The Laravel Podcast

Matt Stauffer:
You're now listening to the Laravel Podcast. Hey everybody, welcome back to Laravel Podcast Season Six. I'm one of your hosts, Matt Stauffer, and I got Taylor with me. You wanna say hey?

Taylor Otwell:
Hey everybody.

Matt Stauffer:
Taylor Otwell, the man, the myth, the legend, the... It's not the consigliere, because that would be more like Ian Landsman. I bet you there's gotta be some kind of reference, some mobster reference to what role you play. But... What's the... Oh, Benevolent Dictator for Life. We're gonna do that. BDFL. The BDFL of our little world. Um, so today we have had a request from friend of the pod and of the Laravel world, Justin Jackson, to revisit an older podcast episode from the Laravel snippet from October 11th, 2019, which is wild to me because when I relistened that snippet, um, you were saying, Oh, I'm just getting back from launching Vapor. And I was like, you're telling me Vapor launched four years ago? I feel like it was last year. This is wild to me! I didn't need to go back. Do you know when, when Forge launched?

Taylor Otwell:
Summer 2014 at Laracon in New York City.

Matt Stauffer:
We are coming up on 10 years of Forge.

Taylor Otwell:
Almost 10 years ago, yeah.

Matt Stauffer:
Wow.

Taylor Otwell:
That, I mean... Yeah. Pretty crazy. Wrote the whole back end, wrote the whole front end in Bootstrap. You could even make Minecraft servers on Forge.

Matt Stauffer:
Yes, I remember making Minecraft servers. There's WordPress as well. Although I think you brought WordPress back, right?

Taylor Otwell:
So we still have WordPress. Yeah, WordPress is there.

Matt Stauffer:
That's wild. Minecraft servers on Forge definitely gives you a sense of like, we're just figuring this thing out. So almost 10 years of Laravel LLC, the business. We have four years of Vapor. We also had Envoyer in the middle there. We've got some other paid products like Nova. And this episode four years ago, you said it was about choosing product ideas. And Justin was like, I know that people are always curious about that. So a little bit of backstory, I run a consultancy, and we have a few small softwares and services, but consultancies have a lot of like an ebb and flow. I'm talking to listeners less than to Taylor. I could have my entire team book for the next six months, and that's great for the next six months, but then six months from now, I got nothing, right? And so as a consultancy, we're constantly having to find more clients, more clients, more clients. And one of the dreams of a consultancy is recurring revenue, and one of the best ways to get recurring revenue is to have a SaaS product. So I have spent, I mean, I go to, what are those conferences in Vegas? The,

Taylor Otwell:
Micro-conf?

Matt Stauffer:
I go to micro-conf, I go to less-conf, I listen to all these podcasts about creating products. My brain lives in the creating product, and I've never actually been able to do it. I mean, I've done it. I've got some little products, but never at the Forge and Vapor level. And so, and I know there's a lot of people out there like me who are just saying, Oh man, it would be the dream to have a SaaS, whether it's somebody who's got a bigger company like me or somebody who's an independent founder. And so that kind of the foundational concept of this, this, this episode was asking the question of how do you choose a product idea and obviously you led that one in your own but I kind of kind of walk us through the same question. So, I mean, the baseline question is just like, hey, in the original thing here, you said, after selling $10 million worth of software, I began a mini-series on launching successful software products. Well, I think it's been a lot more than $10 million now, but I want to be the next Taylor, right? Okay, we've talked about open source packages, stuff like that. Let's say I want to be the next Taylor the businessman, and I'm a Laravel programmer who works in Laravel day by day. What does it look like for me to start the process of imagining how I can come up with my first SaaS? And I know there's other topics about how to actually build the thing, and you mentioned in your episode about building an audience. We can talk about those too if we have time, but let's talk about the product. Not only can you give us a baseline overview if somebody hasn't listened to that episode, but do you think your thinking has changed at all since then as well?

Taylor Otwell:
No, I don't think it's changed. And from what I remember on that episode, and I should have gone back and listened to it.

Matt Stauffer:
But it's better this way.

Taylor Otwell:
I think the core idea of how I've always thought about building products is mainly solving my own problems. And I've said that many times. Yeah, so Forge I was building servers by hand day in a day out to test various things with Laravel. You know to make sure that things were working or to benchmark something on a real web server or whatever. I wanted to automate that I put together some scripts to do that and a really really ugly UI and it kind of worked and felt good. It was like, hey, there's kind of something really convenient here. And I think I'll go ahead and build it out. And if nothing else, I will be the only user of this and it will honestly make my life so much easier.

Matt Stauffer:
Yeah.

Taylor Otwell:
And as I got deeper into it, it became sort of more obvious that someone else is actually going to use this. I don't know how many people. I remember when I was building Forge, I told Abigail, my wife, I hope this just pays maybe our mortgage and our electric bill, and that would be great, and we'd just have some extra fun money on the side. You know, many more people used it than I would have ever expected. And every product I've basically built since then has kind of been built in the same way. Envoyer, we needed to do zero downtime deployments without any downtime for our customers, solving our own needs there. Spark. Also, I never wanted to write all of that billing boilerplate ever again after working on Forge and Envoyer. And so I built Spark so that for any future products, I would not have to do that.

Matt Stauffer:
Yeah.

Taylor Otwell:
The one thing that I think is kind of unique that I was, maybe the only product I was actually pitched on building was Laravel Nova, who David Hemphill and I actually partnered up on that, where he primarily wrote the front end, I primarily wrote the back end. And I like wasn't convinced of an admin panel for many, many years. Until, you know, he kind of, I think it was at Laracon, maybe in one of the New York Laracons, he was like, Taylor, you know, I really think there's something here with this admin panel. Let me show you this prototype I've built. And it was all written in Blade. Currently Nova's written with like Vue and Inertia and stuff. This prototype was called Beam, and it was written in Blade. And it actually worked very similar to how Nova works today. And once I saw it, I was like, Oh, wow, this, you do kind of have something here. But I, you know, I just took him sitting down and pitching it to me. And then we partnered on it.

Matt Stauffer:
Yeah.

Taylor Otwell:
That's one of the only products where it wasn't, wasn't really me solving my own problem. It was more like he had kind of pitched me one of the problems he was having. So yeah, I mean, I think, you know, not to ramble on about it, I think the core idea, for me at least, has always been solving my own problems. I feel like I'm a very typical developer with typical developer problems. And if I have an issue or a pain point that I'm running into, I feel like there's probably other people out there that have that pain.

Matt Stauffer:
Yeah. And so that's super helpful. And one of the things I've been trying to compare it to is like, I get people pitching me pretty regularly saying, hey, I got this new product idea for the Laravel world. Do you think it's something that you're going to want to pay for? Do you think it's something that people are going to pay for? And so I'm trying to imagine the difference between you doing that and those folks doing that. And I think one of them is that a lot of people are unwilling to build a thing purely for their own desire, which is fine. There's nothing wrong with this. They're only willing to build a thing if they think it's going to make a lot of money, which, again, makes sense. It's a reasonable thing to do. But it's something I'm noticing different from you, at least with Forge. With Forge, you're like, I'm going to build this thing, and if nobody else uses it, it's still worth the cost of building the thing. And I wonder if that makes it easier for you, because A, you're using yourself as the target audience versus some imagined potential thing. Because you know, like that often saves us from all these like hyperbolic potentials. It's just like, no, I need this. I'm going to build this. But B, I wonder if that had an impact on your motivation? Do you feel like you still felt that way with other tools you built, like Forge, like Envoyer and Vapor? Or was that really something unique to your first product?

Taylor Otwell:
No, I think I felt the same way about all of the products for the most part. And honestly, like even, let's just talk about this year, even things like Pulse, which is not a paid product, but I think still kind of applies. We want to build something that people use, obviously. Born totally out of our own needs at Forge and, you know, me kind of writing up this pitch and base camp of what I thought we needed and Jess and Tim going and working on it. And honestly, same thing. If no one else had ever used Pulse.

Matt Stauffer:
Yeah.

Taylor Otwell:
Great. Like we have it in production on Forge right now. And we've identified, you know, kind of things that stick out to a slow endpoints or whatever that we didn't actually realize we had and things we need to dig into, customers that are calling our API is way more than seems reasonable. Like, you know, just helped us surface some interesting things to dig into, but yeah, same thing. Laravel Pennant, you know, also released this year our feature flag package. That's really an extraction of code we had already written in Forge to manage beta testing features and mainly that Tim had wrote. Feature flagging stuff that Tim had wrote in Forge is what I mean. Just extracting that into a package. And again, like just stuff that we needed, you know, that we found useful. And I think we solve common problems here at Laravel. And, you know, people seem to keep finding them useful, which is nice.

Matt Stauffer:
Yeah. And I mean, I definitely think there's some elements of like how to approach it. And I also think that there's got to be some elements of you have some combination of a unique vision, a unique audience, and a unique... I don't know. There's something unique about how you go about doing something that is probably a little bit hard for anybody else to just imagine, magically, immediately reproduce. But I also think that there's some things that you do that, as people learn from them, we're seeing more effective products. Because someone said, oh, well, I'm sure there's a story behind Tynker. Well, I couldn't think on top of my head. But he's just like, I would really like to be able to do blah, blah, blah. But with Tinker, I can only do X, Y, Z. But I think the reason I asked the question I did is because it feels like there's an element of what What is enough? What satisfies us? What makes us motivated to do the thing? And it lines up a little bit the idea where like a lot of times people say, don't announce the thing you're going to do, because once you announce it, you're going to lose the motivation for it.

Taylor Otwell:
And I've always tried to follow that rule.

Matt Stauffer:
Okay, because I was going to ask, because I wonder if it's like one of those, well, maybe that's a test. So for you, you're like, I want to have the thing before I start talking about the thing.

Taylor Otwell:
Yeah, I never tweet about anything secretive that Laravel's working on until it's basically done. Like, until I'm extremely confident that the product is going to launch. I mean, I think I've pretty much done that with all of my products. I don't think I really talked much about Nova until David Hemphill and I were literally together in Arkansas, pairing on the final push of getting that product over the line. So yeah, I don't really get into like talking about things I'm doing beforehand. I do think there's like some science behind that, you know, that people have shared online about how once you talk about something, you kind of get that fix of actually having done the action. So yeah, I try to avoid it.

Matt Stauffer:
So one of the things that a lot of people talk about in the startup world is validation, where you kind of like take your idea and you talk to other people and say, would you like it? Would you pay for it? But even they're often saying someone's saying they're going to pay for the thing and actually being willing to pay for the thing is not actually always the same thing. So I understand that whatever answer you give works for you is not saying those people are wrong, right? You're only talking about what works for you. But like once you've had an idea, you start building this idea. You build the idea to a point where you're going to be happy with it. And then do you just take signups? Is there any other steps in the process for you of like actually going from the idea to just taking paid signups? Is there any aspects of validation? Are you shopping it to a small group of trusted friends or anything like that? Or you're just kind of like, hey, this is what I'm doing and we'll see how it works once I release it.

Taylor Otwell:
I definitely do send, you know, the rough idea or screenshots or whatever to a group of friends or even beta test. People helped us beta test Forge, a few people, less than 10 probably. So yeah, I mean, I honestly don't do a lot of validation in that way. And I do think it's hard to get people to pay for things. You know what I mean? It is like the product has to be pretty ambitious and pretty good. Like if I think about how many SaaS products do I actually pay for? It's not a lot. Even here at Laravel, we pay for DigitalOcean, we pay for Pusher, we pay for a few bug tracking services or whatever, but it's not like there's... We're not paying for 50 SaaS products here at Laravel. So it's actually not that many, I think, that people are using on a regular basis. So yeah, I don't know. I think another thing, you know, to talk about is just sort of the market and following you have for launching products, which obviously we have here at Laravel, a huge audience of people that are ready to look at whatever we put out there. And I think if you're new to launching a product, there's probably a lot of preliminary groundwork to be done in terms of actually building an audience. And I don't think there's a great shortcut to that, except for providing a lot of value for free in the months to maybe even years leading up to you launching a product. And I know that kind of sucks to hear. But when I think about all of the people that I know that have launched something successful, it's usually preceded by many, many months of valuable tweets, valuable blog posts, maybe valuable videos, valuable podcasts. They're providing some sort of something. It could be just pure information, could be an open source package, could be anything that provides value for end users for free first, typically.

Matt Stauffer:
Yeah.

Taylor Otwell:
If you're sort of an Indie bootstrapper type of person I think it's pretty it's at least useful to have that audience to launch something to.

Matt Stauffer:
Yeah.

Taylor Otwell: and I think a lot of people kind of want to shortcut that and it's because it is a lot of work But I think it's actually very valuable if you can do that

Matt Stauffer:
I also think that it's, it's pretty tough to continue doing that if your only goal for doing it is to gain an audience for launching a thing. So that's another piece of it.

Taylor Otwell:
Yes!

Matt Stauffer:
If you're like, all I'm doing is committing, you know, this huge portion of my life to building an audience so that hopefully when I make a product one day it'll actually be successful. You're going to burn out in that really fast.

Taylor Otwell:
And I think it's sort of disingenuous.

Matt Stauffer:
The people I've seen both be most successful are the people who say, I honestly want to do this because I want to help people and I hope it's going to help me. And the thing is those things can be true at the same time. And there's this book, I don't know if you've read it, but it's "How to Win Friends and Influence People". Are you familiar with it?

Taylor Otwell:
Yeah, I've read it.

Matt Stauffer:
Okay, so I read it and immediately assigned everybody at Tighten to read it because it's how I look at the world, but I didn't know how to say the words for it. And one of the things he basically says in the book is like, and really it's the whole premise of the book is, if you genuinely help people and you figure out what they need and you figure out how to help them, you're also basically going to be able to figure out the way that, you know, you can like I don't know, I'm saying it, it sounds skeezy.

Taylor Otwell:
I think it's just a really great book on relationships in general. I do think everyone should read it. I think about that book a lot, actually, on a pretty regular basis, just in my interactions with people. Just about stuff like how you can never win an argument, you know, which is one point of the book someone has to lose and yeah, usually you always lose actually Because even if you beat the person in the argument, they're sort of this underlying resentment.

Matt Stauffer:
Yeah

Taylor Otwell:
On the other side. The relationship is a little bit damaged. Even if you win and if you lose, of course that sucks because you lose so yeah. Everyone should read that book.

Taylor Otwell:
It's a great I agree.

Matt Stauffer:
Yeah, and I'm gonna try again, but I agree there's so much more than what I'm saying here. Everyone should read it. But there's some element in it of how you can honestly be receiving benefit from a relationship, you know, and not necessarily financial benefit, but like, you can be altruistic and want what's best from someone even in a relationship where there's a transaction or where there's benefit from having a relationship. And it walks that line in a very careful and honest way, in a way that I think that, like, again, if we're talking about building an audience, I think that the people who build an audience purely for transactional benefits, right? Like, I'm going to put these tweets out, and they don't, they burn out, they stick around, and often it feels fake, it feels dishonest, and it doesn't, maybe always every day, but you're going to hit those moments where you're like, ugh, this kind of makes me feel skeezy. Whereas there are other people who are like, I want to help people, but they're also open to me saying, And I also understand that helping people builds my audience and that audience may be a benefit to me, but I'm doing this because of helping people. You feel better about them because you want them to succeed and you like them, and you don't feel like they're being dishonest about what they're doing. And so I just like people like Aaron, you know, Aaron Francis is someone who has had a recent rise in the Laravel world in part because he talks openly about the ways that like he's a good guy and trying to help people. And also it is benefiting his career to do so. And those things can both be true at the same time. And so I appreciate the honesty of just being like, you know, you're going to have to want to do it for good reasons or you won't stick around with it. However, also doing it for good reasons can benefit you, right? Like you just got to be the type of person who wants to do that.

Taylor Otwell:
What do you think about? Okay, if we if we need to stick on audience building...

Matt Stauffer:
No, no, we can go anywhere you want.

Taylor Otwell:
But the next the next place I was about to go was what do you think about recurring billing versus one time purchase in terms of deciding what to build? I think, you know, a lot of my stuff has been subscription based. We have a couple one time purchase things like Nova. No, that's not even true. Actually, Nova and Spark even are yearly payments to receive a year of updates on Composer. But I think someone like Adam Wathan at Tailwind has kind of shown you can actually build a pretty successful business with no subscriptions at all. And I think that's actually a little bit easier to launch than a subscription-based service, especially if you're selling to kind of the individual developer and you're not selling to big businesses or corporations. And those people are happy to pay subscriptions. But the individual developer... Yeah, I think so. But the individual developer, much more likely, I think, to make a one-time purchase and just be done. And you can kind of get away with charging a little bit more, maybe. Yeah. So yeah, as you're thinking of products, don't lock yourself in, I think, to the subscription model. There's a lot of actually really successful people that are selling just one-time purchase products and making bookoos of money doing that.

Matt Stauffer:
Yeah.

Taylor Otwell:
Anyway, yeah.

Matt Stauffer:
Yeah, no, I actually was going to take us there eventually, so I'm glad you got there. There's an interesting... We think of it as a dichotomy, right? It's either a SaaS where you pay every single month or every single year, or it's a one-time purchase, period. And there's definitely, it's worth naming the difference because like you said, people have a much lower barrier to entry on a one-time purchase. But if you think about the types of things we traditionally think as a one-time purchase, there's a difference between one-time purchase or a one-time purchase that if you want updates after a certain amount of time, you're gonna have to go back and pay more because that's not quite a SaaS, right? You can continue using this thing as it is, forever in perpetuity you will get support and updates for one year. I think that's a really nice in-between space. It doesn't work for everything but it works for example for software like I think with Tinker well, you buy Tinker well, you get a year with support and then you can keep using that app for the rest of your life or you can pay for updates and I think Ray might be the same way and I really like that format because as someone who's like I don't want to lock into your SaaS platform and I can't keep using my thing if I don't, well, you know, like it feels kind of gross, like a car where if you don't keep paying a subscription to the car manufacturer, your car stops working. You know, that would make me feel uncomfortable. What about a car where after a year, you know, you don't get GPS updates? Well, we're all used to that, right? Like, you know, the car keeps working for the rest of your life, but there's certain features that if you keep wanting to have it, you're gonna have to pay for those. It just feels so much better because it gives us the agency to be able to opt into that update later. But know that we have not now committed to XYZ for every single month or all of a sudden that initial spend is just kind of useless because we can't use the thing anymore. I know it makes a lot of sense for software to do that way. Do you think there's any way for info products or info products just a one and done and that's just kind of it?

Taylor Otwell:
I can't think of any examples of a kind of an ongoing info product type of thing, you know.

Matt Stauffer:
Because like Tailwind UI, what is the billing model on Tailwind UI?

Taylor Otwell:
That's all lifetime.

Matt Stauffer:
Yeah. So when they release new stuff, you just get new stuff. Oh, but didn't they add something that cost more, like one of the different kits or something like that?

Taylor Otwell:
So you can buy, I think I'm right about this, you can buy individual templates if you don't have, I think they call it Tailwind All Access is what they're sort of like lifetime all access pass and you get everything that they do have done and basically will ever do. And me and Adam have talked about this many times, how I kind of think that's a scary idea for them. But, you know, I mean, I guess the idea is CSS and front end in general is such a huge market. There's probably new customers all the time to keep the revenue coming in theory. So yeah, I mean, they're working on a new application UI kit, which they've been pretty publicly talking about lately. And if you're an All Access subscriber, my understanding is you get access to that on day one when it comes out. So yeah, that's a one-time purchase business, as far as I know, pretty exclusively.

Matt Stauffer:
Did they end up, I don't know if it was like e-commerce or something like that, but I feel like at some point there was gonna be the possibility that one of them was gonna cost extra, but did that maybe not end up happening?

Taylor Otwell:
I'm not sure that ever really materialized I think when you know when Tailwind UI came out there was the idea of potentially different kits like a social media website kit an e-commerce kit, and I don't think that totally materialized I think the the upcoming react base UI component kit is kind of the upcoming thing.

Matt Stauffer:
Well, I am on their pricing site and it is like what you said, which is you can get all access, which is right now it's 300 bucks one time, or you can buy a marketing package for 150, an application UI package for 150, e-commerce for 150. So there are different ways to differentiate between individual products versus like a longer lifetime thing. And then you also got people like Laracasts who are subscription models and then allow you to buy like a one-off thing that gives you lifetime, which is, like you said, is scary. But yeah, there's a lot of different ways of looking at this.

Taylor Otwell:
It is scary, but I guess, you know, in Laracast's case, if they know their average lifetime spend of a monthly customer, then the math should work out, you know, as long as they charge a little bit that level or a little bit more than that for their one-time purchase thing.

Matt Stauffer:
Yeah.

Taylor Otwell:
And the same on Forge. Like, I know, you know, kind of the average lifetime spend of customers, but I would be just something in me would still be scared to put that that lifetime pricing out there.

Matt Stauffer:
Yeah.

Taylor Otwell:
Even though it may not even be rational from a math perspective, the fear.

Matt Stauffer:
Yeah. So we've got...

Taylor Otwell:
What else do we have to talk about in terms of building products?

Matt Stauffer:
Yeah, so we had how to come up with ideas for a SaaS, how to build an audience. I think the last thing was about building and shipping. So you had talked a little bit about the last episode about as you're working, how do you focus on quality versus shipping? And, you know, that's something we talk about classically. And then also, how do you find the commitment to finish when you're feeling burnt out? But I definitely want to start out with that quality versus shipping. It's a very common thing that like perfect is the enemy of good or often perfect is the enemy of shift, right? Like we want to make the thing so perfect that you never want to launch the thing. But one of the things that you have talked about a lot is the desire for something to be really good and a lot of the early stories about Laravel are about how Taylor put up this question of Stack Overflow about like, am I crazy for wanting to make every little thing just right with the comments all aligned, everything like that. So as someone who is really trying to make really high quality work where everything that's released under your name is really excellent, how do you avoid the problem of never shipping because it's never good enough?

Taylor Otwell:
Um, I'm not sure because there are things I haven't shipped because they weren't good enough. I mean, there's kind of, kind of, I guess I wouldn't say famous, but in the Laravel lore history, you know, there are products like Laravel Cloud, which I even talked about because it was done. It was totally done, you know, designed by Steve Shoger at Tailwind now. And, uh, I wrote the whole backend, but I just couldn't. I couldn't make it compelling enough to where it felt like this is really something different enough and better enough from what we have that it feels worth releasing. Same with like Laravel Beep, which I'm still There's something there and I'm going to go back to it one day.

Matt Stauffer:
Okay good. I'm still here with you.

Taylor Otwell:
But that's another product totally finished, you know, hired designers to build it, build the whole back end. And when it was done, it was just like, yeah, it's OK, you know. But, you know, maybe it was good enough to release. Sometimes when I come back to it now, I'm like, oh, wow, I should have put this out. This looks great. But once you're deep in it, sometimes it's hard. With like Forge and Vapor, I feel like they were just much better defined in my mind of what being done looks like. I mean, I think that's important to figure out early on, and it's something we maybe could have done a little bit better job of with Pulse, our most recent package we put out. I think it's important to define what does 1.0 even look like so that you know you're actually done. Otherwise, you really can just keep going on forever. So I think it's important to sit down pretty early and say these are the key things that I think make this a compelling package and this is what needs to be in 1.0 and we're not going to allow ourselves to be distracted by other potential features because they will come up inevitably.

Matt Stauffer:
That's wild because that is very relevant to client work. I mean with every single client we have, at some point if we have not defined the initial scope for when it's ready to be done or launched or merged or whatever, it's just going to go scope creep, scope creep, scope creep. And one of our biggest things is like to be able to say the phrase like, That's going to go in phase two or V2 or s print two or whatever you want to call it. Right? So it's very interesting hearing you say like, yeah, that's a part of shipping products too. Like, you know, you have all these cool ideas and you've got to be able to say, is this idea going to now stretch the time to launch and stretch the time to launch? Or do we have this initially defined scope of what we're doing?

Taylor Otwell:
Yeah. And I think one thing that I would recommend if you're building products is go ahead and build a basic version of the product all the way through in the sense that people can sign up. You can deploy the product at any time and maybe it's locked down behind some password or whatever. But the product is actually out there, and at least you're using it in production. And whenever you're ready to flip the switch and allow customers in, everything is ready. The billing is ready. Everything is ready. Because I think that makes it a little bit easier to say, OK, this looks good. Let's go ahead and ship it now. If you get to that point and you still have to add all this other stuff, you're going to get distracted again with all sorts of other things. So I like to kind of set up that, I guess you'd call it like continuous delivery pipeline pretty early in the project's process, if I can, so that it's easy to ship it when you want to ship it and when the feeling strikes.

Matt Stauffer:
That's great. And in the Laravel ecosystem, that also makes a ton of sense because when you're doing those core things like billing and stuff, it's easier to do on a fresh install anyway. So it's sort of like, hey...

Taylor Otwell:
Way easier.

Matt Stauffer:
Yeah. Just like whatever it's going to be, whether it's Breeze or Jetstream and then Spark, throw that stuff on your initial thing. Allow people to sign up. Laugh because of course nobody's going to have more than one team right now. Of course nobody's signing up right now. But then when that day comes, you don't have to A, figure out how to apply those things to a long-built app, and B, don't have to say like, um, like barely, barely have the energy and now I have to do a whole bunch of boring stuff.

Taylor Otwell:
Super boring.

Matt Stauffer:
that's not fun and has lots of edge cases and stuff. That's a great idea. Huh. Okay.

Taylor Otwell:
Yeah. And we're getting into the, the kind of the technical side, but I think, um, yeah, to that point, you don't want to get like to the end of the project and then try to strap on the billing piece at the end and be like, remember, you have to write all this authorization and protection about only subscribed users can do this. And only if you're on this plan, you can do that. And that is super annoying to come in and bolt on after the fact, um, or something like team billing, another super complicated thing to bolt on after the fact. Um, Yeah, so definitely get that set up early on I would say so that you continually ship the product and iterate on it.

Matt Stauffer:
Yeah. So that does touch into the other question, which was talking about the commitment to finish. A lot of people, you know, and every single person, like, probably fits into one of the big categories of like, are you an idea person? Are you an implementation person? Are you a maintenance person or whatever? But if we're talking about someone who wants to be able to build a product, we're going to make the assumption that they have that initial like, come up with an idea, you know, stub the thing out, you know, just build the basic stuff. And a lot of those folks struggle very much with continuing the motivation to actually finish the thing because it gets more and more boring and nitty-gritty the closer you get to the end. Are you one of the other types? And if you are the idea guy, how do you find the motivation to finish? And if you are the finishing guy, how do you even become an idea guy? Is that kind of person? Or are you just kind of like a little bit of everything? Are you a unicorn?

Taylor Otwell:
I just anecdotally seem to be a little bit unique in that I do finish a lot of the products I start and I think I don't know all the reasons for that but one reason I can think of or one thing I've observed in other people that build products is they have an idea Um, and I can think of some specific examples actually right now that I don't want to like put them out there publicly, but generally they have an idea they're super excited about and they do a lot of initial upfront work on a lot of easy tasks. So I'm going to get you know, the basic, some of the really basic, simple stuff done first. And then I'm going to tackle some of the harder problems. And from my observation, one of the problems with that is you work on the idea for, say, a month on some of the easy stuff. The idea has already lost some of its sexiness in your mind and then you get to some super hard stuff and you're already kind of slowing down and now it's like you're really kind of screwed because you lose all the motivation on the hard stuff and you can't really push over that wall. I would really approach it totally opposite than that. And I try to always, like when I built Vapor, I thought of what is the absolute, what's the hurdle on the horizon that I'm not sure I'm gonna be able to cross? The hardest problem we're potentially going to encounter building this product, and let's just do that first. Even before we have any UI or anything. While you're the most motivated on the idea, try to solve the biggest hurdle. I think it has a few benefits. One, You're working on the hard problems while you're most motivated like I said . Two, if the problems are insurmountable you actually want to know that now not a month and a half or two months from now like if it's just generally technically beyond your grasp or maybe even not even possible given some sort of limitations and the the tools you're using or what's out there technology wise at the time I would rather know that in the first two weeks than in the first two months so that I can move on to some other idea or pivot to some modified version of the idea. So do the hard stuff first. I think that has been something that has assisted me. I'm not sure if it's the only thing. one primary thing that has assisted me in getting things actually to the finish line. Once you solve that hardest thing, your motivation is actually stronger because now you finished it, you're pumped, we got past this hard thing, now we just had to add on a bunch of easy stuff and we're good.

Matt Stauffer:
That's brilliant. I really like that and finding the commitment to finish like if let's say you're at the end of the bike ride and you almost are out of energy and then you hit the really big hill like you're screwed. But if you start the bike ride, you take the really big hill, and then the end of bike ride. It's like yeah, you just got to kind of go downhill for the last mile like no big deal, right? So it's like if you use all your energy at the beginning on this very difficult thing when you're excited and you're motivated and you're passionate or whatever . Then at the end where it's like now I gotta finish but yeah, you gotta finish on this rote stuff that you can do while you're watching your favorite TV show or something like that. I really love that. Yeah.

Taylor Otwell:
Yeah, I can think of one situation in particular where the person had a product idea. It was a good product idea. I mean a great product idea, but they kept kind of dancing around the hard part of the idea and doing all these other little things and I was like, hey man, you should like. The product is useless if you don't tackle this hard thing. This is actually the most important part. And you should really try to tackle that while you have this energy. And, you know, I don't think they ever ever did. And you kind of get bogged down. But yeah, don't dance around like the hard core part of the idea. Because I mean, usually the the valuable things are the hard things, right? Otherwise, people wouldn't be paying you to do them. So focus on those early.

Matt Stauffer:
And this may not be true for everybody, but one idea here has just popped in my head is partnerships can be helpful in this direction. So Aaron Francis was building out BuiltForPulse.com, which is like a directory of pulse cards that people create. And it's very similar to NovaPackages.com, which I made for the Nova World a while back. So I just reached out to him and I said, Here's the code base for Nova packages. Let me know if you want to work on it. And we've ended up working on it together. And one of the things that I found is that he's really excited about writing the code that integrates with GitHub and downloads the GitHub readmes and stuff like that. And that code exists in Nova packages, but it's still... pretty complicated code and it needs to be done a little bit differently. He's like, I love this kind of stuff. I love this deep, nitty gritty backend stuff and this site's not going to exist without it. I'm like, great, I'll go add tags to the packages. I'll go rework these really rote, you know, UI things. And so one of the things that I'm doing is honestly the easy stuff. We're doing a ton of easy stuff on the site while Aaron's brain purely just focuses on the hard stuff. And so rather than him doing all this hard stuff and then being exhausted and then have to do a whole bunch of basic database stuff at the end, he's gonna finish the hard stuff and it's gonna be like, and there you go. You plug it in the system I already built, whereas I built this whole system and all the system is waiting for is Aaron's hard work to be done. So there also might be some elements of partnership there where you can split the tasks and also potentially motivate each other because you finish something and then you don't finish it and you go, and now all this? It's like you finish it and you're like, and everything else is done. Look at that, that's kind of amazing!

Taylor Otwell:
Yeah.

Matt Stauffer:
I know that you don't normally work in partnership in these products, although I assume that with the more recent ones like Vapor and stuff like that, there's some element where you're building the core, but then at some point you hand off some of the work to your team. Is that something that you would kind of say makes a significant impact on your ability to ship? I imagine no, because you ship things like Forge and Envoyer solo, but do you notice there being a big difference working in a team when creating a product versus working on your own?

Taylor Otwell:
Um, so how I've approached some of these things in the past, like Vapor, I actually wrote myself pretty much everything.

Matt Stauffer:
Oh, you did?

Taylor Otwell:
Then, and then yeah, then at the end, um, Mohammed, you know, our first employee at Laravel came in, kind of helped tidy up some of the loose ends and kind of perform some of the initial support work on that product. Um, I would say over the last year to year and a half has actually been the first transition to where we've actually shipped Laravel packages that I did not write. So examples would be Pennant and Pulse primarily, but to some extent Volt. I wrote the prototype for Volt and then Nuno came on board with fresh ideas and we kind of paired up on the end of that. But Pennant and Pulse I did not write really a single line of code on either of those packages. Pennant wasn't even my idea to be honest. It was Tim's idea and then Pulse was my idea, but I didn't write any of the code and it's a very new place for me to be but I think obviously If you want to actually scale out and build a lot of things you got to have help and we have great help here at Laravel so You know, it lets us do more. It helps us ship more. But yeah, most of the stuff up until 20, you know, 2021, 2022, I was writing at least the initial versions, start to finish myself, and then kind of bringing in people once I had a good idea.

Matt Stauffer:
You have the benefit of having built apps before, so the people you bring on you know can maintain your apps the way you like. They know how you like to write apps. By the time you trust somebody else, you are decade plus into this process of defining how you want to do things. That's something I found at Tighten as well, even with not products. In the early days of bringing on employees, I paired with them on everything. I didn't teach them how to code, but I brought in people who were more apprentice level. And I'm like, I'm going to shape you into helping me. And then now I'm at the point where I'm just like, first of all, I trust all these people to write the code the way I want. And even if I didn't, Keith would be there. Keith, my director of engineering, would be there. I haven't yet, for years, been in a place where I look at a single line of code that gets written in Tighten and say, that's not how I would want it. But it took a long time to get there, similarly to you. You've got a team of people you trust now. But when someone's just getting started, that's not what you start out with. That's not a reasonable thing to expect. Well, that's the end of my questions other than something entirely unrelated. Were there any other aspects of this conversation about what it looks like to come up with your own product or SaaS or something that you can charge money from? Is there anything we missed?

Taylor Otwell:
No, I think, honestly, that's a pretty good overview from start to finish in terms of finding your idea. All of my ideas have come through my own problems. I actually really hate to be in that position of like, hmm, I want to build something. What could I build? I don't like that feeling. I feel like that's kind of grasping at straws. If the idea is not obvious to me, then I'm just not super compelled to build it or even I don't have confidence that it's even a good idea at all, to be honest, because I'm just kind of made it up out of thin air. I mean, I think, you know, Justin Jackson, the one that asked us to talk about this, I mean, he's written actually a lot about business ideas and finding product market fit himself. And I think if people are interested in this topic in general, you know, go dig into some of the prior work he's put out there on this topic, because I think it's pretty valuable.

Matt Stauffer:
I mean, he's had Slack discussion groups about it. He's written books. He's done podcasts. I mean, he tweets about it. Yeah. Justin, not only is brilliant in his own right, but also I think he's a bridge into the startup founder ecosystem that exists that a lot of Laravel programmers might not know are out there. So definitely follow Justin and see the worlds that he kind of overlaps in. All right, well, here's the last question of the day. So I hope I don't get in trouble for saying this because my fiancee doesn't listen to this podcast. So hopefully it stays that way. Nobody go tell her, but there's a my family's throwing her a and some of her family's well throwing her a virtual shower in a couple weeks. And I just got to send a questions of like the What is the newlywed game? So they gave me all these questions and they're like, can you answer these and then during the game? We'll kind of like see what she she can get and I just looked at that and there was one that I did not know from you that I want to figure out which is says what is their favorite movie ? Favorite movie is tough. I feel like that's a really tough one to do because , favorite comedy favorite what so I said I wanted to say in a specific moment Um, Abby and the kids go out of town for something and it is a Friday night and you've got your favorite drink in hand. It's getting dark. It's cold. You finished work for the day and you just want to veg. You want to sit on the TV and you want to turn on just a movie that you know, like when you turn on this movie, you can be engaged. You might've seen it a hundred times, but like you just know you're gonna have a good time with it. Does that prompt a movie for you?

Taylor Otwell:
Um, Two movies come to mind. One would be Interstellar.

Matt Stauffer:
Really?

Taylor Otwell:
I like that movie. I listen to the soundtrack a lot as well.

Matt Stauffer:
Great soundtrack.

Taylor Otwell:
What else?

Matt Stauffer:
It's not too heavy for you to just want to sit and watch again?

Taylor Otwell:
I do think that's a little heavy. That's why I kind of hesitated on that a little bit.

Matt Stauffer:
Got it.

Taylor Otwell:
But my other movie feels kind of equally weird, which is would be like Sandlot, which is one of my favorite movies. And that feels,

Matt Stauffer:
That's fantastic.

Taylor Otwell:
It feels a little weird to sit by myself and watch a kids movie with a, you know, with a glass of wine or something. But it's just a great movie.

Matt Stauffer:
It's also a kids movie from our childhood, right? So there is that.

Taylor Otwell:
Yeah, it is. Yeah, sure.

Matt Stauffer:
So it's weird because... Oh, go ahead.

Taylor Otwell:
No, I... Yeah, I mean, those are the two that just came to mind first.

Matt Stauffer:
Yeah. I realize that I don't have an answer to this question because the only thing I can think of is if my kids were like, Dad, what movie do you want to watch? I can tell you immediately which movie I'd want to watch. But then I'm like, would I watch this without my kids? And I'm like, I don't know, maybe I would. It's The Mitchells vs. the Machines on Netflix.

Taylor Otwell:
Oh, wow. Okay.

Matt Stauffer:
It's this weird, quirky, coming-of-age movie with funny family dynamics and robots and the end of the world. It brings all these things together in a way that I really like. It's a great comedy. I don't know if it would be my top. I think if I put myself out of dad brain, there's probably other movies that I could put. But because 9 times out of 10 when I'm watching a movie, it's going to be with my kids. Then that's just what pops to mind, but it's good enough that if if you're like Matt You got to come up with something right now, and I don't have a list Yeah, I go watch Mitchells versus the Machines by myself. I'd do it.

Taylor Otwell:
Yeah, I think what makes it hard. I don't know about you, but I just wouldn't. I wouldn't watch a movie by myself. I would just be on Github you know working.

Matt Stauffer:
You know what I might do what I found is that like if I'm alone by myself what I'm most likely to do is put on a TV show and code at the same time . That I can do pretty easily. I do that with Ted Lasso. I do that with other shows. I have some shows that I literally never watched without coding. And one time I turned one of them on, I'm like, oh, this is not interesting enough to maintain my attention. But yeah, Friday Night Alone, I'm going to be coding, 100%.

Taylor Otwell:
Yeah.

Matt Stauffer:
Sweet. Well Taylor. It was a pleasure hanging out with you as always. Thank you for teaching us all about you know how you've done this and hopefully this will motivate some of us to go go build a thing so.

Taylor Otwell:
Yeah fun times.

Matt Stauffer:
The rest of you. We will see you all next time. Thanks for hanging out.

Taylor Otwell:
See ya.