What's up, everybody?
This is Cortland from IndieHackers.com, and you're listening to the IndieHackers 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 do they get to where they are today?
How do they make decisions, both in their companies and in their personal lives?
And what exactly makes their businesses tick?
And 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.
Hey, thanks for having me.
Glad to be here.
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, backend web framework on GitHub, too.
It's got more stars, even than Ruby on Rails.
So 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?
Laravel ecosystem does a little more than $3 million a year in revenue.
That's crazy, especially for an open source project.
Yeah, pretty wild.
And you're not just working on Laravel, the framework itself, but you've also built kind
of a suite of products on top of Laravel.
So you've got products like Spark, Nova, Envoy and Forge.
How much revenue are these projects generating?
Every product besides my latest one that I just launched in July, Laravel Vapor, has
made over a million in its lifetime.
So I have different kinds of products.
I have a couple of SaaS products like Forge and Envoy.
Forge makes a couple million actually a year.
Envoy is probably close to like a half million a year.
And then the other one-off products, things like Nova and Spark, I don't really keep track
of what those do a month anymore.
But over their lifetime, they're both over a million dollars separately.
And 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.
So you've got LaerCon, 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've really done it all.
How big is the team?
How many co-founders do you have?
How many employees are working with you?
So from 2014 to 2017, it was just me.
And LaerVille was making over a million dollars a year before I brought anyone on.
And then in 2017, I brought on Mohammed Saeed.
And 2018, I brought on a guy named Dries Vintz from Belgium, who's been around LaerVille
for a long time.
And then our latest hire this year is James Brooks from the UK.
So it's me and three other developers right now.
And you started LaerVille I think in 2010.
So the vast majority of this time has just been you, by yourself.
And like from 2010 to I started working on LaerVille, like the fall of 2010.
I launched in 2011.
And from that time until like 2014, it was basically just open source.
Like I wrote an ebook.
And I think it made like 60 or $70,000, which was awesome.
I think I did that in like 2013 or 2012.
But for most of the time, I had a full time job.
I worked on LaerVille, either when my job allowed me to because we were building stuff
on LaerVille for part of it, or at night, you know, so I had a lot of late nights.
But for the most of that time, I was not making, you know, any life changing amount of money
from LaerVille.
It's pretty crazy if you think about the amount of impact per person, with LaerVille just
being 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 really the backbone of the entire PHP ecosystem at this point.
What kind of background do you have to have to build something like this?
Were you like a computer science whiz kid growing up?
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 like routers and switches and
stuff like that.
So like, for all I knew coming out of college, I was going to be a network admin or something.
And then a company called Arkansas Best Freight here in Arkansas, they came to the college
to interview seniors or whatever that were about to graduate.
And I interviewed with them and then I got a call back to go for an onsite interview
at their place and they ended up hiring me.
And what's cool is actually for every new hire they bring in, which they almost only
hire people straight out of college, they put them through six months of computer programming
training.
And honestly, they start like pretty much at the beginning, I would say like they don't
assume all that much about your computer programming experience.
So like they started us on classic asp.net, COBOL, like all the languages that they used
there at the company.
It's really, it's like a hundred year old company.
So there's a lot of legacy code as well.
Yeah, COBOL sounds old.
Yeah.
And so that's really where I like cut my teeth in terms of programming and I don't really
consider myself like I'm not like a math whiz or like any, I'm not really a whiz, particularly
anything.
I think it's just, I think what makes Laravel and I think that contributes to actually
making Laravel better in a way because the framework was made very accessible.
It was made to do things very simply, very quickly, whereas, you know, maybe if I would
have been smarter, it would have been like harder to use or something, but I don't know.
I was, I just kind of view myself as an average Joe developer that makes tools that appeal
to, you know, the average other developer.
And I think that just sort of has mass appeal.
What about on the business side of things for you to start an open source project that's
grown to generate many millions of dollars and revenue every year.
It's pretty rare.
Had you started any companies before Laravel?
No, they would Laravel Forge was the first business I'd ever started really.
So yeah, and I don't, you know, Laravel had a pretty big following, which of course makes
it a lot easier to launch a business when you've built, when you've already like shared
a lot of value and built a big like 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, that was my first startup really.
So average Joe developer, zero business experience, and yet here you are today.
I guess that means you've learned basically a ton on the job.
And I think you're really the perfect person to share a lot of these learnings because
this podcast is basically listened to by a lot of people who were you 10 years ago, developers,
software engineers who really just want to quit their job or start a side project that
makes money and basically, you know, make a living doing their own thing the same way
that you have.
So maybe that's the best place for us to sort of jump in.
I think a lot of people get started, you know, 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?
It was a lot of I want to be my own boss.
I had a young family like I was pretty newly married and we were living in an apartment
and we were about to have our first child and I just wanted to be able to like have
more freedom to set my own hours, be able to work from home, be able to kind of move
wherever we wanted without being tied down to any given location.
That was a lot of the drive behind building Laravel and like, you know, when I first
started Laravel, the goal was, OK, I'll build Laravel as sort of a stepping stone into launching
these other business ideas that hopefully will come to me.
I didn't like have any great ones at the time.
And then like after I built Laravel, it took off to such a point where like that became,
you know, the business, which I didn't expect at all at the time.
But I became so kind of consumed in maintaining Laravel and promoting Laravel that that really
turned into my my main focus.
One of the biggest challenges early on and there may be five or 10 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 of 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?
I think a lot of it is because Laravel at the time I scoped it pretty small.
When Laravel first came out, it looked a lot different than what Laravel looks today.
It was much simpler.
There was a lot less features.
It just was a lot smaller of a task.
It's not like I started from nothing and then built what is Laravel 6.0 today, you know,
and release that when it first came out, I called it actually a micro framework.
So I think part of what kept me motivated and able to finish it was just because I kept
it pretty tightly focused and I didn't have a lot of like feature creep and scope creep
that made the development process drag on like 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.
And honestly, a lot of the stuff I've launched has been kind of like that forge, you know,
there's a lot of stuff we could have done at the launch that we didn't do.
But we just kind of built something that solved the immediate problem and got it out there.
So I guess a lot of it, what I'm trying to say, a lot of it is being able to see like
where's at what point is something good enough to launch versus like incomplete or too much
or whatever.
You know what I mean?
Like a lot of people, a lot of people air on like one side or the other.
Either they launch something that's so bare bones that like it's not even useful.
You know what I mean?
Before they launch, they get so bogged down in like perfecting everything, adding every
feature they can think of that eventually you just kind of lose interest or you burn
out on it or it gets too complicated so you just feel overwhelmed.
So finding that middle ground of like 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 really key to like finishing something.
Yeah, it's a super difficult challenge.
My favorite story here is an episode I recorded a while back with Chad Pytel of Thoughtbot.
And Thoughtbot builds products for other companies, oftentimes early stage companies and the feedback
they most often give to their clients is hey, you don't need 80% of the features you think
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.
And they're always 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.
And I guess you've really maintained that balance to this day with your newer products.
Yeah, and I think one thing that helped 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.
And I know if you've listened to me give other talks or on podcast 4, I've said that a lot
where a lot of the stuff I built was like scratching my own itch.
And I think if you're building a project that is scratching your own itch, you know when
the itch is scratched.
So defining the scope is a lot easier that way.
I did the same thing with Andy Hackers.
So with you, you needed a PHP framework for yourself and 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 out all that great, so I switched out.
But with Andy 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 Andy
Hackers were starting their businesses and the ideas they came up with and how they were
paying their own salaries.
And there wasn't anything like that out there.
So I needed to build it.
But of course, there's challenges with scratching your own itch.
In my particular case, it was once I had that business idea, I no longer needed any hackers
to solve that problem for me.
So suddenly, on launch day, I'm already in the place where I'm building for other people
and 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?
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 on stuff like Forge, I just tried to rest in the fact that, like
I said, I viewed myself as an average developer.
And I was like, if I'm having this problem, someone else has to be having this problem.
Because I just saw myself as a very typical PHP developer and encountering this problem
day after day of not being able to quickly spin up a PHP server like on DigitalOcean
or whatever.
That was my take on it.
And I mean, maybe I got lucky that that happened to be true.
I don't know if there's any validity to that, but that was just how I viewed it at the time.
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?
Yeah, like I would hack on it until like two in the morning.
I think I worked on Forge for about six months before I launched it.
And it wasn't like super pretty.
I mean, it was all built using like Bootstrap, CSS.
There was no like custom design.
I wasn't a super good designer.
But it was usable.
And like the basic feature set was there in terms of giving someone an actually useful
product for the very first day.
Yeah, I remember launching IndieHackers.
And it was definitely one of those inflection points where there was a before and there
was an after.
And 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 IndieHackers, suddenly it was no longer just me, but it was thousands
of other people who had opinions and suggestions and you could send me emails and they might
have complaints.
And it was just completely different emotionally working on a product in that phase.
It was also, I think, tremendously motivating.
Suddenly, you know, I would stay up late into the night to work on something because somebody
had asked for it.
And I ended up working, I think, way harder on IndieHackers 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 world and suddenly other people started
to care?
Oh, yeah, for sure.
I mean, especially when I first launched Laravel, I was out interacting with people that were
using it in forums and chat rooms every day, really interacting with them a lot.
And yeah, it really did.
I mean, it just kind of fired me up that other people were excited about it and their excitement
kind of fueled my excitement.
So I wanted to work on it even more.
And even now, you know, like Laravel has matured a lot and changed a lot.
And now, you know, it's still it's still crazy.
Every time I go to LaraCon, like I hear some a lot of really inspiring stories from people,
some people, you know, they 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 like a Laravel developer.
I mean, I heard a story like that at the last LaraCon, actually.
So yeah, all that stuff still kind of fuels my excitement to work on it.
And definitely when you have, you know, 100,000 people or more using it, then you feel an
obligation to work on it for sure.
You've got a podcast called Laravel Snippets, and you talked about this in a recent episode
that was all about motivation.
And I think you made one of the most insightful 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
sort of external motivation, the feeling that you need to have discipline to get through
things.
You know, you owe other people something or you need to, you know, 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?
A lot of it first, when I first started was passion, but I have a decent mix of like discipline
naturally I feel like just as part of my personality that helps me push through things sometimes.
And so like one of the strategies I always take as well is like, I always tackle the
most difficult part of a project first, because I can always feel like that part of my brain
that's saying like, Oh, you know, wants to push that off and we'll get to that part later.
But for me, I just feel like I do a lot better on a project.
If I do the absolute most difficult part first, like the part I'm most unsure about, if 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, you know, a bunch of time
just kind of like building all the easy parts and procrastinating around the hard parts.
So if I'm going to fail, I would rather fail within the like the first week, you know what
I mean?
Rather than wait like a whole month or two.
That's definitely the best way to go about things.
And it's pretty amazing that that's your natural personality because a lot of other people
need to read a lot of books, think of 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 the segue is pretty 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 and a couple of weeks rather than spending months
or years of your life working on it.
What were the hardest parts of Laravel that you needed to validate in the early days?
I didn't really know if people were going to embrace Laravel.
The one part I did feel pretty strongly about was that if I wrote really good documentation
that it would gain some following because I felt like documentation and accessibility
were king basically in the PHP world.
I felt like 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 just felt like that was really the differentiating factor even above and beyond like the technical
merits of the tool really.
And to an extent, that's still somewhat true today.
Think about when Slack first came out.
There's this group of people that's like, oh, we've had IRC for 20 years or whatever.
But Slack is just easier for people and it's more accessible.
That kind of stuff just wins at the end of the day, even if IRC is more technically superior
in some way.
That was my approach to it, was making it accessible.
I think this is a challenge that everybody has, overemphasizing the product, but especially
developers.
Because we spend so much time with our noses and the code that we turn a blind eye to all
the other parts of a business or a product that make it appealing to people, that make
it work and that 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?
Starting off what you just said about, and I was going to talk about on an upcoming Laravel
snippet is a lot of developers that are trying to start businesses, they don't realize how
low their pain tolerance needs to be for finding problems.
And I've talked about this with Adam Wadden quite a bit as well.
I feel like I have a very low pain tolerance for things.
So if I encounter something that's frustrating, I want to build an easier solution for it.
So let's look at Laravel Forge, for example.
Laravel Forge, you sign up and you link your digital ocean account and it makes a server
and it installs PHP and all of that for you.
There's a lot of developers out there that when they see something like Forge, they think,
I could just use Ansible for that, or I could just use Terraform for that, or something
like that.
And it's because their pain tolerance is too high.
You know what I mean?
And they're willing to put up with hours of reading documentation, hours of configuring
YAML configuration files, whatever else to figure out some orchestration tool for their
web layer.
And some people are just like really into that.
And 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 really lower your pain threshold so that you can
kind of discover these tools that like, sure, you as a developer might say, I don't know
why anyone would do this.
I could just do this myself using XYZ.
A lot of people just are willing to pay for a much simpler solution, even if you think
it's just sort of like dumb or too easy, you know what I mean?
So with Forge, that's very much the case.
Even when I launched Forge, there was a lot of the feedback on Reddit or whatever was
like, just what I said, I mean, you could use, I could run my own Raspberry Pi in my
office and do this myself.
And a lot of the feedback, it almost felt like 50% of the feedback was like that if
you just looked at the Hacker News slash Reddit type comments.
But there's this whole other crowd out there, and that's a lot more people that are willing
to pay for a simple solution.
Yeah, totally.
And 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.
And 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 pretty fun for you.
You probably enjoy writing code.
And 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 not how consumers think.
People are generally happy if there's some sort of 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 $1 million idea.
What's your approach to deciding what to work on?
Every thing I've worked on so far has just 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, Envoyier, Spark, and Vapor were all my own original ideas.
And all of them were solving problems that I had.
So with Forge, it was provisioning servers.
With Envoyier, I needed to deploy with zero downtime.
With Spark, I just sort of took the lessons I learned building SAS back ends on Forge
and Envoyier, and then built a faster way to do that for myself because I didn't want
to ever have to do it again.
And then Vapor, I was just personally interested in serverless auto scaling deployment stuff.
I didn't want to think about servers anymore.
And so I built Vapor.
And then with Nova, that was the only idea that was actually pitched to me by a guy named
David Hemphill.
And he really sold me on the idea and showed me why I needed this when we were in New York.
And we kind of co-wrote that product together.
All of the ideas are essentially driven from my own needs.
I've never worked on, I never tried to launch a business really where I just searched for
an idea that was sort of outside of my problem space.
Okay, let's dive into this because a lot of people have trouble making this strategy work
of solving their own problems, 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.
Our other people will try to solve a problem that they care about, but it turns out that
it doesn't really resonate with other people.
So I wonder what you think is missing here and what people can do.
And sometimes solving your own problem doesn't seem to be quite enough.
Maybe my approach is just really an anomaly, you know, like I've thought about that myself.
Maybe there is no useful information to draw from that.
I think part of it though, like when people say like they don't have a problem worth solving
is part goes back to sort of that, that pain threshold thing.
And maybe if they lowered their pain tolerance a little bit, they would find problems maybe.
But I don't know, you know, it's hard for me to say, and I've wondered that myself that
maybe I don't have anything valuable to contribute to this discussion.
And why am I, you know, why, why do people want to hear my story?
But I don't know.
That's just how it's always worked for me, you know, like, and it has worked four times.
So like, it feels like there is some validity to it, but I don't know.
I mean, there are some consistent themes to the products you built.
For example, they're all built within the Laravel ecosystem on top of this framework
that you developed.
You're not sort of going out and 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.
Yeah, I mean, that's obviously very key.
And I think I, you know, I built this big audience with Laravel and doing open source
work.
And if you have any way to build an audience like that, you should definitely do that and
take advantage of it.
I do know, I've seen quite a few people try to launch things without sort of going through
that legwork of like sharing value, whether that's recording podcasts like this to share
with people and just sort of 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
like building that reputation of being someone worth following or like worth investing in
their products.
And then if you try to launch something, I do think you have a lot higher chance of failure.
So for me, I, 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,
you know, have had to kind of start from scratch with that, you know, but definitely a huge
advantage and worth putting in a couple of years actually have like time to build up
your audience like that.
It's such a crazy advantage to sell to an audience that you've built.
Yeah.
It's basically like cheating.
I mean, it's just like a huge head start.
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?
Some of it was technical things like the accessibility accessibility of the framework.
Some of them were like non-technical things, but that I set out intentionally to do like
to set, I always set out to have a really positive atmosphere around Laravel, whether
that was the way I personally interacted with people around the project or just sort of
like, you know how every kind of sort of company has like a personality, like a brand, like,
you know, Apple has a personality, Slack has a personality.
I always tried to have make Laravel have like a friendly personality, a fun personality.
A lot of that was kind of imitating people like Apple and Slack, to be honest.
And I think that was just sort of attractive for people, none of the other competing like
tools and PHP were really doing anything like that.
I wouldn't say they were really operating or viewing themselves as a product.
And Laravel was one of the first frameworks, I think, to come into PHP and really like market
itself as a product in that way.
Other people were viewing it or approaching it in this very like sterile open source fashion,
you know, like, and they would never tweet anything like fun or interesting.
It was always just like, we have a new release, here's the eight changes that were made.
You know, like it was never it was always very sterile.
So I try to make Laravel really inviting and a really fun place to be.
It's interesting to see a space where an entire market is full of products that are all kind
of the same.
You know, 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 kind of copying
the details that everybody else is using.
And then somebody comes along and does something different.
Wufu is a good example of this, the form builder space is super boring.
So Wufu decided to build something that was loud and colorful and funny, like tell you
jokes inside of the product.
And that made them stand out.
And it's super obvious, you know, 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.
Laravel changed a lot about the PHP world, really, like there was that and then no one
was really selling stuff, you know, in terms of open source and PHP, like there was this
big apprehension to, to sort of 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.
So I mean, we were kind of breaking new ground on both fronts, really.
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?
My thought with Forge was like, 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 like to me, it was like, I might as well, you know, like try to do it.
And with Forge, it was something that I felt was disconnected enough from like the open
source tooling where it didn't feel like I was making like a paid version of Laravel,
like, as if, you know, like 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.
I've spoken with a couple of different open source developers on the podcast.
So I had Evan Yuon, the creator of Vue.js.
I think he makes most of his money through donations on Patreon and maybe some sponsorships.
And I also talked to Mike Parham, the creator of Sidekick.
And I think instead of building completely separate apps on top of his framework, he
pretty much just charges for a pro or premium version of Sidekick with extra features and
better customer support and stuff like that.
So it's pretty interesting to see that you've been able to make it work with a third model
where you've got this base level framework that is Laravel.
And then on top of that, you're building these optional paid tools that 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?
I think it's very hard to make money in open source.
I'm not sure I've ever seen anyone actually make a living on pure open source donations.
So when I think about Evan Yu or myself, we're both on 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.
And I've thought about this thing a lot about open source developers and making money.
And 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 because like 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 is really the customer of your library and all these other people are unaware of
the fact that your library is under the hood.
And so they don't feel compelled to donate to that.
So I don't know.
I don't think it's really feasible.
I don't know if it's really a good idea to try to make a living off open source donations.
I think the best value in 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.
I thought about this a lot in the early days of IndieHackers because I used to ask for donations.
And it's a different space in the developer world but it's kind of similar in that people
are used to getting stuff for free.
So 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.
And so I think if you're operating in a space like this and you ask for donations, it's
just super easy for people to say no because they're used to things being free.
And the other side of this coin is I think that donations kind of obscure the value that
you're providing.
So 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 actually need it.
It's valuable.
Whereas if you're asking for donations, like who knows?
Maybe they don't even care about your thing.
They just like you.
Yeah, I think so.
I think that's good insight.
So there's some other ways to come up with ideas that we haven't really talked about
and that you mentioned on the Laravel Snippets podcast.
The first was Scratch Your Own Itch, which I think you've done pretty consistently.
Another one is that you can pick a technology that's up and coming and sort of ride a wave
of a big trend.
And I think that it's pretty interesting to see how you've done that with Laravel because
PHP, and a sense was up and coming, but also I feel like you've kind of created the wave.
Like you've revitalized PHP because when I was using it back in the late 2000s, it kind
of felt like it was on its way out.
Big time.
Yeah.
So 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?
I think because PHP was just such a huge language and I don't think a lot of people realize
how many users of PHP there are out there, especially when you factor in like WordPress
and Drupal and things like that, it's just the pie is so big, you know, that like even
a small piece of that pie is still a lot of customers and a lot of users.
I mean, I picked PHP kind of by accident.
It's not like I had some insight into that, but I just didn't hit hindsight.
I think that's why Laravel was still able to succeed in PHP and there were a lot of
people like they already know PHP.
And when I first came into PHP and I was hanging out in like PHP chat rooms, everyone was like
wanting to leave for Ruby, everybody or Ruby or like Python or something.
And you know, because they were just dying for like something fresh, you know, just like
a drop of water in the desert, basically.
And I think Laravel came along and kind of revitalized them to an extent and gave them
some fresh energy.
Yeah, 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.
But then I learned Ruby on Rails and like that was the new hotness.
Everybody was talking about it.
They had Rails Cast coming out, which are their video series for how to learn.
So it was super easy to get on board.
And yeah, it was just like 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 basically dying?
I don't know.
Again, I just think there were so many people just dying for something fresh.
And I mean, Rails was a huge inspiration for me, like personally, and all DHH did on Rails
was a huge inspiration.
But I just think there were just tens of thousands of people that were just sort of like a neglected
market, you know, that had kind of been left behind.
And they were still, they had to use PHP for their day job or whatever else.
And you know, when I just came along at an opportune time when all the other PHP frameworks
were pretty stagnant, and was able to kind of strike while the iron was hot.
This kind of plays into building an audience, I think, because you're basically giving all
these PHP developers who are craving something good, who have invested a lot of time, maybe
even years in the learning, the ins and outs of PHP, and they have lots of PHP projects,
but you know, they probably don't want to see PHP die.
And 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 does he turn that excitement into an audience that you could capture, that you could reach,
you know, again and again into the future?
One was being very engaged with them.
So I didn't, I tried not to sit in like an ivory tower and just work on the framework.
I tried to be like one of them and, you know, hang out, answer questions, just chat about
random stuff in the Laravel chat room, just off topic stuff.
And just sort of like, you know, build friendships and trust within the community as being like
an accessible person that's, you know, just trying to build something valuable and make
development fun again for a group of people.
Yeah, that makes a ton of sense.
It's going to be actually a part of your community.
And now we're starting to talk about community and not just building an audience.
And I think there's a distinction there where an audience is people listening to you, Taylor
Otwell.
It's kind of the ivory tower thing you were discussing earlier, whereas a community is
people helping each other.
So you can take a break from the 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 and they're answering each other's questions because it's an actually
engaged community.
How did you think about creating a community early on when all you had was an audience?
And is that something that just kind of happens on its own or do you have to put deliberate
thought into it?
I did try to foster it kind of in the ways I mentioned.
And then like once it gets to a certain point, it sort of snowballs with itself, you know,
it's like other community members have come in and they're now contributing, answering
questions, writing blog articles.
And then you have someone like Jeffrey Way come along who starts laracast.com and it's
really the first person to go full time on like a Laravel related business.
And he's just pumping out videos, you know, I mean, like four or five videos a week, it
seems on Laravel and now like it's sort of out of my hands in a way to where I just sort
of planted the seed and I think tried to get it started on a good path.
And then other people came in and really like, you know, tended that garden, so to speak,
and saw it to completion.
And laracast was probably the major part of making that happen really.
Yeah, it's just another advantage of building an ecosystem because 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, you know, resources and they're sort of filling
in the gaps.
Like probably there's a sense in which you could look at what Ruby on Rails had and say,
well, every single thing is going on there.
We can have for Laravel.
Now there's guides and videos.
We should have laracast, which will be like Rails cast or something.
They have conferences, you know, we should have a conference.
Is there a sense in which you looked at it as in, let's just duplicate what's going on
elsewhere?
Totally.
At the beginning, I was, you know, 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 like, uh, what, you know, what does rails
do on this problem or for this situation?
Um, so yeah, I mean, that was, that was actually really helpful and it was kind of standing
on the shoulders of giants in a way, uh, when I first started and some of looking at some
of those other languages.
So tell me about launching a conference.
How do you, how did you decide to do that?
And how do you actually get a successful conference off the ground?
So when we first started Lara con, I actually, it wasn't my original idea.
I was working at user scape for Ian Landsman.
We were building help desk software on top of Laravel.
And he was like, you know, this was 20, I guess it would have been winter 2012 cause
our first conference was 2013.
And so he's like, Hey, I think we should do a conference.
And um, I didn't know like if Laravel had the following to really have a conference.
Um, but he was like, no, you know, we'll have a hundred people.
And like, he wanted to do it in like three months, like from when we talked about it,
like we, we started talking about it in the winter and we're going to do it in February
in Washington, DC.
And I was like, I mean, whatever, you know, like let's try it.
And we're just like, maybe we'll get a hundred people to come to Washington cause we thought,
you know, people can come from New York and Boston and Philadelphia and stuff.
And hopefully we'll be able to do it.
And it worked out, you know, we got like 90 people, we had like 12 speakers and boom,
you know, the first Lara con.
And I don't know, I think it really like that probably did help solidify Laravel as a real
thing.
Like in people's mind, even the people that didn't come to the conference, like they see
like, Oh, there's a Lara con now.
Like this is actually like getting kind of legit as a framework.
Um, so yeah, I mean, it's, it's crazy.
Like I didn't, I didn't think it would work, but it did.
And um, after that, it just kept growing every year.
How big is the conference nowadays?
Now it's like 900 people.
Um, this year we had 900 in time square at PlayStation theater.
And I mean, the nice thing about it is though, like for me, Lara con is not really a for
profit endeavor because we have the other revenue from like forged and on floor and
all that stuff to where I can, as long as Lara con breaks, even like to me, that's the
goal.
It means like we poured every bit of money we could into making the conference as awesome
as possible, because thankfully just in a position where we don't have to make any money
on Lara con and we can just make it just an awesome event for people and you know, just
do it that way.
Yeah.
I was talking to another indie hacker on the podcast last week, actually, uh, her name's
and Lauren, she's got a company called nest labs and some of the products she makes are
just free and she just gives them away and other products she makes you charges money
for.
And it's cool because those free products help her build her brand and sort of spread
her message and she's able to do it because she's got this ecosystem of other things that
can sort of cover it, you know, cover its costs.
And I really love that strategy of not only having one thing, but having different things
and being able to like reap the rewards of certain things that are maybe just breakeven
or free that don't need to do the profit.
Yeah.
And we've done that in other ways too.
Like I actually typically would like alternate years of launching a commercial product versus
launching a free product.
And like you mentioned sidekick pro earlier on the podcast, we actually built sort of
our version of sidekick pro called Laravel horizon and just launched that for free at
Lara con 2017 and you know, just like as a way to just sort of say thank you and to build
goodwill and continue to just like provide value to people without asking for anything
in return.
Cause I think that's a really important thing to do when you're trying to build an audience
when did the same thing with like Laravel telescope last year was sort of a free debugging
tool for Laravel.
So I think, yeah, she has a really, that's really smart to do that.
And we've tried to do that same thing because I've never wanted to like make Laravel feel
just like a corporate, you know, become just like the next drab corporate entity.
That's just sort of always taking your money.
Like 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 we're putting out half the time we're
putting out free stuff, you know, so it's a good idea.
How important is it exactly to give things away for free when you're trying to build
a community and build an audience as well?
I mean, huge, like it's maybe one of the most important things.
I think that in my experience, at least that we've done is give away Laravel itself for
free.
I've given away, you know, just 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.
And I don't say it like in a resentful way, like, Oh, see, I've given you so much free
stuff.
You should pay me now.
But genuinely, I think it's just a really smart thing to do.
And if as long as like, for me, the hard part is like, I think it's important to be able
to do it with like a pure heart, so to speak.
So like, if you're only doing free stuff so that tomorrow you could ask them to pay you,
like to me, that feels like sort of like tarnished in a way.
But I've always just tried to like give back free stuff just out of like, just out of like
the fun of it and the excitement of it and just to make people happy and and just to
build up goodwill within the community.
You know, it's always struck me as interesting about this whole topic of building an audience
before you get started.
Is it it's kind of a chicken and an egg problem where it is you want to build an audience
and you want to like give them something for free that you're useful and actually helpful
and that hopefully you're passionate about so you do a good job.
But you know, 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 does that look like for Laravel?
When you were at the very beginning, you had nobody knew about it.
No one cared.
Oh, gosh.
I mean, small successes.
I mean, like, I remember I was super excited one time that like a Twitter account that
had 500 followers retweeted something that I tweeted about Laravel.
Like to me, that was a huge success.
Like at the beginning, just getting Laravel in front of like 500 people.
And I would just try to like post it everywhere.
I knew post it, you know, like there was a site called forest that was for developers
at the time.
It was kind of like a dribble for developers.
I would post it like on Reddit programming stuff.
And I don't know, you know, I don't I'm not the best one to ask about building an audience
from scratch.
But that's just the things I did is just like really try to just like be scrappy about finding
every little way I can get the framework out there.
Was there any one thing that worked better than others or was it just like every little
thing contributed a small amount?
I think it all added up a little bit.
I think sites like forest and Reddit for me were pretty big for getting it out there in
front of a lot of people.
I didn't have any Twitter following at all because I mean, I wasn't anybody, you know,
to follow.
I was just I probably just had like 10 followers.
So that wasn't like a huge market for me.
It was more just like if I could if I get someone to like retweet it, you know, or share
it with their audience.
That was obviously really helpful.
Yeah, I had almost the exact opposite situation early on with any hackers where I had basically
one distribution channel and that was Hacker News.
And it helped any hackers sort of blow up in the first week, you know, like 100,000
visitors and just a couple of days.
But after that, I was like, well, where do I where do I go from here?
You know, how do I what do I do?
I spend lots of time posting on Quora and all sorts of other websites, it doesn't really
seem to even be a drop in the bucket.
And so I think for me, the next step was to sort of build my own internal channels.
You know, 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.
I mean, you're launching your new products every year at the conference, you don't really
need any sort of external distribution channels nowadays to market Laravel, at least that's
how it looks from the outside looking in.
Is that true?
And do you spend time trying to grow Laravel?
That's I mean, it's funny you asked that because I was just on the phone with Adam
Wathan who I mentioned earlier yesterday and he was like, you know, maybe you should market
vapor some more.
And I was like, what, you know, what does that even mean?
I don't know what that even what do you mean, try to market it more and like, it is like,
we always kind of laugh at the fact that it feels like I've done nothing right in terms
of marketing.
Like, I don't really have a mailing list.
I don't pay for ads for any Laravel projects or products.
I have, well, that's not true.
I have run a couple of ads on Reddit for Forge, but in general, I don't really do any like
paid marketing anything.
All of my marketing is just strictly, you know, through my own Twitter channels of working
on Laravel through hyping up the conference, and then other community members, you know,
just like talking about or tweeting about or blogging about it.
It's kind of cool if you are building for an ecosystem that has gaps, that has holes,
you know, if you're like, well, I'm using Laravel, but I really need some sort of background
job processor and PHP people, I assume just sort of search out some of the things that
you're building because they already know that they need them.
Like these are kind of tools that fill a missing gap that people know to search for.
Yeah, and that's kind of what I was talking about on my snippet a few weeks ago is like,
if you can find a hot tool and then pair it with some like other thing that people want,
like Laravel and GraphQL or something, like some kind of pairing, then that's a good way
to actually launch something pretty successful.
Totally.
Yeah.
And I think, you know, people hear this sometimes they're like, oh, okay, well, I'm going to
combine, you know, underwater basket weaving with like my passion for Lord of the Rings.
And it's like, well, 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, you know, PHP and background
job processes or PHP and servers or something, then if they get, it's cool because you can
niche down and make something super targeted, super specific, but also have like a huge
market where it's not just going to be a couple dozen people.
So I want to talk about some of these other problems that developers who are aspiring
to be in the hackers end up running into.
We've talked about how do you come up with an idea and like sort of 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 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, you know, on the price points for the different products you've released,
how have you decided on, you know, charging recurring revenue versus one off and those
kind of decisions?
So back at the beginning with Forge, I knew it was going to be a subscription service
just based on the nature of like the product.
And then I was so like apprehensive, you know, because I had never, I was selling something
to an open source audience.
So I set my price really low, like Forge launched at like 10 bucks a month.
And I think that I was too low of a price, like in hindsight, but it was just like my
own fears and all of that made me put it really low.
And I think it worked out in the long run just because Laravel had so many users that
the volume sort of made up for the mistake in pricing.
And like, as I've gone, like every product I've launched, I've gotten more comfortable
with bumping up that price.
So like on voyeurs tiers go up to like $50 a month.
So I mean, a lot higher, a lot higher than $10 a month, but not, you know, like hundreds
of dollars a month.
And then a vapor now the cheapest plan is $40 a month.
And with Nova, we charged $200 per site.
So like we've, the prices have gone up significantly since that first release.
And I think part of that is just because I've gotten more comfortable, you know, with just
like putting a fair price on things that I think they should have based on their value.
And I'm not really as scared anymore.
And part of that I think is just because of like in PHP, we've now sort of conditioned
people to expect things that bring value to potentially cost money.
Like, whereas when Laravel was first getting started, that was not the case at all.
Like 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
like tinkering around with Laravel code.
And you know, they sold it as like a premium app, like you had to pay for it.
And like, no one complained about that.
You know what I mean?
Like no one said, Oh, this should be open source and free.
And I think it's easy to take that for granted because at the very beginning of this whole
story, like there would have been a lot of pushback around even selling that for anything
at all.
I mean, even if it was $5 or $10.
So yeah, 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 air way too low.
Like going back to our topic on donations and open source, like even when people try
to do donations, I'll see them set their tiers at like $1, $5, then corporate, corporate
tier $25.
It's just like, it's so comically low.
And I don't know if it's because they don't know, like they misjudge like how much money
big businesses are actually dealing with or what, but they just set them so low that it's
just so hard to make a sustainable, like livable income.
It's really easy to tell yourself in the early days that the thing that you've built or the
thing you're creating isn't that good yet.
And it's not really worth that much money and that the only way it's going to sell is
if you charge a dollar a month, you know, or there's something super small.
Do you think that you charging so little for a letter of L in the beginning was necessary
or in hindsight, do you think you could have just come right out of the gate charging a
lot?
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 for sure.
Like I think if I would have put it in the $25 or $30 range, it would have done just
as well.
I don't know how high I could have gone, but you know, I think when you're first launching
a product trying to get in that, like, I mean, I know like some people, they want to aim
for like $49 a month is like their minimum monthly.
And I think there's a lot of sense in that.
Honestly, I do kind of agree with that because it's just so much easier to just get a couple
hundred users, you know, rather than trying to get a couple thousand users, which is just
very daunting.
So that was like, I mean, that's what I did with vapor is kind of go $40 a month and figure,
Hey, maybe I can get four or 500 people on this and I don't know what, yeah, like I would
be happy with that, you know, if, if it did that.
So that, that just felt really achievable.
I mean, I think that's kind of a good marker, but you know, I don't think I had to charge
$10 a month for Forge.
I was just bad at pricing back then, nervous.
And this is kind of what I did.
Like you said, it, you kind of had the whole audience building thing made up for it.
You had such a huge following for Laravel at that point, you'd already done, I think
a couple of, of different Larikons by the time you launched Forge.
I launched Forge at Larikon number two in New York.
So you have the ecosystem going, you kind of are already creating your own distribution
channel and you were sort of capturing the fact that you had an audience.
You charge 10 bucks a month.
How long did it take you to hit the point where Forge was profitable and you're able
to quit your full-time job and work on Larvel stuff full-time?
I quit my full-time job six months after launching Forge.
I mean, I was already making more than my full-time job within like the first like six
or seven weeks.
Wow.
But you know, like I was nervous to just automatically quit the job.
One, like I kind of, I liked working there too, just like I would have to, it was scary
because it was so new, you know, like 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.
So I just kind of wanted to see it out for a little bit.
And January one of 2015 was my first day working full-time on Larvel.
It's pretty crazy because people talk a lot about how it takes a couple of years of working
on a SaaS product or something to get to the point where you can quit your job.
And with you, it was like, yeah, you're making that much a few months after launching Forge.
But you know, if you really look at the whole story, you would spend years, you know, a
couple of years by that point working on Larvel, building the audience.
And I guess, you know, doing a lot of research to figure out what people actually wanted.
I mean, by the time you built Forge, you get a pretty good understanding of what was missing
and what was valuable.
I can imagine.
Exactly.
Like you could say there was like a four-year lead-up into Forge of working without making
much money at all.
So yeah.
And then I think all of that legwork just made it launch a lot faster, obviously.
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, you know, what you're going to build for the next
10 years or is it inspiration strikes and you just get started immediately?
I don't keep a giant list, but I do actually keep a list of just potential ideas.
I mean, there's only like maybe four or five on there and they're not like, it's not like
I have hard dates beside them, but I do keep like 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.
And then like, for example, like right now I'm building a example application to help
people learn Laravel and it's just going to be like a free thing I put out.
Like I'm trying to build a whole app in Laravel because I've never, like all my stuff, my
biggest stuff has been closed source and commercial and that's always frustrated me that me as
the creator of Laravel has not had like this app I can point people to and say, hey, here's
how I would build something in Laravel.
So that's what I'm doing right now, and I mean, it's not going to be a commercial thing,
but it serves a couple of purposes in my mind.
One, like we talked about, it's just sort of something to sort of build goodwill in
the community.
But then also two, I sort of use this as an opportunity to find ideas.
So like, as I'm working on this example application, I'm going to be looking for like, you know,
what is giving me trouble?
What is hard about this?
What do I wish was easier about launching or building this application?
And so I'm just sort of proceeding in faith in a way that if there's a valuable idea,
it will surface to me like at some point during this example application and while I'm working
on it.
And if it doesn't, it doesn't.
But I'm kind of right now, I'm just kind of going on faith that hopefully it will.
But you know, it's just a way to keep me on the ground and working on something real.
And I think that's where sort of some of the most valuable ideas have come from.
Well, it's crazy to me how much you really do.
I mean, you're on this podcast right now, taking the time to do a little bit of promotion
and stuff.
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 Laricon.
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?
I work pretty much eight to five.
A lot of it is just having the team around me now and moving further down like Laravel's
commercial history, I definitely waited on hiring too long because I was scared to bring
someone else into Laravel for fear that they might like mess it up or call it wouldn't
like, I don't know, that they would just like mess up my baby that I'd created.
And gosh, that was just like probably one of my biggest business mistakes actually,
I would say is waiting like a couple of years to even bring on one person to help me.
And Laravel was making a lot of money at the time.
We could have easily hired a lot sooner, but that just made my life so much easier.
And now like I have one employee dedicated entirely full time to open source, like they
don't work on any of the commercial stuff at all.
One employee dedicated to or really two employees then also working on the commercial stuff.
And that includes like helping answer support emails, which I also do every morning.
And then just like fixing bugs and all that.
And so what that allows me to do is just like focus on sort of the R and D aspect of Laravel,
I guess you could say where I'm kind of the one tinkering around with new ideas.
And of course, like I bounce ideas off them too, or and they pitch ideas like Laravel
telescope was Mohammed's idea.
So you know, I mean, it's the staff that is really making this possible and making it
possible for me to be productive and building new things now.
Because if it was just me, like I would be way too bogged down at this point to do anything
new for sure.
Are there any things that you find yourself saying no too often that others might say
yes to you?
Because I feel like even with the staff you have, and even with the division of labor,
like you've got to be super disciplined in some way to be able to have this much time
to just do the R and D stuff, I could easily see it taking like, you know, 24 hours a day
to run Laravel.
Yeah, I mean, there's some of that I get it.
I don't get like, as many requests to do things as people might think, like, I get invited
to a conference like maybe once, once a month or something like that.
And I say no to almost all of those because I don't want to be away from like the family
and stuff.
And as at this point, I'm not sure you know, it's like super worth the best use of my time
like for Laravel for me to travel around and do that because it kind of kills the time
I can work on like the ecosystem itself.
And then there's also ideas that like have come up that we've said no to like building
a Laravel bug tracker set we said no to that and just other ideas that I feel like wouldn't
be the best use of time and sort of my framework for gauging that is I really like ideas that
we can accomplish in a reasonable amount of time and they provide maximal benefit to our
end users like make our end users more powerful and able to do cooler stuff.
And so, you know, for me stuff has to have a really good bang for the buck in that sense
for me to want to do it.
There's a framework that I think, I'm not sure if they developed it, but intercom's
founders at least wrote about it and it's called rice.
I think it stands for reach, impact, confidence and effort.
And so they sort of decide what they're going to work on by, you know, number one, reach
how many people are actually going to use this?
Is this something that like only 1% of our users are going to use or like 100% impact,
which is exactly what you're talking about, like how much bang am I going to get effort,
sort of divide this all by effort?
Like how much time does this take?
Is this something we can build in two months or like a year and then confidence, you know,
like, is this just a wild guess or are these numbers like pretty concrete?
And I love having like that kind of framework, even if you don't write it out and do the
equation, but just having like something like that in your head where you're constantly
trying to think, you know, 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, you know, why
are you working on this particular thing?
I've never heard of that about that, but yeah, that's a really awesome.
I'm going to have to look that up because that's a really awesome way to think about
it.
And it's very similar to what, how I try to think about things, which surprisingly,
like a lot of developers don't think that way.
Like when you hear it, it sounds like, oh yeah, of course you would think that way.
Like, but so many people like they especially neglect, like what it's going to do for the
end user, you know, developers are very focused on sort of, here's my holy grail contribution
to the development world and look how clean and shiny the code is.
Yeah.
And they're, they lose track of like, how does this actually improve people's lives
at the end of the day?
It's not just simple question, but surprisingly easy to forget to ask for some reason.
Yes.
Yeah.
So you're at this point now, you've been running Laravel for pretty much close to 10 years.
It'll be 10 years and another year.
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, you know, doing 10, 20 years from now?
And if so, what does that feature look like?
Man, you know, like, I don't know, you know, like part of it is I'm interested to see how
the story ends myself, you know, like, I feel like I've, it's come so far and like, I don't,
I don't know what the future is going to hold.
So like right now I just kind of take it a year or two at a time.
Like for me right now, sitting here, I feel confident saying like, yeah, Laravel is going
to be a thing in another year.
I don't know, like, you know, what four or five years down the road looks like just because
things can change really fast, but for me, like this is sort of what I'm focusing on
like for the rest of my professional PHP career.
And I think once Laravel is done, like, I'll probably move on to something else.
You know, like I don't think I'll start another PHP thing, you know, I think I'll move on
to something entirely different.
You think Laravel can survive without you?
Like is it something that's inherently tied into Taylor Atwell at this point, or is it
something that can sort of grow and thrive if you will, and they decided to move on to
something else?
I think it would, I think it would survive.
I think there is an element of like personality cult around Taylor Atwell and Laravel.
But I think, I think there's just enough talented people are in the ecosystem that like Laravel
the open source project, I think would continue for years to come really.
And there's enough talented, talented people that could move it forward.
I think about the same thing with Andy hackers, like what would I do if I wanted to leave,
you know, which I'm not planning to do anytime soon, but like, how do I get it, you know,
to not be as focused on me?
How do you identify talented people from the community to take over different parts of
it?
And then also, to your point, you know, 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 just a new fun opportunity, just because it's something you haven't done
before?
And it sounds like you're leaning towards the ladder.
How would you even decide what to work on next?
I don't know, you know, like, gosh, I mean, 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, like, I mean, I
think it would be cool to have a barbershop.
Like I think it would be cool to do a lot of stuff that's not even related to programming.
And I think I'll have to cross that bridge, you know, when I get there.
But I think Laravel would look different.
And I think, you know, like when I think about something like rails, and DHH is involvement
in rails, which I think is kind of, you can see is kind of a parallel to my involvement
Laravel.
I see DHH as not as invested in rails anymore as it used to be.
And I think rails feels different because of that.
So I think like, anytime you have a founder, that's like very involved in starting the
product, like, it's hard for them to step away and for the product to sort of retain
the same identity and feel the same way.
So I think Laravel would be different and what I would do afterwards.
I don't know.
It depends how long it lasts, you know?
Yeah.
What about now?
I don't know what's motivating you because I have a lot of conversations with founders.
And sometimes I'll talk to people on the podcast or I'll talk to them after the podcast.
Sometimes we'll get coffee with people.
And oftentimes people will run really successful businesses and get to a certain point where
they're like, well, what's the point?
You know, I have, you know, more than enough money and income coming in.
And I like what I'm doing, you know, theoretically, but I also have sort of acclimated to it.
And then I talked to other founders who are like super excited about what they're doing.
And I love every single day of it.
And it's like their life mission.
What keeps you going with Laravel and the present, you know, why do you wake up and
keep doing this every day?
I think for me, it's just kind of chasing that next big thing, you know, it's just sort
of like a rush, like chasing that next idea now is to have the next big cool announcement
at LaraCon.
It's just sort of like a driving thing for me now.
And you know, trying to see if I can find something even cooler than what we did last
year is just sort of like a personal challenge at this point.
It's just kind of a game to where I want to wake up and do it.
And you know, I think that's part of what's motivating me right now is just seeing like,
you know, how far can we take it basically.
We've come full circle back to the topic of motivation, which I guess never is never something
that doesn't matter.
A lot of people listening to this podcast are fledgling indie hackers.
They're working full time jobs as software engineers.
They're thinking about trying to start something and 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 showed a ton of advice in this episode.
So if we zoom out and you had to say something to this group of people as a whole, what do
you think they should really take away from your story?
I would say whatever you're doing, put your whole heart into it and like love it and invest
in it and care about it.
You know, I think if you do that and you really put your passion behind it, I think things
can work out.
And 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.
Put your whole heart into it.
Taylor Atwell, thank you so much for coming on the Indie Actors podcast.
Yeah, thanks for having me.
Can you let listeners know where they can go to learn more about Laravel and Forge on
the products you're building?
Yeah.
So just Laravel.com, you can go there and there's links there to all the various tools
around Laravel.
And if you want to follow me, it's twitter.com slash Taylor Atwell where I do most of my
social media engagement.
All right.
Thanks again, Taylor.
All right.
Thanks for having me.
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 at Taylor Atwell on Twitter, so feel free to send him a tweet and include me as
well.
I'm CS Allen on Twitter.
Also, I have a newsletter for the podcast where I share my thoughts on each new episode.
You can subscribe at ndhackers.com slash podcast.
Thanks so much for listening and I will see you next time.