Creating an Ecosystem for Millions by Building for Yourself with Taylor Otwell of Laravel

Courtland Allen: 7s

What’s up, everybody? This is Courtland from indiehackers.com, and you’re listening to the Indie Hackers podcast. On this show, I talk to the founders of profitable internet businesses and I try to get a sense of what it’s like to be in their shoes. How did they get to where they are today? How do they make decisions, both at their companies and in their personal lives, and what exactly makes their businesses tick?

The goal here, as always, is so that the rest of us can learn from their examples and go on to build our own profitable internet businesses. Today I’m talking to the one and only Taylor Otwell. Taylor is one of the most requested guests for me to have on the show since I started it two years ago, so Taylor, welcome to the show.

Taylor Otwell: 41s

Hey, thanks for having me. Glad to be here.

Courtland Allen: 42s

Glad to have you. You are the creator of Laravel. It's a web framework for php developers. I think it’s the most popular web framework, back end framework, on GitHub2.

It’s got more stars, even, than Ruby on Rails. It’s used by many hundreds of thousands, if not millions, of developers. Can you let us know what the revenue numbers are like for the Laravel ecosystem as a whole?

Taylor Otwell: 1m 4s

Laravel ecosystem does a little more than $3 million a year in revenue.

Courtland Allen: 1m 10s

That’s crazy, especially for an open source project.

Taylor Otwell: 1m 13s

Yeah, pretty wild.

Courtland Allen: 1m 16s

And you’re not just working on Laravel, the framework, itself, but you’ve also built a suite of products on top of Laravel. So you’ve got products like Spark, Nova, Envoyer and Forge. How much revenue are these projects generating?

Taylor Otwell: 1m 29s

They’ve each - Every product I’ve launched besides my latest one that I just launched in July, Laravel Vapor, has made over a million in its lifetime. I have different kinds of projects. I have a couple SaaS products, like Forge and Envoyer. Forge makes a couple million, actually, a year. Envoyer is probably close to a half million a year, and then the other one-off products, things like Nova and Spark, I don’t keep track of what those do a month anymore, but over their lifetime they’re both a million dollars separately.

Courtland Allen: 2m 2s

You’ve also got a bunch of other things you’re working on that I think most people would consider businesses in and of themselves. You’ve got Laracon, which is an entire conference that you put on. You’ve written books and guides and generated many tens of thousands of dollars in revenue off of those things, so you’re really done it all. How big is the team? How many cofounders do you have? How many employees are working with you?

Taylor Otwell: 2m 22s

From 2014 to 2017 it was just me. Laravel was making over a million dollars a year before I brought anyone on. In 2017 I brought on Mohamed Said. In 2018 I brought on a guy named Dree Spintz(ph) from Belgium who’s been around Laravel for a long time. Our latest hire this year is James Brooks from the UK. So it’s me and three other developers right now.

Courtland Allen: 2m 49s

And you started Laravel in 2010, so the vast majority of this time it’s just been you by yourself.

Taylor Otwell: 2m 55s

Yeah. I started working on Laravel in the Fall of 2010. I launched in 2011 and from that time until 2014 it was just open source. I wrote an e-book and I think it made $60,000 or $70,000, which was awesome. I think I did that in 2013 or 2012. But for most of the time, I had a fulltime job. I worked on Laravel either when my job allowed me to, cause we were building stuff on Laravel for part of it, or at night. So I had a lot of late nights. But for most of that time I was not making any life-changing amount of money from Laravel.

Courtland Allen: 3m 37s

It’s crazy if you think the amount of impact per person, with Laravel being just one person for many years and now it’s a small handful of people, but your products are being used by hundreds of thousands of people, and it’s the backbone of the entire PHP ecosystem at this point. What background do you have to have to build something like this? Were you a computer science whiz kid growing up?

Taylor Otwell: 3m 58s

No, I really wasn’t, and I didn’t even major in computer science in college. I majored in IT, which is more like computer networking and routers and switches and stuff like that. For all I knew coming out of college, I was going to be a network admin or something.

Then a company called Arkansas Best Freight here in Arkansas came to the college to interview seniors that were about to graduate. I interviewed with them and then I got a call back to go for an onsite interview at their place. They ended up hiring me. What’s cool is for every new hire they bring in, and they almost only hire people straight out of college, they put them through six months of computer programming training.

Honestly, they start at the beginning I would say. They don’t assume all that much about your computer programing experience. They started us on classic ASP.NET, COBOL, all the languages that they used there at the company. It’s a hundred year old company so there’s a lot of legacy code as well.

Courtland Allen: 5m 2s

COBOL. Sounds old.

Taylor Otwell: 5m 3s

Yeah. So that’s where I cut my teeth in terms of programming. I’m not a math whiz. I’m not a whiz particularly at anything, and I think that contributes to making Laravel better in a way, because the framework was made very accessible.

It was made to do things very simply, very quickly, whereas maybe if I would have been smarter, it would have been hard to use or something. I don't know. I just view myself as an Average Joe developer that makes tools that appeal to the average other developer and I think that has mass appeal.

Courtland Allen: 5m 43s

What about on the business end of things? To start an open source project that’s grown to generate many millions of dollars in revenue every year is pretty rare. Had you started any companies before Laravel?

Taylor Otwell: 5m 54s

No. Laravel Forge was the first business I’d ever started. Laravel had a pretty big following, which of course makes it a lot easier to launch a business, when you’ve already shared a lot of value and built a big following and have trust among tens of thousands of people, that makes it, obviously, a lot easier to launch Forge. But no, that was my first startup.

Courtland Allen: 6m 20s

So Average Joe developer, zero business experience, and yet here you are today. I guess that means you’ve learned a ton on the job. I think you’re the perfect person to share a lot of these learnings, because this podcast is listened to by a lot of people who are you ten years ago, developers, software engineers who just want to quit their job or start a side project that makes money and make a living doing their own thing the same way that you have. So maybe that’s the best place for us to jump in.

I think a lot of people get started because they’re passionate about something in particular, but a lot of people get started because they know they have this explicit goal of, “I want to be my own boss someday.” How would you describe your goals and your mindset at the beginning when you first started working on Laravel?

Taylor Otwell: 7m 4s

It was a lot of “I want to be my own boss.” I had a young family. I was newly married. We were living in an apartment and we were about to have our first child. I wanted to be able to have more freedom to set my own hours, be able to work from home, be able to move wherever we wanted without being tied down to any given location.

That was a lot of the drive behind building Laravel. When I first started Laravel, the goal was, okay, I’ll build Laravel as a steppingstone into launching these other business ideas that hopefully will come to me. I didn’t have any great ones at the time.

Then after I built Laravel, it took off to such a point where that became the business, which I didn’t expect at all at the time. But I became consumed in maintain Laravel and promoting Laravel that that really turned into my main focus.

Courtland Allen: 7m 58s

One of the biggest challenges early on, and there may be five or ten really big, really common challenges that stop people who are on this path of trying to become their own boss, but one of the biggest ones early on is motivation. It’s pretty common to work on something for a couple months and be super excited for it early on, but then eventually it gets hard or it gets boring or you get distracted by other shiny things and you quit. How did you summon the motivation that was required to get Laravel out the door in the early days?

Taylor Otwell: 8m 29s

I think a lot of it is because Laravel, at the time, I scoped small. When Laravel first came out, it looked a lot different than what Laravel looks today. It was much simpler. There were a lot less features. It was a lot smaller of a task.

It’s not like I started from nothing and then built what is Laravel 6.0 today and released that. When it first came out, I called it a micro framework. I think part of what kept me motivated and able to finish it was just because I kept it tightly focused, and I didn’t have a lot of feature creep and scope creep that made the development process drag on years and years and years to where I would eventually lose interest.

Because there was such a small, tight feature set, I think it made it a lot more manageable. Honestly, a lot of the stuff I’ve launched has been like that. Forge, there’s a lot of stuff we could have done at the launch that we didn’t do. I built something that solved the immediate problem and got it out there.

So I guess what I’m trying to say, a lot of it is being able to see at what point something is good enough to launch, versus incomplete or too much or whatever. You know what I mean? A lot of people err on one side or the other.

Either they launch something that’s so bare bones that it’s not even useful, or they get so bogged down in perfecting everything, adding every feature they can think of, that eventually you just lose interest or you burn out on it or it gets too complicated so you just feel overwhelmed.

So finding that middle ground, the sweet spot of feature set to launch with in a way that’s manageable for one person to build as a side project, I think is a challenge, but I think it’s key to finishing something.

Courtland Allen: 10m 16s

Yeah, it’s a super difficult challenge. My favorite story here is an episode I recorded a while back with Chad Pytel of thoughtbot. Thoughtbot builds products for other companies, oftentimes early stage companies. The feedback they most often give to their clients is, “Hey, you don’t need 80% of the features you need to have in here. You should launch much smaller, much simpler. It’ll be cheaper. It’ll be easier.”

But then when they go to build their own internal products at thoughtbot, they have that same challenge. They find themselves motivated to put in all this extra stuff and it’s very hard to draw the line. So kudos to you for being able to do that. I guess you maintain that balance to this day with your newer products.

Taylor Otwell: 10m 55s

I think one thing that helps my situation in figuring that out was, I was building the projects specifically for me. So it became more obvious when it was done or when it wasn’t done, because I was solving my problem. I know, if you’ve listened to me give other talks or on podcasts, I’ve said that a lot.

A lot of the stuff I’ve built was scratching my own itch. I think if you're building a project is scratching your own itch, you know when the itch is scratched. Defining the scope is a lot easier that way.

Courtland Allen: 11m 27s

I did the same thing with Indie Hackers. With you, you needed a PHP framework for yourself. Probably if you’d come around five years earlier, I would have been a Laravel user because I had been using PHP earlier back in 2008 and just didn’t find it all that great so I switched out.

But with Indie Hackers, what I really wanted was a business idea, and what I needed was some sort of repository of examples I could look at of how other indie hackers were staring their businesses and ideas they came up with and how they were paying their own salaries. There wasn’t anything like that out there, so I needed to build it.

There are challenges with scratching your own itch. In my particular case it was once I had that business idea I no longer needed indie hackers to solve that problem for me. Suddenly on launch day I’m already in the place where I’m building for other people. I’m not building for myself.

But there are other problems, too. For example, just because you have an itch to scratch for yourself doesn’t mean that other people have that same problem. How did that work early on for you at Laravel? Were you certain that other people had the same problem that you did?

Taylor Otwell: 12m 23s

As far as figuring out, do other people have these problems, when I was building Laravel initially, I didn’t care because I was building Laravel for myself. But when I was building stuff like Forge, I tried to rest in the fact that, like I said, I viewed myself as an average developer.

I was like, “If I’m having this problem, someone else has to be having this problem,” because I saw myself as a typical PHP developer, encountering this problem day after day of not being able to quickly spin up a PHP server on DigitalOcean or whatever. That was my take on it. Maybe I got lucky that that happened to be true. I don't know if there’s any validity to that, but that’s just how I viewed it at the time.

Courtland Allen: 13m 6s

How long did you spend hacking away on the early versions of Laravel before you got to the point where you could release Version 1.0?

Taylor Otwell: 13m 13s

I would hack on it until 2:00 in the morning. I think I worked on Forge until about six months before I launched it. It wasn’t super pretty. It was all built using Bootstrap, CSS. There’s no custom design. I wasn’t a super good designer. But it was usable, and the basic feature set was there in terms of giving someone a useful product from the very first day.

Courtland Allen: 13m 42s

I remember launching Indie Hackers, and it was definitely one of those inflection points where there was a before and there was an after. In the before period, it was just me working on it. I was the only source of feedback on the product. I was the only source of new ideas for the website.

But then after I launched Indie Hackers, suddenly it was no longer just me but it was thousands of other people who had opinions and suggestions. You could send me emails and they might have complaints. It was just completely different emotionally working on the product in that phase.

It was also tremendously motivating. Suddenly I would stay up late into the night to work on something cause somebody had asked for it. I ended up working way harder on Indie Hackers in the weeks after I launched than I had beforehand. I wonder if that was the case for you, Taylor, when you were working on Laravel. Was there an inflection point after you released it to the word and suddenly other people started to care?

Taylor Otwell: 14m 32s

Oh, yeah, for sure, especially when I first launched Laravel. I was out interacting with people that were using it in forums and chat rooms every day, interacting with them a lot. It fired me up that other people were excited about it, and their excitement fueled my excitement so I wanted to work on it even more.

Even now, Laravel has matured a lot and changed a lot. Now it still is crazy. Every time I go to Laracon, I hear a lot of inspiring stories from people. Some people were doing some whole other career and then they came across Laravel. Maybe they always wanted to tinker around with programming and now they’re a Laravel developer.

I heard a story like that at the last Laracon. All that stuff still fuels my excitement to work on it. Definitely when you 100,000 people or more using then you feel an obligation to work on it, for sure.

Courtland Allen: 15m 34s

You’ve got a podcast called Laravel Snippets. You talked about this on a recent episode. It was all about motivation. You made one of the most inciteful points I’ve heard here, which is that you’ve got intrinsic motivation, which is your passion for the project, but you’ve also got this external motivation, the feeling that you need to have discipline to get through things.

You owe other people something, or you need to suck it up and work on the hard parts, not just the easy, fun parts. For you, in the early days, how much of Laravel was discipline and how much of it was passion?

Taylor Otwell: 16m 0s

A lot of it when I first started was passion, but I have a decent mix of discipline naturally, just as part of my personality, that helps me push through things sometimes. One of the strategies I always take as well is I always tackle the most difficult part of a project first, because I can always feel that part of my brain that wants to push that off and we’ll get to that part later.

But for me, I feel like I do a lot better on a project if I do the absolute most difficult part first, the part I’m most unsure about whether it’s even possible. I would rather just do that first, and then if I fail at least I fail early, and I didn’t waste a bunch of time building all the easy parts and procrastinating around the hard parts. If I’m going to fail, I would rather fail within the first week, rather than wait a whole month or two.

Courtland Allen: 16m 56s

That’s definitely the best way to go about things, and it’s amazing that that’s your natural personality. I know a lot of other people need to read a lot of books and come up with lots of different strategies to get themselves to behave that way and even then, still tend to procrastinate by doing the easy stuff first and not the hard stuff.

I think this segues well into the topic of idea validation, where the whole goal here is that you want to figure out if the product you’re going to work on, the project you’re building, is worth working on in a couple weeks rather than spending months or years of your life working on it. What were the hardest parts of Laravel where you needed to validate in the early days?

Taylor Otwell: 17m 30s

I didn’t know if people were going to embrace Laravel. The one part I did feel strongly about was that if I wrote good documentation that it would gain some following, because I felt like documentation and accessibility were king in the PHP world.

The other competing tools, the ones that were popular, they all had good documentation. The ones that weren’t popular, they had terrible documentation. So I felt like that was the differentiating factor, even above and beyond the technical merits of the tool.

To an extent, that’s still somewhat true today. Think about when Slack first came out. There was this group of people that were like, “We’ve had IRC for 20 years,” or whatever. But Slack is easier for people. It’s more accessible. That stuff wins at the end of the day, even if IRC is technically superior in some way. So that was my approach to it, was making it accessible.

Courtland Allen: 18m 34s

Yeah, I think this is a challenge that everybody has, over-emphasizing the product, but especially developers. We spend so much time with our noses in the code that we turn a blind eye to all the other parts of a business or product that make it appealing to people, that make it work and then make it successful. It’s very easy to ignore documentation and things like that. What else was crucial for Laravel’s success in the early days?

Taylor Otwell: 18m 57s

Going off what you just said, and I was going to talk about this in an upcoming Laravel Snippet, is a lot of developers that are trying to start businesses don’t realize how low their pain tolerance needs to be for finding problems.

I’ve talked about this with Adam Lavin quite a bit as well. I feel like I have a very low pain tolerance for things. If I encounter something that’s frustrating, I want to build an easier solution for it. Let’s look at Laravel Forge, for example. Laravel Forge, you sign up and you link your DigitalOcean account and it makes a server and it installs PHP and all of that for you.

There are a lot of developers out there that when they see something like Forge, they think, “I could just use ANCEL for that,” or “I could just use Terraform for that,” or something like that. It’s because their pain tolerance is too high. They’re willing to put up with hours of documentation, hours of configuring YAML configuration files, whatever else to figure out some orchestration tool for their web layer. Some people are into that.

I think when you’re looking for ideas as a programmer, you need to try to turn that part of your programmer brain off and lower your pain threshold, so that you can discover these tools. Sure, you as a developer might say, “I don't know why anyone would do this. I could just do this myself using X, Y, Z.”

A lot of people are willing to pay for a much simpler solution, even if you think it’s dumb or too easy. With Forge, that’s very much the case. Even when I launched Forge, a lot of the feedback on reddit was just what I said. “I could run my own Raspberry Pi in my office and do this myself.”

It almost felt like 50% of the feedback was like that, if you just look at the Hacker News/reddit-type comments. But there’s this whole other crowd out that, that’s a lot more people, that are willing to pay for a simple solution.

Courtland Allen: 20m 57s

Totally. I’ve never quite heard it put that way before, that you need to lower your pain tolerance, that you need to lower your pain threshold. I think it’s spot on because if you’re a developer, you write code all day long and it’s not that painful. In fact, it’s probably fun for you. You probably enjoy writing code.

So when you put your business hat on and you’re trying to come up with an idea, you might rule out an otherwise good idea because you think, “Oh, nobody’s going to pay for this when they could just whip up the code themselves.” But that’s now how consumers think.

People are generally happy if there’s some cheap, simple working solution to their problems so they can spend their day doing other things they want to do. Even other programmers think that way.

Let’s talk about idea generation, because you’ve been able to come up with seemingly project after project and they’ve all been successful, when the average person has trouble coming up with even one million dollar idea. What’s your approach to deciding what to work on?

Taylor Otwell: 21m 47s

Everything I’ve worked on so far has been jumping from solving my own problem to solving my next problem to whatever problem comes up next, I solve that. Four of the product ideas were my ideas. That was Forge, Envoyer, Spark and Vapor, which were all my own original ideas. All of them were solving problems that I had.

At Forge, there was provisioning servers. With Envoyer it was I needed to deploy with zero down time. With Spark, I just took the lessons I learned building SaaS backends on Forge and Envoyer, and then built a faster way to do that for myself because I didn’t want to ever have to do it again. Then Vapor, I was personally interested in serverless, autoscaling, deployment stuff. I didn’t want to think about servers anymore and so I built Vapor.

With Nova, that was the only idea that was pitched to me by a guy named David Hemphill. He sold me on the idea and showed me why I needed this when we were in New York for Laracon. We cowrote that product together. All of the idea are essentially driven from my own needs. I never tried to launch a business where I just searched for an idea that was outside of my problem space.

Courtland Allen: 23m 5s

Okay. Let’s dive into this. A lot of people have trouble making the strategy work of solving their own problems, of scratching their own itch. For example, a lot of people will say, “Hey, I’ve looked around my life and I don’t really have any problems that are worth solving. They’ve all been solved already.”

Other people will try to solve a problem that they care about but it turns out that it doesn’t resonate with other people. I wonder what you think is missing here and what people can do when sometimes solving your own problem doesn’t seem to be quite enough.

Taylor Otwell: 23m 31s

Maybe my approach is just an anomaly. I’ve thought about that myself. Maybe there is no useful information to draw from that. I think part of it, though, when people say they don’t have a problem worth solving goes back to that pain threshold thing. Maybe if they lowered their pain tolerance a little bit, they would find problems maybe.

But I don't know. It’s hard for me to say. I’ve wondered that myself, that maybe I don’t have anything that valuable to contribute to this discussion. Why do people want to hear my story? But I don't know. That’s just how it’s always worked for me. It has worked four times, so it feels like there’s some validity to it but I don't know.

Courtland Allen: 24m 16s

There’s some consistent themes to the products you’ve built. For example, they’re all built within the Laravel ecosystem, on top of this framework that you’ve developed. You’re not going out, building a totally random product that doesn’t have an audience and doesn’t have a channel that you can distribute it through, for example.

Taylor Otwell: 24m 31s

Yeah, that’s obviously very key. I think I’ve built this big audience with Laravel doing open source work. I think if you have any way to build an audience like that, you should definitely do that and take advantage of it.

I’ve seen quite a few people try to launch things without going through that legwork of sharing value, whether that’s recording podcasts like this to share with people and just build up a following, whether that’s building an open source tool, whether that’s writing blog articles. A lot of people don’t go through the legwork of building that reputation of being someone worth following or worth investing in their products. Then if you try to launch something I think you have a lot higher chance of failure.

For me, it’s not like I set out one day like, “Oh, I’m going to build an audience using Laravel and then I can sell a bunch of stuff.” It just happened to work out that Laravel built me a big audience. But other people have had to start from scratch with that. But definitely a huge advantage and worth putting in a couple years of time to build up your audience like that.

Courtland Allen: 25m 37s

It’s such a crazy advantage to sell to an audience you’ve built.

Taylor Otwell: 25m 41s

Oh, yeah. It’s mentally like cheating. It’s a huge head start.

Courtland Allen: 25m 45s

If you look back on why you were able to build such a huge audience for yourself via Laravel, what do you think some of the biggest contributing factors were, especially given that you weren’t going into this explicitly intending to build an audience?

Taylor Otwell: 25m 58s

Some of it was technical things like the accessibility to framework. Some of them were non-technical things but that I set out intentionally to do. I always set out to have a positive atmosphere around Laravel, whether that was the way I personally interacted with people around the project.

You know how every company has a personality, a brand? Apple has a personality. Slack has a personality. I always try to make Laravel have a friendly personality, a fun personality. A lot of that was imitating people like Apple and Slack, to be honest.

I think that was just attractive for people. None of the other competing tools in PHP were doing anything like that. I wouldn’t say they were operating or viewing themselves as a product. Laravel was one of the first frameworks, I think, to come into PHP and market itself as a product in that way.

Other people were viewing it or approaching it in this sterile, open source fashion. They would never tweet anything fun or interesting. It was always like, “We have a new release. Here’s the eight changes that were made.” It was always very sterile. So I tried to make Laravel inviting and a fun place to be.

Courtland Allen: 27m 14s

It’s interesting to see a space where an entire market is full of products that are all kind of the same. They have the same personality, the same look and feel. They might be different in terms of what they do but generally you can tell everybody’s inspired by everybody else. Everybody’s copying the details that everybody else is using.

Then somebody comes along and does something different. WuFoo is a good example of this. The form builder space is super boring, so WuFoo decided to open something that was loud and colorful and funny. They’d tell you jokes inside of the product and that made them stand out. It’s obvious, in hindsight, that that’s what you want to do. You want to be deliberate and stand out in a good way, but most people don’t do it.

Taylor Otwell: 27m 51s

Laravel changed a lot about the PHP world. There was that and then no one was really selling stuff in terms of open source and PHP. There was this big apprehension to cross that barrier and put a product around an open source library. It was controversial. People thought maybe it went against the spirit of open source. We were breaking new ground on both fronts.

Courtland Allen: 28m 18s

What made you so confident that it would be okay to do something like that when it obviously goes against the normal open source culture of everything being free?

Taylor Otwell: 28m 26s

My thought with Forge was I can either make it free and make zero dollars, or I can charge for it and it fails and I also make zero dollars. So to me, it was I might as well try to do it.

With Forge, it was something that I felt was disconnected enough from the open source tooling, where it didn’t feel like I was making a paid version of Laravel, as if you had to pay for access to the framework, which I think wouldn’t have been a good move. So I thought it was separate enough to where hopefully people would differentiate it in their mind from the tool.

Courtland Allen: 29m 4s

I’ve spoken with a couple of different open source developers on the podcast. I had Evan You on, the creator of the Vue.js. I think he makes most of his money through donations, on Patreon and maybe some do sponsorships. I also talked to Mike Perham, the creator of Sidekiq.

I think instead of building complete separate apps on top of his framework, he just charges for a pro or premium version of Sidekiq with extra features and better customer support and stuff like that. It’s interesting to see that you've been able to make it work with a third model, where you’ve got the space-level framework that is Laravel, and then on top of that you’re building these optional paid tools.

They don’t really take away from anybody’s ability to use Laravel if they don’t want to pay for these tools. What are some of the keys to making that model work, and what’s your advice for other open source developers who are trying to figure out a way to charge for what they’re building so they can continue working on their projects?

Taylor Otwell: 29m 55s

I think it’s hard to make money in open source. I’m not sure I’ve ever seen anyone make a living on pure open source donations. When I think about Evan You or myself, we’re both Patreon and we both make a decent chunk of money on Patreon, but we’re both selling advertising space on the website. So to me, that’s like selling some sort of product, let’s say.

I’ve thought about this thing a lot, about open source developers and making money, and I don't know. I don't know if there’s any solution there, because a lot of people are building tools that just aren’t conducive to donations. Say I build this file system library that helps you interact with files, and a tool like Laravel uses that library.

The end users of Laravel don’t view your library as something they’re consuming. Laravel’s really the customer of your library, and all these other people are unaware of the fact that your library’s under the hood. So they don’t feel compelled to donate to that.

So I don't know. I don't think it’s feasible. I don't know if it’s a good idea to try to make a living off open source donations. I think the best value at open source is using it as a tool to build an audience of people that are interested in what you’re doing, the same way as recording a podcast or publishing a book or whatever.

Courtland Allen: 31m 15s

I thought about this a lot in the early days of Indie Hackers. I used to ask for donations. It’s a different space in the developer world but it’s similar in that people are used to getting stuff for free.

If you’re a founder and you want to find advice on the internet or you want to read some interviews, there are thousands of places where you can see the stuff for free. If you’re a developer and you need an open source tool, most of the things that you’re using as part of your stack every day are completely free and you probably haven’t donated at all.

So I think if you’re operating in a space like this and you ask for donations, it’s super easy for people to say no because they’re used to things being free. The other side of this coin is I think that donations obscure the value that you’re providing.

If you’re selling something to somebody and they don’t know you and they don’t like you, you know they’re buying that thing because they need it. It’s valuable. Whereas if you’re asking for donations, who knows? Maybe they don’t even care about your thing. They just like you.

Taylor Otwell: 32m 4s

Yeah. I think so. I think that’s good insight.

Courtland Allen: 32m 7s

There are some other ways to come up with ideas that we haven’t talked about and that you’ve mentioned on the Laravel Snippet podcast. The first was scratch your own itch which I think you’ve done consistently.

Another one is that you can pick a technology that’s up and coming and ride a wave of a big trend. I think it’s interesting to see how you’ve done that with Laravel, because PHP in a sense was up and coming, but also I feel like you’ve created the wave. You’ve revitalized PHP, because when I was using it back in the late 2000s it felt like it was on its way out.

Taylor Otwell: 32m 38s

It was dying, big time.

Courtland Allen: 32m 42s

You almost did the opposite. You picked a dying trend and built on top of that, and yet Laravel still worked out. Why do you think that is?

Taylor Otwell: 32m 52s

I think because PHP was just such a huge language. I don't think a lot of people realize how many users of PHP there are out there, especially when you factor in WordPress and Drupal and things like that. The pie is so big that even a small piece of that pie is still a lot of customers and a lot of users.

I picked PHP by accident. It’s not like I had some insight into that. But in hindsight, I think that’s why Laravel was still able to succeed in PHP. A lot of people already know PHP. When I first came into PHP and I was hanging out in PHP chat rooms, everyone was wanting to leave for Ruby, everybody, Ruby or Python or something because they were dying for something fresh, a drop of water in the desert. I think Laravel came along and revitalized it to an extent and gave them some fresh energy.

Courtland Allen: 33m 51s

That’s the exact transition that I was making. I was using PHP I think to build Facebook apps, because Facebook used PHP so you had to use that. Then I learned Ruby on Rails and that was the new hotness. Everybody was talking about it. They had RailsCasts coming on which was their video series on how to learn. It was easy to get on board. Everybody knew that was the future. How do you compete with something that has so much momentum, that’s so popular when you’re building for a language that’s dying?

Taylor Otwell: 34m 20s

I don't know. Again, I think there were so many people dying for something fresh. Rails was a huge inspiration for me personally, and all DHH did on Rails was a huge inspiration, but I just think there were tens of thousands of people that were a neglected market, that had been left behind. They had to use PHP for their day job or whatever else, when I just came along at an opportune time when all the other PHP frameworks were stagnant and was able to strike while the iron was hot.

Courtland Allen: 34m 54s

This plays into building an audience, I think. You’re giving all these PHP developers who are craving something good, who have invested a lot of time, maybe even years, in learning the ins and outs of PHP and there are lots of PHP projects. They probably don’t want to see PHP die.

Then here you come and you’re like, “Hey, use Laravel. It’s free. It’s much better than what you’re used to using. I’m going to keep working on it and make it better.” How did you turn that excitement into an audience that you could capture, that you could reach again and again into the future?

Taylor Otwell: 35m 24s

One was being very engaged with them. I tried not to sit in an ivory tower and just work on the framework. I tried to be one of them and hang out, answer questions, just chat about random stuff in the Laravel chatroom, just off-topic stuff and just build friendships and trust within the community as being an accessible person that’s just trying to build something valuable and make development fun again for our group of people.

Courtland Allen: 35m 52s

That makes a ton of sense. It’s good to be a part of your community. Now we’re starting to talk about community and not just building an audience. I think there’s a distinction there where an audience is people listening to you - Taylor Otwell.

It’s the ivory tower of things you were discussing earlier, whereas a community is people helping each other. You can take a break from that community. You can leave that chat room you were talking about and you can come back a few days or a few hours later.

People have built tools to help each other out. They’re answering each other’s questions because it’s an engaged community. How did you think about creating a community early on when all you had was an audience? Is that something that just happens on its own, or do you have to put deliberate thought into it?

Taylor Otwell: 36m 32s

I did try to foster it in the ways I mentioned. Then once it gets to a certain point, it snowballs with itself. Other community members have come in, and they’re now contributing, answering questions, writing blog articles.

Then you have someone like Jeffrey Way come along who starts laracasts.com and it’s the first person to go fulltime on a Laravel-related business. He’s pumping out videos, four or five vids a week, it seems, on Laravel. Now it’s out of my hands in a way to where I just planted the seed and I think tried to get it started on a good path, and then other people came in and tended that garden, so to speak, and saw it to completion. Laracasts was probably a major part of making that happen.

Courtland Allen: 37m 25s

Yes, it’s just another advantage of building an ecosystem. Cause not only are you able to come in and build your own products on top of the Laravel ecosystem, but now everyone else is building different products and different resources and they’re filling in the gaps.

Probably there’s a sense in which you could look at what Ruby on Rails had and say well every single thing we have going on there, we can have for Laravel. There are guys in videos. We should have Laracast, which will be like RailsCast or something.

They have conferences. We should have a conference. Is there a sense in which you looked at as in, “Let’s see what’s going on? Let’s just duplicate what’s going on elsewhere?

Taylor Otwell: 37m 58s

Totally. At the beginning I was always looking at what other ecosystems were doing, especially Rails, Python ecosystems. I was constantly looking to them for inspiration. Basically everything I did, I would consult. What would Rails do on this problem or in this situation? That was helpful. It was standing on the shoulders of giants, in a way, when I first started looking at some of those other languages.

Courtland Allen: 38m 27s

Tell me about launching a conference. How did you decide to do that and how do you get a successful conference off the ground?

Taylor Otwell: 38m 35s

When we first started Laracon, it wasn’t my original idea. I was working at UserScape for Ian Landsman. We were building help desk software on top of Laravel. I guess it would have been winter 2012 because our first conference was 2013.

He was like, “Hey, I think we should do a conference.” I didn’t know if Laravel had the following to have a conference. But he was like, “No, we’ll have a hundred people.” He wanted to do it in three months from when we talked about it. We started talking about it in the winter and we were going to do it in February in Washington, D.C.

I was like, “Whatever. Let’s try it. Maybe we can get a hundred people to come to Washington.” We thought people could come from New York and Boston and Philadelphia, and hopefully we’ll be able to do it.

It worked out. We got 90 people. We had 12 speakers and we had the first Laracon. I think that probably did help solidify Laravel as a real thing in people’s minds. Even the people that didn’t come to the conference, they see there’s a Laracon now. This is getting legit as a framework. It’s crazy. I didn’t think it would work but it did, and after that it just kept growing every year.

Courtland Allen: 39m 55s

How big is the conference nowadays?

Taylor Otwell: 39m 56s

Now it’s 900 people. This year we had 900 in Times Square at PlayStation Theater. The nice thing about it is, for me, Laracon is not a for-profit endeavor, cause we have the other revenue from Forge and OnVoyage. As long as Laracon breaks even, to me that’s the goal.

It means we poured every bit of money that we could into making the conference as awesome as possible, cause thankfully we’re in a position where we don’t have to make any money on Laracon and we can just make it an awesome event for people and do it that way.

Courtland Allen: 40m 33s

I was talking to another indie hacker on the podcast last week. Her names Anne-Laure. She’s got a company called Ness Labs. Some of the products she makes are free. She just gives them away. Other products she makes she charges money for.

It’s cool because those free products help her build her brand and spread her message, and she’s able to do it because she’s got this ecosystem of other things that can cover its cost. I love that strategy of not only having one thing but having different things and being able to reap the rewards of certain things or just break even or free that don’t need to turn a profit.

Taylor Otwell: 41m 4s

We’ve done that in other ways, too. I typically would alternate years of launching of commercial product versus a free product. You mentioned Sidekiq Pro earlier on the podcast. We built our version of Sidekiq Pro called Laravel Horizon and just launched that for free at Laracon 2017, as a way to say thank you and to build good will, and to continue to provide value to people without asking for anything in return.

I think that’s an important thing to do when you’re trying to build an audience. We did the same thing with Laravel Telescope last year. It was a free debugging tool for Laravel. I think that’s smart to do that. We’ve tried to do that same thing, because I’ve never wanted to make Laravel become the next drab corporate entity that’s always taking your money. I still want it to be a fun place that’s putting out lots of cool free stuff, too, and sometimes we put out commercial stuff. But half the time we’re putting out free stuff. It’s a good idea.

Courtland Allen: 42m 14s

How important is it, exactly, to give things way for free when you’re trying to build a community and build an audience as well?

Taylor Otwell: 42m 20s

Huge. It’s maybe one of the most important things in my experience at least that we done, is give away Laravel itself for free. I’ve given away lots of educational material for free, Laravel Horizon, Laravel Telescope, Laravel Echo, all those things for free.

Laravel Homestead was free. Laravel Valet was free. We’ve given away so much free stuff. I don’t say it in a resentful way, like, “Oh, see, I’ve given you so much free stuff. You should pay me now.”

Courtland Allen: 42m 49s

You owe me.

Taylor Otwell: 42m 51s

Genuinely I think it’s a smart thing to do. For me, the hard part is I think it’s important to be able to do it with a pure heart, so to speak. If you’re only doing free stuff so that tomorrow you can ask them to pay you, to me, that feels tarnished in a way. But I’ve always tried to give free stuff out of the fun of it and the excitement of it, to make people happy and to build up goodwill within the community.

Courtland Allen: 43m 22s

What’s always struck me as interesting about this whole topic of building an audience before you get started is it’s a chicken and an egg problem.

Taylor Otwell: 43m 22s

It is, yes.

Courtland Allen: 43m 31s

You want to build an audience and you want to give them something for free that’s useful and helpful and that hopefully you’re passionate about so you do a good job. But where does the audience come from that’s going to use this first audience-generating information that you’re putting out there in the first place? How does that work? What did that look like for Laravel when at the very beginning nobody knew about it. No one cared.

Taylor Otwell: 43m 49s

I mean, small success. I remember I was super excited one time that a Twitter account that had 500 followers retweeted something that I tweeted about Laravel. To me, that was a huge success at the beginning, getting Laravel in front of 500 people.

I would try to post it everywhere I knew. There was a site called Forest that was for developers at the time. It was like a Dribble for developers. I would post it on reddit in programming stuff. I don’t know. I’m not the best one to ask about building an audience from scratch. But that’s the things I did, just try to be scrappy about finding every little way I can get the framework out there.

Courtland Allen: 44m 38s

Was there any one thing that worked better than others or was it just every little thing contributed a small amount?

Taylor Otwell: 44m 44s

I think it all added up a little bit. I think sites like Forest and reddit, for me, were big for getting it out there in front of a lot of people. I didn’t have any Twitter following at all because I wasn’t anybody to follow. I probably had 10 followers. So that wasn’t a huge market for me. It was more that if I could get someone to retweet it or share it with their audience, that was helpful.

Courtland Allen: 45m 12s

I had almost the exact opposite situation early on with Indie Hackers, where I had one distribution channel and that was Hacker News. It helped Indie Hackers blow up in the first week. I had 100,000 visitors in just a couple days.

But after that I was like, “Where do I go from here? What do I do? Do I spend lots of time posting on Quora and all sorts of other website?” It doesn’t even seem to be a drop in the bucket. So I think, for me, the next step was to build my own internal channels.

I should have my own mailing list where I can reach people at any time. I should have my own online community and forum where people can talk to each other. Hearing your story, a lot of that seems to be done through the conference.

You’re launching your new products every year at the conference. You don’t need any external distribution channels nowadays to market Laravel, at least that how it looks from the outside looking in. Is that true? Do you spend time trying to grow Laravel?

Taylor Otwell: 46m 8s

It’s funny you ask that because I was just on the phone with Adam Lavin who I mentioned earlier yesterday, and he was like, “Maybe you should market Vapor some more.” And I was like, “What does that even mean? What do you mean, try to market it more?”

We always laugh at the fact that it feels like I’ve done nothing right in terms of marketing. I don’t have a mailing list. I don’t pay for ads for any Laravel projects or products. Well that’s not true. I have run a couple of ads on reddit for Forge, but in general I don’t do any paid marketing or anything. All my marketing is strictly through my own Twitter channels of working on Laravel, through hyping up the conference, and then other community members, just talking about it or tweeting about it or blogging about it.

Courtland Allen: 46m 58s

It’s cool if you’re building for an ecosystem that has gaps, that has holes. If you’re like, “Well I’m using Laravel but I need some sort of background job processor in PHP.” People, I assume, just search out some of the things that you’re building, cause they already know that they need them. These are tools that fill a missing gap that people know to search for.

Taylor Otwell: 47m 16s

Yeah, and that’s what I was talking about on my Snippet a few weeks ago. If you can find a hot tool and then pair it with some other thing that people want, like Laravel and GraphQL or something, some kind of pairing, then that’s a good way to launch something successful, I think.

Courtland Allen: 47m 34s

Totally. I think people hear this sometimes. They’re like, “Oh, okay. Well I’m going to combine underwater basket weaving with my passion for Lord of the Rings.” Maybe one of those is too small and too niche and there’s not going to be enough people.

But if you can take two huge things, PHP and background job processors or PHP and servers or something, then it’s cool cause you can niche down and make something super targeted, super specific, but also have a huge market where it’s not just going to be a couple dozen people.

I want to talk about some of these other problems that developers who aspire to be indie hackers run into. We’ve talked about how you come up with an idea and the limits of scratching your own itch. We’ve talked about building an audience.

I think another big thing has to do, we’ve touched on it a little bit, is pricing. It’s very easy to underprice the things you’re working on. It’s very easy to be scared to charge at all. How have you decided on the price points for the different products you’ve released? How have you decided on charging recurring revenue or just one-off and those decisions?

Taylor Otwell: 48m 37s

Back at the beginning with Forge, I knew it was going to be a subscription service based on the nature of the product. Then I was so apprehensive, because I was selling something to an open source audience, so I sent my price low. Forge launched at ten bucks a month.

I think that was too low of a price in hindsight, but it was just my own fears made me put it low. I think it worked out in the long run because Laravel had so many users that the volume made up for the mistake in pricing.

As I’ve gone, every product I’ve launched I’ve gotten more comfortable with bumping up that price. So OnVoyage’s tiers go up to $50.00 a month, so a lot higher than $10.00 a month but not hundreds of dollars a month.

Then Vapor, now the cheapest plan is $40.00 a month. With Nova we charged $200.00 per site. So the prices have gone up significantly since that first release, and I think part of that is because I’ve gotten more comfortable with putting a fair price on things that I think they should have based on their value, and I’m not as scared anymore

Part of that, I think, is because in PHP, we’ve conditioned people to expect things that bring value to potentially cost money, whereas when Laravel was first getting started, that was not the case at all. It’s very easy to take that for granted now. But just the other day we had a Laravel community member launch a native Mac application for tinkering around with Laravel code. They sold it as a premium app. You had to pay for it, and no one complained about that. No said, “Oh, this should be open source and free.”

It’s easy to take that for granted because at the very beginning of this whole story, there would have been a lot of push back around selling that for anything at all. Even if it was $5.00 or $10.00. So over time, I’ve increased my prices. I still am not sure I’m great at pricing things, but I think you’re right that most developers probably err way too low.

Going back to our topic on donations in open source, even when people try to do donations, I’ll see them set their tiers at $1.00, $5.00, then corporate tier, $25.00. It’s so comically low, and I don't know if it’s cause they don’t know. They misjudge how much money big businesses are actually dealing with, but they just set them so low that it’s just so hard to make a sustainable, livable income.

Courtland Allen: 51m 18s

It’s easy to tell yourself in the early days that the thing that you’ve built or the thing you’re creating isnt that good yet and it’s not worth that much money, and that the only way it’s going to sell is if you charge a dollar a month, something small. Do you think that you charging so little for Laravel in the beginning was necessary or in hindsight do you think you could have come out of the gate charging a lot?

Taylor Otwell: 51m 37s

I definitely think I could have charged more. I don't know how much more but I think I could have charged more than $10.00 for sure. I think if I would have put it in the $25.00 or $30.00 range, it would have done just as well. I don't know how high I could have gone.

But I think when you’re first launching a product, I know some people want to aim for $49.00 a month as their minimum monthly, and I think there’s a lot of sense in that, honestly. I do agree with that. It’s just so much easier to get a couple hundred users rather than trying to get a couple thousand users, which is very daunting.

That’s what I did with Vapor, is go $40.00 a month and figure, hey, maybe I can get 400 or 500 people on this. I would be happy with that if it did that. It felt achievable, and I think that’s a good marker. I don't think I had to charge $10.00 month for Forge. I was just bad at pricing back then, nervous, and that’s what I did.

Courtland Allen: 52m 40s

Like you said, you had the whole audience building thing made up for it. You had such a huge following for Laravel at that point. You had already a couple of different Laracons by the time you launched Forge?

Taylor Otwell: 52m 51s

I launched Forge at Laracon Number 2 in New York City.

Courtland Allen: 52m 54s

Number 2. So you have the ecosystem going. You are already creating your own distribution channel and you were capturing the fact that you had an audience. You charge ten bucks a month. How long did it take you to hit the point where Forge was profitable and you were able to quit your fulltime job and work on Laravel stuff fulltime?

Taylor Otwell: 53m 11s

I quit my fulltime job six months after launching Forge. I was already making more than my fulltime job within the first six or seven weeks. But I was nervous to automatically quit the job. One, I liked working there.

Two, it was scary cause it was so new. I didn’t know if it could all collapse within a few months or if it was going to be a long term sustainable thing. I wanted to see it out for a little bit. January 1 of 2015 was my first day working fulltime on Laravel.

Courtland Allen: 53m 49s

It’s crazy because people talk about how long it takes, a couple years of working on a SaaS product to get to the point where you can quit you job. With you, you were already making that much a few months after launching Forge. But if you look at the whole story, you had spent years, a couple years by that point working on Laravel, building the audience and doing a lot of research to figure out what people wanted. By the time you built Forge, you had a good understanding of what was missing and what was valuable, I can imagine.

Taylor Otwell: 54m 17s

Exactly. You could say there was a four-year leadup into Forge of working without making much money at all. So yes. And I think all of that legwork made it launch a lot faster, obviously.

Courtland Allen: 54m 33s

So at this point you’re launching products significantly faster than every four years. You’ve got, like I mentioned earlier, a new product almost every year. Where are these ideas coming from? Do you have a giant list somewhere of what you’re going to build for the next ten years, or is it inspiration strikes and you get started immediately?

Taylor Otwell: 54m 49s

I don’t keep a giant list, but I do keep a list of potential ideas. There are only four or five on there. It’s not like I have hard dates beside them, but I do keep a little list of like, “Hey, maybe this would be a good idea or maybe that would be a good idea,” and try to have some idea of what might be coming in the future.

For example, right now I’m building an example application to help people learn Laravel. It’s going to be a free thing I put out. I’m trying to build a whole app in Laravel. All my stuff, my biggest stuff, has been close source and commercial, and it’s always frustrated me that me as the creator of Laravel has not had this app I can point people to and say, “Hey, here’s how I would build something in Laravel.”

So that’s why I’m doing right now. It’s not going to be a commercial thing, but it serves a couple purposes in my mind. One, like we talked about, it’s just something to build goodwill in the community. But then, two, use this an opportunity to find ideas.

As I’m working on this example application, I’m going to be look for what is giving me trouble. What is hard about this? What do I wish was easier about launching or building this application? So I’m proceeding in faith, in a way, that if there’s a valuable idea, it will surface to me at some point during this example application while I’m working on it.

If it doesn’t, it doesn’t, but right now I’m just going on faith that hopefully it will. It’s just a way to keep me on the ground and working on something real, and I think that’s where some of the most valuable ideas have come from.

Courtland Allen: 56m 30s

Well it’s crazy to me how much you really do. You’re on this podcast right now taking the time to do a little bit of promotion. You have your own podcast. You’ve got the Laravel framework that you need to work on. You’ve got this list of ideas that you’re excited about that you’re working on. You’ve got Laracon.

You’ve got all these different products that you’ve launched and I’m sure new ones in the pipeline and a pretty small team doing all of this. How do you make the time? How much are you working nowadays, too?

Taylor Otwell: 56m 55s

I work pretty much 8 to 5. A lot of it is having the team around me now. Moving further down Laravel’s commercial history, I definitely waited on hiring too long. I was scared to bring someone else into Laravel for fear that they might mess it up or that they would mess up my baby that I’d created.

That was probably one of my biggest business mistakes, I would say, is waiting a couple years to even bring on one person to help me. Laravel was making a lot of money at the time. We could have easily hired a lot sooner. But that made my life so much easier.

Now I have one employee dedicated entirely fulltime to open source. They don’t work on any of the commercial stuff at all. Two employees are working on the commercial stuff, and that includes helping answer support emails, which I also do every morning, and then fixing bugs and all that.

What that allows me to do is focus on the R&D aspect of Laravel I guess you could say, where I’m the one tinkering around with new ideas and of course I bounce ideas off them, too, and they pitch ideas. Laravel Telescope was Mohamed’s idea. It’s the staff that is making this possible for me and making it possible for me to be productive in building new things now, because if it was just me, I would be way too bogged down at this point to do anything new, for sure.

Courtland Allen: 58m 25s

Are they any things that you find yourself saying no to often that others might say yes to? I feel like even with the staff you have and even with the division of labor, you’ve got to be super disciplined in some way to be able to have this much time to do the R&D stuff. I could easily see it taking 24 hours a day to run Laravel.

Taylor Otwell: 58m 42s

Yeah. There’s some of that. I don’t get as many requests to do things as people might think. I get invited to a conference maybe once a month or something like that. I say no to almost all of those, because I don’t want to be away for the family.

At this point, I’m not sure it’s worth the best use of my time, for Laravel, for me to travel around and to that. It kills the time I can work on the ecosystem itself. There are also ideas that have come up that we’ve said no to, like building a Laravel bug tracker. We said no to that, and other ideas that I feel wouldn’t be the best use of time.

My framework for gauging that is, I like ideas that we can accomplish in a reasonable amount of time and that provide maximal benefit to our end users, like make our end users more powerful and able to do cooler stuff. For me, stuff has to have a good bang for the buck in that sense, for me to want to do it.

Courtland Allen: 59m 49s

There’s a framework that Intercom’s founders wrote about. It’s called RICE. I think it stands for Reach, Impact, Confidence and Effort. They decide what they're going to work on by, number one, how many people are going to use this? Is this something that only 1% of our users are going to use or 100%? Impact, which is exactly what you’re talking about. How much bang am I going to get?

Effort, sort of divide this all by effort. How much time does this take? Is this something we can build in two months or a year? And then confidence. Is this just a wild guess or are these numbers pretty concrete?

I love having that framework. Even if you don’t write it out and do the equation, but having something like that in your head where you’re constantly trying to think “How much bang am I going to get for my buck?” makes so much sense, even if it’s not visible from the outside in and people might question why you’re working on this particular thing.

Taylor Otwell: 1h 0m 37s

I’ve never heard about that. I’m going to have to look that up, because that’s an awesome way to think about it. It’s very similar to how I’ve tried to think about things. Surprisingly, a lot of developers don’t think that way.

When you hear it, it sounds like, “Oh, yeah. Of course you would think that way.” But so many people especially neglect what it’s going to do for the end user. Developers are very focused on, “Here’s my Holy Grail contribution to the development world and look how clean and shiny the code is,” and they lose track of, how does this actually improve people’s lives at the end of the day.

Courtland Allen: 1h 1m 16s

Such a simple question but surprisingly easy to forget to ask, for some reason.

Taylor Otwell: 1h 1m 19s

Yes.

Courtland Allen: 1h 1m 20s

So you’re at this point now, you’ve been running Laravel for close to 10 years. It will be 10 years in another year or so. You’ve got a whole list of ideas that you want to work on. Is this a lifelong project for you? Is this something that you see yourself doing 10, 20 years from now, and if so, what does that future look like?

Taylor Otwell: 1h 1m 37s

Man, I don't know. Part of it is, I’m interested to see how the story ends myself. I feel like it’s come so far and I don't know what the future is going to hold. Right now I take it a year or two at a time.

For me, right now, sitting here I feel confident saying, “Yeah, Laravel’s going to be a thing in another year.” I don't know what four or five years down the road looks like, because things can change really fast.

But for me, this is what I’m focusing on for the rest of my professional PHP career. I think once Laravel’s done I will probably move on to something else. I don't think I’ll start another PHP thing. I think I’ll move on to something entirely different.

Courtland Allen: 1h 2m 21s

Do you think Laravel could survive without you? Is it something that’s inherently tied into Taylor Otwell at this point, or is it something that can grow and thrive if you one day decided to move on to something else?

Taylor Otwell: 1h 2m 31s

I think it would survive. I think there is an element of personality cult around Taylor Otwell and Laravel. But I think there’s enough talented people in the ecosystem. Laravel, the open source project, I think would continue for years to come, really. There’s enough talented people that could move it forward.

Courtland Allen: 1h 2m 51s

I think about the same thing with Indie Hackers. What would I do if I wanted to leave, which I’m not planning to do any time soon but how do I get it to not be as focused on me? How do you identify talented people from the community to take over different parts of it?

Then also, to your point, what do you do next? Do you double down on the knowledge you already have? You’re an expert PHP developer. You know so much about the ecosystem. Or do you look out for a new fun opportunity because it’s something you haven’t done before? It sounds like you’re leaning towards the latter. How would you even decide what to work on next?

Taylor Otwell: 1h 3m 25s

I don't know. I think I’d probably still be involved in technology. I don't know what that looks like. There’s other things I would like to do that aren’t technology related. I think it would be cool to have a barbershop. I think it would be cool to do a lot of stuff that’s not even related to programming.

I think I’ll have to cross that bridge when I get there. I think Laravel would look different. When I think about something like Rails and DHH’s involvement in Rails, which I think you could see as a parallel to my involvement in Laravel, I see DHH as not as invested in Rails anymore as he used to be, and I think Rails feels different because of that.

So I think any time you have a founder that’s very involved in starting the product, it’s hard for them to step away and for the product to retain the same identity and feel the same way. I think Laravel would be different. What I would do afterwards, I don't know. It depends how long it lasts.

Courtland Allen: 1h 4m 25s

Yeah. What about now? I wonder what’s motivating you, because I have a lot of conversations with founders. Sometimes I’ll talk to people on the podcast or I’ll talk to them after the podcast. Sometimes I’ll get coffee with people. Oftentimes people who run successful businesses get to a certain point where they’re like, “Well what’s the point? I have more than enough money and income coming in. I like what I’m doing theoretically, but I also have acclimated to it.”

Then I talk to other founders who are super excited about what they’re doing. They love every single day of it and it’s their life mission. What keeps you going with Laravel in the present? Why do you wake up and keep doing this every day?

Taylor Otwell: 1h 5m 0s

I think for me it’s just chasing that next big thing. It’s a rush. Chasing that next idea now, to have the next big cool announcement at Laracon, is a driving thing for me now. Trying to see if I can find something even cooler than what we did last year is just a personal challenge at this point and just a game to where I want to wake up and do it. I think that’s part of what’s motivating me right now is seeing how far we can take it.

Courtland Allen: 1h 5m 36s

We’ve come full circle, back to the topic of motivation which I guess is never something that doesn’t matter. A lot of people listening to this podcast are fledgling indie hackers. They’re working fulltime jobs as software engineering. They’re thinking about trying to start something.

They’re not quite sure where to start. They’re not quite sure how to get something off the ground. Taylor, you’ve learned a ton. You’ve shown a ton of advice on this episode. If we zoom out and you had to say something to this group of people as a whole, what do you think they should take away from your story?

Taylor Otwell: 1h 6m 4s

I would say whatever you’re doing, put your whole heart into it and love it and invest in it and care about it. I think if you do that and you really put your passion behind it, I think things can work out. Even if they don’t, you’ll grow a lot as a person and you’ll learn a lot of valuable lessons that you can take into your next adventure and keep trying.

Courtland Allen: 1h 6m 26s

Put your whole heart into it. Taylor Otwell, thank you so much for coming on the Indie Hackers podcast.

Taylor Otwell: 1h 6m 31s

Yeah, thanks for having me.

Courtland Allen: 1h 6m 33s

Can you let listeners know where they can go to learn more about Laravel and Forge and all the products you’re building?

Taylor Otwell: 1h 6m 39s

Just to laravel.com. You can go there and there are links there to all the various tools there on Laravel. If you want to follow me, it’s twitter.com/taylorotwell. It’s where I do most of my social media engagement.

Courtland Allen: 1h 6m 53s

Alright. Thanks again, Taylor.

Taylor Otwell: 1h 6m 54s

Alright. Thanks for having me.

Courtland Allen: 1h 6m 56s

Listeners, if you enjoyed this episode or you learned something new from Taylor, I’d really appreciate it if you took a minute to let him know. He is @taylorotwell on Twitter, so feel free to send him a tweet and include me as well. I’m csallen on Twitter.

Also, I have a newsletter for the podcast where I share my thoughts on each new episode. You can subscribe at indiehackers.com/podcast. Thanks so much for listening, and I will see you next time.