Taylor Otwell - founder of Laravel
Laravel creator Taylor Otwell explains why raising venture capital was the ambitious choice after 13 bootstrapped years, how he protects the framework’s taste as the company scales, and why enduring tools begin with problems their builders understand firsthand.
Taylor Otwell released Laravel in 2011 and built a profitable ecosystem around products including Forge, Vapor, Envoyer and Nova. In 2024, after years of bootstrapping, Laravel raised $57 million to pursue Laravel Cloud and Nightwatch.
Taylor discusses that change in risk and responsibility, his transition from sole product builder to company leader, the value of real-world constraints, the outside influences behind Laravel’s craft and the unusual lack of fear that helped him ship.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why raise venture capital after building Laravel profitably?
I had built nearly every product I could imagine funding through a very lean, profit-focused company. The remaining ideas — especially Laravel Cloud and Nightwatch — required infrastructure, engineering, support and marketing at a scale that could mean years around break-even or at a loss. Coasting would have underserved the people who spent 13 years building their work and businesses around Laravel; raising let us attempt something ambitious again.
Why is Laravel Cloud riskier than Forge?
Forge provisions servers inside a customer’s AWS or DigitalOcean account, so the underlying provider and customer ultimately own the infrastructure. Cloud is fully managed, more like Heroku or Vercel: Laravel operates the Kubernetes clusters and databases, pays the AWS bill and carries the responsibility when something fails. That changes both the capital required and the operational stakes.
What became easier and harder as Laravel grew?
Product managers, engineering managers and team leads let me delegate to excellent specialists instead of holding the entire company in my head. The harder part is bringing roughly 50 remote people across many time zones into one tightly aligned unit. Technical products add another onboarding burden: colleagues in support, marketing or operations must learn concepts such as servers, Nginx and MySQL before the customer’s problem becomes intuitive.
How has your role in building products changed?
Before funding, I prototyped almost every commercial product and co-wrote Nova. Cloud and Nightwatch are the first products I did not code from the ground up. I still use the builds daily, flag awkward interactions, sketch alternatives and make scope and roadmap decisions, but full product teams now write the implementation. The job is increasingly to protect the experience and choose what matters.
Why must framework features come from real work?
Laravel’s foundational features emerged from applications we actually built at UserScape, and later products such as Forge and Vapor kept revealing new pain. Community pull requests carry more weight when they solve an encountered problem rather than anticipate a hypothetical one. That discipline limits feature design in a vacuum and helps Laravel adopt useful ideas without chasing every short-lived industry trend.
How do you decide what customers need?
Years of building Laravel applications provide strong intuition for hobbyists and small or medium businesses. Constantly asking whether every detail is good can signal that the team does not understand its problem space deeply enough to hold an opinion. That confidence has boundaries: enterprise infrastructure and security are outside much of my historical experience, so that is where direct outside feedback becomes much more important.
How did you develop Laravel’s sense of taste?
I looked beyond software to people obsessively committed to craft: Jiro Dreams of Sushi, Dieter Rams, Jony Ive, excellent writing, art and music. That shaped a curated framework where the public API and the unseen internal code both have to feel considered. I still personally manage framework pull requests and keep the queue small because consistency comes from applying that standard continuously, not writing it down once.
What did the wider Laravel ecosystem contribute?
Early on, the sensible answer to anyone offering a news site, conference, podcast or educational product was yes. Laracasts in particular became foundational: Jeffrey Way was working full-time on Laravel education before I worked full-time on Laravel itself, and the quality of that material drove adoption throughout PHP. The trade-off is a scattered brand that the company is only now trying to make feel like one family.
How does a perfectionist actually ship?
Perfectionism can become endless polishing, so at some point the answer is simply to put the work out. I also seem to lack some of the fear that stops other builders. Running a platform responsible for hundreds of thousands of sites felt less like a terrifying bet than the obvious response to a known problem: ship the useful thing, trust the product and fix issues when they appear.
What is your advice to a DevTools founder?
Solve a problem you understand because you experience it yourself. That proximity produces more nuanced and considered work than choosing an abstract market and guessing at its needs. Scratching your own itch is not the only way to build software, but it gives an open-source or developer-tool founder the strongest foundation for useful product judgment.
Links & references
- Laravel ↗
- Laravel Cloud ↗
- Laravel careers ↗
- Taylor Otwell on X ↗
- Adam Wathan on X ↗
- Michael Grinich ↗
- Ostap Brehin ↗
- Hank Taylor ↗
This episode is brought to you by WorkOS.