Dear founder,
I really want to clean up a little bit when it comes to vibe coding and software as a service businesses, because I think there’s a lot of confusion, a lot of hype, and a lot of complaints about the imminent demise of software as a service solutions.
And I think it’s time that we have a voice out here that is not a doomer. I’m certainly not an apologist for the SaaS movement either. But giving some realistic expectations of where we are and where the field is headed is probably a good idea at this point.
A quick word from our Sponsor, Paddle.com. I use Paddle as my Merchant of Record for all my software projects. They take care of all the taxes, the currencies, tracking declined transactions and updated credit cards so that I can focus on dealing with my competitors (and not banks and financial regulators). If you think you’d rather just build your product, check out Paddle.com as your payment provider.
I believe that while software as a service may struggle with things like subscription fatigue, or some vibe-coded slop solution replacing certain purchases that people might have been making in the past, I don’t think it’s the end. And I don’t think it’s necessarily a bad thing for our industry to be where we are right now.
There are a couple things I feel are significantly undervalued when people look at AI and what threat it might pose to the software development field and the SaaS field in particular. So let’s talk about that.
What Vibe Coding Actually Is
Most importantly, I think people who believe that just because you can go to Bolt.new, or to v0, or to Lovable, and explain what you want, and have a vibe coding tool pretty much build whatever it thinks you’ve just explained—I don’t think this is the end of all software as a service.
But before we dive into why this is false, maybe we should determine what exactly vibe coding is. Because a lot of software developers see AI and think “vibe coding,” mostly because the consensus in our community is that this is what it means.
I do not believe so.
I believe vibe coding is a version of AI-assisted software engineering—let’s call it an extreme version of it. But not all software created through AI-assisted engineering is vibe coded.
Vibe coding is when you don’t really care about the underlying code at all. You just say what you want. The thing builds, it deploys in the background, and then it runs. That, to me, is a vibe coded app.
The moment you dive into the code, the moment you understand it, the moment you know what the components are underneath the user interface or the API—it’s not a vibe coded project anymore. It is, at most, a strongly AI-assisted software engineering project.
The Core Truth: Projects vs. Businesses
So here’s my definitory exercise: the general consensus in the—let’s call it “thinkfluencer”—community on Twitter and other social media seems to be that vibe coding is taking our jobs. That it’s making it harder to build simple SaaS businesses and monetize them, and that people can just build these things internally and be perfectly happy with those solutions.
I believe that is utterly and completely false.
Because it’s easy to vibe code a project, but it’s incredibly hard to vibe code a business.
And I think people who have never built a business but who have strong opinions about software engineering mistake one for the other.
You can build a product with all kinds of features—that’s not a problem. But a business, and that is the main part of what Software as a Service is, has significantly different requirements than just building a software tool.
In fact, I think people are so focused on the “software” aspect of the whole “software as a service” terminology that they completely forget that it was never really about the software.
Software as a Service was always about the service. Always about the operation of software, the implementation of software changes, the adaptation of software to new things. The actual value of a software as a service business is in running and supplying the software, not in the software itself.
When Vibe Coded Solutions Break Down
If you understand that, then you know that AI tooling will only ever—at least in this current situation that we’re in, which is likely going to be true for another couple years—be good at creating software. But it will be very limited at creating and, more so, maintaining businesses.
You can vibe code a product, no problem. And it can look and feel like an actual human-built software business. But the moment your first customer service request comes in, the moment your first integration request comes in, the moment somebody has a problem with their data that you might need to adjust in a database, or somebody needs a certain file format supported and makes that a requirement for their purchase—you’re going to end up in vibe coding hell.
Because the vibe coded solution operates under certain assumptions, and every single feature request will change these assumptions. Every single thing that your customers do or want will be a re-evaluation of your initial assumptions.
That’s the whole trick here. That’s the whole basic truth that a lot of people with strong opinions seem to be very intentionally forgetting.
A software product is the outcome of a business effort. A SaaS is a way of solving a business problem. And to be able to comprehend not just how to solve that problem, but what that problem is in the first place—who really struggles with it, who should be approached to purchase it, how they should be talked to, how they can be convinced, what alternative solutions they are using, and what they think about the field and certain implementations, certain features, certain ideas—that takes a lot of experience. It takes nuance and industry insight.
Most software products come from a niche, from a very specific subset of an industry. And if we’ve learned one thing about the LLM systems that we all use to prompt our way into products, it’s that these are built for consensus purposes. An LLM can act like it knows a lot about a specific thing, or it can act as a niche persona. But in the end, it will always be the consensus engine that we created it to be.
The Comprehension Debt Problem
And I think it’s very significant that we understand this.
For a product to be built well, the problem and the solution have to be deeply understood, then implemented, and then adjusted. All these vibe coding tools seem to me like a flicker in time. Some of them are great, and some of them will fulfill a purpose. But they all come with an extremely heavy maintenance burden.
That burden is surprisingly bearable when it is the result of a human project, because people have a strong internal understanding of what their codebase and product is doing. But it is extremely frustrating to deal with in a vibe coded project.
If you ever have a vibe coded solution, or even a heavily AI-assisted solution that does not have proper documentation, the AI will struggle—not just struggle, but fail—to remember what it was thinking when it was building the thing in the first place.
While it is being built, while the context window exists, you will find that AI tools are very capable of maintaining internal cohesion. But the moment that window is gone, the moment you end your session with Lovable or whatever, the internal understanding—the representation of what the vibe coded tool was meant to build—is gone forever. It literally vanishes into an unrecoverable state because it’s not meant to be understood or persisted or maintained.
Maybe in the future we will have ways to create a fully comprehensive internal understanding of a codebase, plus everything in the business around it. But right now, we’re not there.
I talked about this recently on the podcast when I was discussing comprehension debt versus technical debt. That internal understanding is still for us to maintain. If we use AI tools, we need to persist it into text files that can be read by AI tools and humans—comments and strong architectural documentation.
Traditionally, software engineering used to work like this: somebody architects, they write up docs, they write up specs, then they implement it. They fully understand what they built, and they write tests so it can be tested, because they have an expectation of what things are going to be like. The test is written to see if that expectation holds true.
But if nobody has that knowledge, how can you know if your codebase is working and doing what it’s supposed to do? If it’s small, sure, you can kind of test your way through it. But if it’s not, then all of a sudden you have a problem. A really, really big problem. Because you won’t be able to know at all what your product is. And a product that is unreliable creates a business with high churn, with low retention—and ultimately, a business that fails.
So the phrase isn’t “SaaS is dying because of AI.” It’s more like: certain kinds of software engineering are changing because of AI. But it has so little to do with the actual potential of software as a service businesses as a concept dying out because people can now tell Lovable or some other tool that they want a certain thing done.
That’s not the case. That is definitely not the case.
The Pareto Principle: Why People Buy Your Last 20%
Think about why people buy a software as a service product. Often, it’s not that they couldn’t build something like it themselves.
We often think about “buy versus build,” and in many ways, during sales, it’s the conversation where you try to convince people that their build cost would be significantly higher than their buy cost. That’s definitely true in many cases.
But people are very well aware that they could build a software product—your software product, very likely—because the moat, in many ways, is just time and energy spent.
Yet they still choose to buy it from you.
The reason is the Pareto Principle. 80% of the way there takes 20% of the time, but the remaining 20% of the work effort takes 80% of your time.
And most people who are in successful businesses themselves—you know, your buyers—understand very well that they don’t see the 20% that you have figured out over the last couple years.
This is why people buy SaaS businesses that have been around for a while. They want to see that you’ve struggled for a bit, so you’ve truly understood all your customer needs.
Smart people will buy your product because they are perfectly aware of the fact that you’ve covered edge cases. That you have discovered specific, really hard to maintain integrations into systems that they don’t even know exist.
That’s why people buy your software as a service product. Not because it’s 10% cheaper than if they were to build it themselves.
Of course, a lot of people think they have to build everything in-house, or otherwise it’s a dependency risk. But building a software tool that other people employ half a dozen staff to maintain as a business, all in itself, clearly has opportunity cost that will likely outpace the $200 a month that you might be paying for a subscription.
People will always have these weird issues and weird understandings when they make their purchasing decisions. But I certainly feel that your ideal customer understands that they buy your SaaS for the last 20%.
Making the Invisible Visible
Which brings me to the whole point of this.
If SaaS is not dying, but vibe coded internal solutions are much easier for people to build, how can we make sure that the last 20%—the invisible stuff—becomes visible? Not so that people can copy it more easily, but so that it becomes an argument for why people should buy our solution instead of building their own.
I think this will be an ongoing struggle over the next decade or so.
We’ve understood this in software as a service, right? We understood that customers aren’t buying our software—they’re buying peace of mind. They’re buying having their thing figured out and having that problem solved.
Well, now this might actually swing back into the direction of them buying something that even they could kind of make themselves. But it still is better because it is built from certain experience, or it’s something that would be very hard for them to get right, very hard to even approach correctly.
In our self-description, maybe we don’t sell the solution to problems as much anymore. Or when we do, we show that there is complexity to it and an interdependency to it that they may not have expected.
Maybe we are upfront with our buy versus build equations. Instead of waiting for a customer to ask us about this, we tell them: “Hey, this would probably cost you $50,000 to $100,000 to build, and at least thousands a month to maintain with a service level agreement. Or: a $2,000 subscription with a service level agreement. We have integrations with 56 different data providers to get the data that you need—you just need one login.”
The conversation will be shifting, because we’re now talking to people who are technically capable of building their own systems. Every company now has somebody who at least understands AI a little bit. People will try to consider that they could possibly build everything.
Maybe we give them a clear background. We give insight into just how complex it would be to build this. And they will benefit from us having it already built for them, because we have built the last 20% already.
That’s what we’re selling to them. But it is time to make this more apparent.
Final Thoughts
Vibe coding isn’t killing SaaS. It’s changing how we need to communicate our value. The service in “software as a service” has always been the point. The edge cases, the integrations, the accumulated wisdom from serving real customers with real problems—that’s what people are paying for. That’s what they’ll continue to pay for.
And if you’re building a SaaS, lean into that. Show your work. Make visible what was always invisible. Because the person who can vibe code a clone of your product in an afternoon still can’t vibe code the years of customer conversations and hard-won insights that made your product actually work for people.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week’s essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
