How a Solo Dev Went From $0 to $57M Raised

In this interview, Taylor Otwell describes how Laravel grew from a personal productivity tool into a framework used worldwide, and how Forge turned that side project into a business. He explains his approach to community trust and staying true to Laravel's core users rather than chasing critics, plus why he ended a decade of bootstrapping to raise from Accel. He closes with advice for founders: solve problems you personally have, and build the hardest part first.

Hi, I'm Taylor Otwell. I am the creator of Laravel, an open-source PHP framework for building web applications. So I started creating Laravel as a way for me to build web applications faster. And it was actually not my original intention to make it a big popular open-source framework or community. And so the community's grown tremendously. We've gone from relatively a few downloads per day when I first released Laravel to now a quarter million downloads per day. Our first Laracon conference was in 2013 and we only had 90 attendees. At last year's Laracon in Dallas, Texas, we had over 900 attendees. Tons of developers around the world and almost every country in the world use Laravel to build incredible applications.

I grew up in Hot Springs, Arkansas. It's a relatively small town in central Arkansas. I was always fairly interested in computers and the web as a kid. I think I built my first website when I was about 10 years old. I think I was one of the only kids I knew that knew how to build anything on the web, which was kind of fun cuz like when you're the only kid in school that can build a website, everyone wants you to build a website for them. So, it was a pretty interesting way to grow up not being around any other techy people or kids or startups. It's a very different world programming and being a developer in Arkansas than being, for example, in Silicon Valley. But overall, I think that being in Arkansas has helped me maintain a level of focus and clarity on what I wanted to build that I probably wouldn't otherwise had if I had been somewhere else. College was a good experience in a sense because a lot of my professors were very old school programmers. Some of them had worked at like NASA.

Many of them did not even use like a guy on their computer, you know, they were like very old school nerdy programmer people teaching me like core foundational programming concepts that apply across all languages. They really understood the foundational concepts of building good software which I think was extremely helpful. So when I was working just like a day job as a software engineer, I always gravitated towards building tools for the other engineers at the company. like I would always um try to get side projects or like get assigned to build things that would make us as developers more productive. So I was always finding ways to like optimize our workflow and I always found that like actually more interesting than what the business was about. I had some businesses that I wanted to build some startup ideas and PHP is a web programming language that is very easy to deploy out onto the web. It's easy to run and maintain and to ship. I needed sort of like a toolkit to build these web applications more quickly. And there was other ways to do this in PHP. There was existing frameworks that were already out there. Many of them were kind of dated and maybe getting a little older. And I thought that I could build a little bit more modern take on how to build web applications in PHP.

Once I was almost done with it, I thought like, hm, this is actually kind of cool and maybe other people would want to use Laravel to build things. So that's when I decided to open source it, put documentation around it and try to, you know, share it with the world. And for the first 3 years of Laravel's life, I made no money on Laravel at all. It was totally open source. I had sort of written my own scripts to automate this on my machine, but I decided to build user interface around it and build like a product out of shipping Laravel applications to the web. And I called that Laravel Forge. And I released that in 2014. And honestly, I had no idea how it was going to perform, like how many customers it was going to have. I still honestly expected that I would need to work a day job. Even after I released Forge, but within probably a month or two of releasing Forge, Forge was making more money than I was making at my regular job. I was having to do customer support and I was having to fix bugs.

Then I was in a situation where it was like very obvious I could not do both things at the same time. About six months after launching Forge, uh January 1st, 2015 was actually my first full-time day working on Laravel where I sat down in my home office, which was basically a spare bedroom at the time.

And I was working on Laravel all day that day and have ever since. The first couple of years, I was the only person at the company. So I wrote the front end, I wrote the backend, I did the customer support, I did the docs, I did everything. And we made our first hire.

I think around 2016/2017 I hired another engineer. This is actually one mistake I made is I put off hiring too long. This may be common for other open source developers where when you create something open source or you create a product you're like extremely protective of it like it's your you know it's it's your thing that you've created and you're scared that anyone's going to like come in and mess it up or like mess up your vision for it. And so that made me very hesitant to hire but then once I did I was like oh wow I should have done this a long time ago. Running a company by yourself can be stressful and a bit lonely. I always felt like Laravel and PHP was a bit of an underdog and web development. Even when I created Laravel in 2010 or 2011, PHP was already seen as like not the most glamorous web language. That was nothing new. Like even back then, I think that underdog mentality of like, okay, well, I actually think there's something really great here and I think this is a fantastic way to build applications really quickly, it really motivated me to like prove it over many years. And all of them in a way were sort of born out of my own like desire to make things easier for developers.

I think opensource is powering almost every business in the world at this point. It's become the norm. You can inspect it and read it and you can even contribute to it. It's almost like the first thought is to release it on GitHub. You know that that's like the most obvious thing you would do if you're running an open- source company.

The most obvious risk is just other people taking your open source code, you know, and building uh alternatives or competitors built on pretty much everything you've done over the last decade or however long you've worked on your project. I think the way you avoid that in many cases is how you run the community and how you interact with the community. I've always tried to stay extremely receptive to community feedback. I'm still very involved. I actually still the first hour and a half of my day is getting on GitHub and managing pull requests to the open source Laravel framework. I'm actually still the only person that does that at the company. I think if you develop an attitude where you're not listening to the community and they feel that that's when like you start getting grumblings in the community, people get unhappy and then you like run the risk of a fork in the open source project. Forks the project, renames it.

This is now a better, more community-friendly version of your product. That's the biggest risk. When you're building open source software, there's a lot of voices. They all have an opinion on where you should take um the framework. And some of them are coming from a place of like genuine uh constructive criticism, and some of them are more like just sort of like haters of your project. One really great piece of advice that another open-source founder, Adam Wavin from Tailwind, gave me was that just like when you're in a band, say you're Metallica or you're Taylor Swift, if Metallica starts trying to cater to like Taylor Swift fans, then they lose all of their core fans. In the same way, like if Taylor Swift changes her core sound that her fans love and that they come to her concerts to hear, she upsets that core fan base. And so play the hits for your fans.

They love what you build. They're the core piece of your community. I think it can be very tempting, especially when other like smart people try to tell you, "Oh, I think it should work this way or I think you should do this." It can be so so tempting as an open source maintainer to like go down these rabbit holes of like, "Okay, well maybe if I add this feature then like this group of people will finally use Laravel and start building with it." In my experience, the people that like sit on the sidelines and sort of just like shout criticisms at open source projects, if you were to follow their feedback and like jump through that first hoop of what they want you to do, there's always like another another like carrot on a stick they're dangling out there, they're like, "Oh, thanks for doing that, but I don't like this either." And like if you change this, oh, that would be great.

You know, you keep jumping through the hoops, but they never actually like become a user of the product, which it can be incredibly frustrating. So listen to just your core audience that's already building with Laravel and they love what you're doing and they have businesses on Laravel. It's important to hear outside feedback too, but just use caution with how far you stray from like your core beliefs and what you think your product needs to be.

I had never really considered taking outside investment before Excel. I used to get emails about that pretty frequently and I would always just delete them which Excel found hilarious.

The reason for that honestly is just like we were happy at the company as just a small team working on whatever we wanted to work on, not wanting someone to mess up what I had built. So that fear of messing up everything we had put so much work into made me hesitant in both regards for hiring and raising money, especially as developer expectations have risen quite a bit since 2011. They expect it to be really really good. The bar just like keeps getting higher for how polished and how productive and how great your products have to be. And I knew that if we wanted to like take Laravel to the next level, it was going to take a lot of work and it was going to have to be some pretty ambitious projects that were far beyond anything we had built before and it was going to take a much bigger team to build these things. And so that's what sort of led me down the path of raising money with Excel. It's been a gradual process changing from a solo developer to running a bootstrapped company to now trying to lead a VCbacked company. And they all work really differently.

Honestly, when I was bootstrapping the company, it was extremely flat. But at the same time, when you go from 10 to 50, there are just new new layers of organizational hierarchy and management that comes with that. But I think what hasn't changed is our core mission to build awesome developer tools. Like that's still the mission we're on. And so like our underlying mission of building great products, nurturing a really great community with community events like Laracon and Laravel lives and meetups, all of that is the same.

But I feel like I should have grown this kind of team much earlier, but I was scared to and I didn't know how to really. and bringing on people that can help us build these products and help us grow this community beyond what I'm capable of myself. And I'm super excited to see where we can go in the next few years.

When I first released Laravel, we had, discussion forums about the framework where people could ask for feedback or give ideas. Every day I was in those forums myself, like answering questions, asking for feedback on new features and I always try to be really involved in the community early. We built sort of like a very friendly, welcoming vibe where everyone can pitch in and get help. And there wasn't a lot of like posturing or judgment on what stage people were at in their journey with Laravel or with development in general. We were just all trying to help each other and kind of be a part of building businesses and building products where people feel like they can come and learn and and build something cool and they have other people kind of have their back.

Everyone wants to be a part of something like they want to contribute to something and it if they feel like they can actually have an impact on the software which you can I think for a lot of people that creates a very strong like sense of belonging and community. If you were to pull up a contributor list of Laravel, like their name is now on the list forever. I think of people like Jeffrey Wei that founded Laracas creating video content and educational material about how to use the framework. He was actually the first person to build a full-time career around Laravel even before I did. By embracing and encouraging those relationships, I think it helped build a really vibrant, strong community. And it's good for us as well because people are constantly making content about, you know, our framework.

I've always said I see myself as a very average developer, which that sounds bad, but I think it's actually been a really good thing because there's a lot of average developers in the world, and I feel like I build tools that helps the average developer do their job quickly.

And that is just statistically a lot of people. When you have an opportunity to build tools that people use pretty much eight hours a day at their job, then you're making a huge impact like on someone's personal enjoyment of their life, I think is really interesting and amazing and like this huge privileged and it's something very few companies and software tools really get to do. The most common advice I give first is try to solve a problem that you yourself have. These are the problems that you're going to understand the most deeply.

Everything I've built at Laravel was essentially solving a problem that I had encountered in reality. Many of them are things that I needed. And I think that if possible, you should try to build a business that way to where you are a customer yourself. The second piece of advice I would give would be do the hardest parts first. This is something that I think a lot of web developers that are trying to start new products get wrong. While they're the most motivated at the beginning of that idea, they build a lot of like of the easy parts. Like they might build, oh, I'll build the login form first. And you spend a month or two building all of these really easy parts, and you're kind of procrastinating in this like clever way of tackling the core like hardest problems you need to solve to really make this product great. And then once you've wasted all of your like initial enthusiasm kind of dancing around, you sort of lost your momentum, especially as a solo founder. And so for me, when I have a new product idea, I absolutely try to build the most impossible part first. Like the part I'm not sure that I even have the skills to build or understand or whatever. I'll just try to get that working. Even though it's the hardest part, if you do that at the beginning, you're the most motivated.

And if you crack it and you nail it, the other part is just like it's all downhill from there as far as building the product. If you fail, you would you would rather fail earlier, you know, like building the product. I would much rather fail after 2 weeks than wasting 3 months. So do the hardest part first and try to solve problems you deeply understand being customer number one yourself.