Taylor Otwell - founder of Laravel

They even had their own conference and launched their 1st paid product, Forge. By 2017, he'd left Use Escape and was making a $1,000,000 a year. By 2022, it was $7,000,000 a year. By 2024, he'd reached his goal and built the most popular PHP framework in the world. He'd kind of become a version of DHH himself, someone that other entrepreneurs aspire to be. But next, he did something entirely unlike DHH. He announced that he'd raised $57,000,000 from VCs.

You know, we had just done a lot of things, plus 25 open source packages. So I only had, like, a few ideas left that were, I thought, really interesting but also extremely challenging, one of which was Laravel Cloud, and the other one is, Laravel Nightwatch, which we debuted at Laracon AU. Laravel Cloud Yeah. In contrast to forge is more like a fully managed hosting platform for Laravel. So with Forge, you have to bring your own AWS account, your own DigitalOcean account, and we provision servers on those accounts on your behalf.

With cloud, everything is fully managed. It's like a Vercel or a Heroku. And to build that, like, that takes a lot of resources. It takes a lot of people, just staff, infrastructure staff, engineering staff, support staff, marketing staff. And I had always run Laravel I guess there's different ways to, like, bootstrap a company or or how you wanna operate it, but I had always run Laravel as lean as possible in in order to maximize, like, profit margin, basically.

Expenses were really low to maximize just, like, income. And I think a lot of boot strappers probably operate that way because it's, like, that's the point, right, is to, like, build this really nice income for yourself and have freedom and stuff. And to build things like Laravel Cloud, you can't really operate for, you know, your own personal bottom line. Like, it would have required basically running the company at least breakeven, but maybe dipping into, like, negative, you know, losses a little bit for the 1st couple years. So, you know, to get back to kinda, like, circle back to the question of, like, why do this?

I felt like it was personally like, some people might see it as like, oh, you're kinda, like, selling out by raising money. But I see it more as, like, selling out if I didn't do it in a sense. And this sounds weird, but if I didn't do it, I would basically just be coasting, like, for Laravel as a community, as a product. I was not going to build anything else super ambitious because I just it would the rest of the ideas were just too big for me to tackle bootstrapped. Yeah.

So I saw that as a disservice really to the, like, 13 prior years of work and people that had come along on this journey and, like, bet on Laravel either individually or as a company or whatever that they were gonna build their business or their life around this tool. And for me to just be like, you know what? Like, I'm good. My life is cushy. I'm gonna go chill pretty much, and, you know, like, we'll just kinda let this thing peak and sort of, like, maybe slowly decline over time, you know, as things do.

I saw that as, like, kind of just kinda wimpy, you know, and, like, something I didn't really want to do after all these years. And I'm still pretty you know, I'm still relatively young, at 38. And Absolutely. I felt like, hey. Like, why not go big?

Whereas on cloud, we are actually running all of this infrastructure in, you know, in our own AWS sort of infrastructure, our own Kubernetes clusters, our own sort of database setup, all of that. And if something goes down, it's very much on us to, like, get it back up now, as well as, like, we're paying the bill for all of those servers to Amazon. So when our Amazon bill is, you know, 1,000,000 of dollars, that, you know, it's just it's just a bigger undertaking versus forge where we're not really responsible for any of this infrastructure at the end of the day. We're more just like a provisioner and like a a admin tool for managing these servers, but they ultimately exist on other other people's infrastructure platforms.

I wouldn't say it's, like, heavily bureaucratically structured, but it's a big change for where we were basically totally flat where it was just kinda me, leading the team, and then everyone else was sort of on the same level and did the same thing, because it was, like, all developers and one customer support person. That has actually been better overall, I would say, because, you know, you just have more help and you have you don't have to keep as much stuff in your head all the time. You can lean on people to just execute really well, especially as we've tried to hire. Obviously, you wanna hire really great people. I think we've been pretty successful in doing that this year, and that makes your life a lot easier as well, where, you know, if we have a really great product manager, we have a really great designer, I can just really let them execute at what they're best at, and that makes life easier for you, you know, as a leader.

Things that are harder as we've grown the company. And, again, I don't really think this is, like, related to VC funding as much as it is just, like, growing a company in general. I would say growing to 50 people while being remote and while operating in a very technical product space can be challenging to get everyone up to speed in terms of what we even do here, to some extent. You know, like, why do people even sign up for forge? What does it do for you?

What is a server? What is NGINX? What is MySQL? You know? Those those are, like, complicated technical concepts. And if you're coming in either on support or marketing or or business operations and you're not deeply entrenched in that world, it can be overwhelming and tough, I think, to get up to speed.

So I had spent 2 days banging my head off the wall trying to build it directly with Okta. And then with Work OS, I then have, like, many, many SSO providers, like, supported instead of just 1. So yeah. Like, for me, Work OS is one of the nicest developer experiences I've encountered in the last, like, 5 years, probably. And it's so surprising because a bunch of the developer team are execute hub and therefore are very good at the job.

And I think that's, like, that's part of the debate online right now about, like, what's better, like, working in the office and working remotely. And I think they both have pros and cons, but it's just one of the challenges we faced, I think, is, you know, just all mobilizing as one unit while being spread around the globe is challenging.

Definitely, I'm very hands on jumping in on how those products work. Cloud and NightWatch, that being said, are the first products that I have not actually coded kinda from the ground up myself. So, like, we actually have, you know, more of a full dev team, product manager, designers on staff, and I'm definitely making sure everything is on track, and I have my hands in how all this stuff works. But the dev teams are really the ones, like, boots on the ground, writing the code for these products, which is very new for Laravel and for me.

And so if something feels, like, confusing to me, to me, it's like a really bad sign that other Laravel developers are going to be actually very confused by this. Yeah. So I try to just, like, I click through the product basically every day and just say, like, what feels awkward? What doesn't quite feel smooth? What doesn't make sense?

How would I do things differently? And a lot of that comes boils down to, like, either me kinda saying, hey. I think this is a little bit clunky. What if we did it this way? Or maybe me sketching out something, like, on paper or in Excalidraw online or something.

It's, like, hey. What if we did things this way? A lot of it is just honestly just making sure we're sort of, like, on the right track and prioritizing what our feature set should be either at launch or 3 months down the road or 6 months down the road. Like, what are actually the most important things that I think we should focus on? Because there's there's a lot of things we could do.

Right? And it's just a matter of kinda, like, keeping our scope on track, keeping our roadmap on track, and, you know, kinda making those decisions on, like, what we actually need to be focused on.

We needed to improve the ORM. All a lot of that early foundational work was done during that time. And then going forward from there, a lot of the work is borne out by just, like, problems we encounter as we build things like forge and Envoy or in vapor. We see, like, the pain points in Laravel, and we're like, hey. We could probably write a package to make this better.

We could add a feature here to make that that better. So that drives a lot of it, but these days, you know, a a lot of features are also driven just by community PRs on Laravel, the framework. So every morning I start my day on GitHub. I spend, like, you know, probably an hour to an hour and a half just going through pull requests, closing, merging. So lots of stuff gets into the framework that way as well.

But I still see that as when when I review a PR in GitHub, I actually do try to sniff out, is this something addressing a problem someone actually encountered, or is this sort of trying to anticipate a problem that someone thinks people might have? And I do close PRs typically if they're sort of, like, guessing at a problem, if they're like, hey. I think it might be useful if the framework could do this. You know? And it's not like, hey.

We had this problem at work and blah blah blah, and this is this is what we came up with to fix it. That, to me, holds, like, a lot more weight than just sort of designing features in a vacuum.

That's very much in contrast to at Rails actually. Right? Where, like, DHH is more like, he would more prefer to do most things in in Ruby and write just a little bit of JavaScript, whereas we're we're a little bit more, like, fully embracing of React and Vue. I think it helps I I think it just helps in terms of focus. You know, like, you're not constantly distracted by the winds of change in the tech industry, and things come and go, you know, like the ways we build applications, whether it's SPAs or different ways of architecting APIs or GraphQL or different databases even, you know, come and go very quickly, in sort of that kinda like Silicon Valley space.

And I don't think that's all bad. Right? It's like a place where new ideas are bubbling and some of them are gonna stick and be really impactful, you know, sort of like world changing ideas in terms of how we develop apps. A lot of them are not. And that's there's no, like, there's no right or wrong, I think, in terms of if you wanna play in that world, it's like an exciting world to play in, but we've always historically focused kinda like more down the middle meat and potatoes, web applications.

We just want developers to be productive. And while we try to embrace new tools, like, you know, we're always open to that, we're not necessarily chasing the latest thing every few months. You know? I think that I always try to grind ground everything in reality, and I think this is another thing I really admire about DHH on the rail side is, like, I would prefer to, like, okay. Let's say there's a new approach to doing something or there's a new technology.

Let's try it, and let's just see, like, does it actually make it more enjoyable to build applications? Let's actually open up our editor, write some code, give it a shot, and let's just be honest with ourselves and be like, I think there's actually something to this or there's not. And, you know, sometimes there isn't, sometimes there isn't. And sometimes we make the wrong calls as well. You know, in Laravel, there's been either, like, patterns we sort of, like, adopted or promoted that sort of, like, fell by the wayside or, like, didn't serve us well or were a little too complicated or whatever, and we just kind of I think you also just have to be honest and move on from what's not working.

There's kind of another you know, just another aspect of kind of maintaining an open source ecosystem is billing being willing to, to change. You know, a lot of a lot of open source tools can get sort of calcified, and they don't really evolve with the, you know, the tech landscape, and that's something I've always been very afraid of. I've seen other ecosystems do it, where they're like, no. Like, that all that new stuff is stupid. These young devs don't know what they're talking about.

Like, we're gonna do everything our way. And it just, like, the the project just stagnates, you know, over time.

I think that's just an area I've not historically spent a lot of time with, and so don't always have the best idea of what's important to them, either from an infrastructure or security perspective, things like that. That's where outside feedback I think is much more helpful. For sort of like the hobby tier, SMB tier type of customers, I think just the overall intuition of building products. And I think it's actually fine. Like, I think, you don't always need empirical data for every single thing you build.

I think you have to develop, like, a pretty good sense of knowing what people need. I tweeted something about this not too long ago where I was like, if you feel the need to, like, ask customers, is this good? Is this good? Is this good? Is this right?

For, like, everything you build, to me, it's like kind of like a smell that you don't really understand the problem space yourself, like, really intimately and deeply. Maybe that's just my, like, naive thinking, but I like to kind of operate with a certain level of, like, confidence in building product. They're like, okay, we understand this problem space very well. We know what we need to do to solve it, and we actually have these opinions on how we think the best way to solve that is. And that's the product we're gonna build and ship, and we think customers are gonna like it because we would like to believe that we have good taste at this company, like know how to build things.

So I like to operate with a certain amount of confidence in that way. And like I said, that that gets you so far, and before you need sort of some outside feedback, but that's kinda how I prefer to operate, honestly.

So we keep that really low because I work on it every day. So it still is very curated. I think for building taste, I always try to look, like, outside of development a lot for inspiration. So, you know, in the early days, that was either through, like, art or music. Especially, I think people I'm drawn to people that are, like, obsessively focused on their craft. So, like, things that come to mind are like that documentary, Jiro Dreams of

I mean, even, like, Jonathan Ive at Apple. Right? Like, big hero have emailed Jonathan Ive. He actually responded and said thanks, which I was super pumped about. That's super cool.

Just people that are just, like, really meticulous and dedicated, have always been inspirations. And I've tried to let that sort of influence me to have, like, a high bar for how Laravel works, how it feels, but also for the code internally. I was always, like, obsessively focused on the code that no one sees has to actually, like, look good and make sense, and it can't be a big ball of mud under the hood Because I was using this framework, and I feel like my sort of, like, obsessive personality wasn't comfortable building a business on it if I knew that, like, inside that vendor directory in the Laravel folder, it is, like, gross in there, you know, with just spaghetti code everywhere. I just couldn't have the confidence to, like, build something on it like that. So anyway, yeah, a lot of stuff outside of coding, I would say, like, is how I kind of fed my inspiration for taste and craftsmanship.

Pre 2015 when I went, you know, full time on Laravel. So he he was actually the first person I know of to, like, sort of start running a Laravel bootstrapped company, that was making content about Laravel. And it wasn't even really Laravel and all of the other sort of, like, community stuff, like you mentioned, like Laravel news or various podcasts or even some of the conferences themselves were things that, like, when you launch an open source product or project and it starts getting popular and people come to you in the early days and they're like, hey. I wanna do this. Like, in my country, I wanna start this website about your tool.

Your default answer is usually just yes because you want more attention, like, to come to the tool or whatever it is. And so, like, if someone came to me, you know, years ago and was like, hey. I wanna start a news website about Laravel. Like, I'd be like, okay. Great.

Like, that sounds awesome. Go do that. And I didn't really give a lot of thought at the time to, like I just never expected you know, I wasn't looking ahead of 20 24 and thinking, oh, Laravel's gonna be a 50 person company and bigger, and we're gonna be building these very serious, like, cloud platform pass products. So I think, like, it was ultimately a huge benefit. Right?

At, like I guess if you had to identify, like, a downside of that or why you might wanna think about like, if you're starting a dev tool open source, you never know how it's gonna go. And sometimes, I guess, you could lose a little bit of consistency, like, across the ecosystem. Like, there's a it feels really spread out. You know? Like, you have Laravel.com.

You have Laravel news. You have Lara cast.com. And only now are we trying to sort of, like, make everything feel a little bit more like one family or, like, like, it's all related. But it was hugely beneficial to, like, the growth of Laravel, and Laravel would not be what it is, honestly, without Laracast. I think that's just, like, such a foundational part of how Laravel got popular within PHP is just the quality of the educational materials that Jeffrey was putting out there.

He was a Laravel developer at a couple of agencies, full stack dev, really talented, wrote an ebook on Laravel collections, made, really, I think, the best video course on test driven development on the internet, I would say, probably with, test driven Laravel. I think has valuable insights no matter, like, what framework you're using. It was just, like, very extensive, very practical, and well done and, like, honestly shaped some of my thinking on testing itself. Over the years, Adam and I are less collaborators and more just, like, real friends, I would say, where, you know, we talk about business. We play games.

We talk about life or whatever. We don't spend as much time collaborating on code, but we definitely talk about business a lot. I would say that the things that we have in common are this very low threshold for pain in the sense that, like, when a developer tool is hard to use, me and him both share this, like, repulsiveness that, like, kicks in at a lower bar than maybe a lot of other people where they were just, like, put up with it. There's, like, extreme examples of this, right, where it's, like, you you have some startup and there's the the classic, I could build this in the weekend with a Raspberry Pi in my garage and blah, blah, blah, blah, blah. And we have a very low pain tolerance of that type of thinking where we like things to just be really smooth, to make a lot of sense, to be very intuitive, to be very high end, to be very polished.

And so I think we sort of, like, resonate with each other on that. Adam is more perfectionist than I am, I would say, and I think he would say about himself that he holds himself and Tailwind to probably an even higher standard than I think I hold myself in Laravel, which is great, because it's like still to this day, you know, like, I want things that I ship. I want Adam to, like, like these things and be, like, yep. This is, like, a good product, or this is well designed.

And, obviously, we've both done that over the years. But, you know, like, sometimes with him, I think over the years, I've been like, yeah. You should just, like you gotta ship something out or, like, you know, he's expressed frustration of, like, hey, we've been working on this for, like, 4 months, and it's just, like, you know, eventually you just gotta ship something. I don't think we've ever given each other just, like, terrible advice though. We're honestly more, like, just friends that play Fortnite in chat business more than we are, you know, real, in the nitty gritty of each other's, like, collaboration efforts.

That's what I, like, greatly underestimated was just sort of, like, the market size more so than, like, the usefulness of the tool itself. You know, this Adam and I have always laughed about this fact about me where, like I don't know if you've seen that documentary about the guy Alex Honnold that, like, freeze free soloed

And it's just, like, Adam Lash because, like, to him, that is, like, I would never ever do that. That is extremely scary. But to me, it just, like, it just over the years, it just never registered really that, like, of course, I would, like, ship this. Like, why wouldn't I ship this? And, like, it'll be totally fine.

And, you know, we believe in the products, and they're useful, and so we're just gonna put them out there. And if there's an issue, we'll figure it out. You know? And so it's it's hard to answer because in some way, it was like I just I don't know. It's just, like, what I thought we should build and what I thought we needed to build based on the problems people were having in Laravel, and there was never this question of, like, being afraid about it or, like, you know, being scared to do it.

You know? So I don't know. Maybe it's a bit of, like, just missing that kind of fear element to putting stuff out there.

With Laravel Cloud, we've been spending tons of time with Kubernetes, with Docker, with Cloudflare, with different kind of database tech. On Nightwatch, we're spending a lot of time with ClickHouse. I'm not sure if Yeah. You dug into that much, but, The events and Yeah. Lots of events and sort of analytics being stored in there. So we we've been exploring some new stuff on our end, and, you it's been a fun year.

We want this to be the absolute best way to get started deploying Laravel products, and you can get on the waiting list for that at cloud. Larabell.com. And then Nightwatch, which kind of tells you a lot of data about your Laravel app, like your slowest routes, your slowest database queries, things like that, is at nightwatch.laravel.com. We're hoping to launch cloud in February and Nightwatch probably first half of the year, let's say April ish timeframe, so coming relatively soon.