The Bootstrapped Founder

Hey. It's Arvid, and this is the Bootstrap 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, just a lot of hype, and a lot of complaints about the imminent demise of software as a service businesses and solutions. I think it's time that we have a voice out here that's not a doomer. And I know there are some people who are more pragmatic about this, but a lot of it out there right now is just so apocalyptical.

It's crazy. I'm certainly not an apologist for the software as a service movement either. Like, not all about it is great. 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 and they take care of all the taxes, currencies, all the transactions when they're declined, and credit cards when they have to be updated. So I could just focus on my own customers. If you would rather build your product instead of dealing with all of these banks and regulators, check out paddle.com as your payment provider and your merchant of record. I believe that while Software as a Service may struggle with things like subscription fatigue right now there's a lot of people who don't want to pay one more thing a month or even some vibe coded slob solutions are replacing certain purchases that some 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 of things that 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. Most importantly, I think people who believe that just because you can go to bold.new or to a vZero, Lovable, whatever the tool might be, explain what you want and then have a Vibe coding tool pretty much build whatever things 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 a false interpretation maybe we should determine what exactly Vibe coding is.

Because a lot of software developers see AI and they think like Vibe coding, I mean, it's the same thing. Mostly because the consensus in our community is that this is what it means. And I don't believe so. Vibe coding is a version a subset 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 really don't care about the underlying code at all. You just say what you want, the thing builds and it deploys in the background and then it runs. That to me is a vibe coded app. But the moment you dive into the code, the moment you understand it, the moment you know what the components are underneath the UI or the API it's not a white coated project anymore. It is at most a strongly AI assisted software engineering project.

So here is my definitory exercise. The general consensus, let's call it the 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 that is completely false because it's easy to Vibe code a project to some degree maybe but it's incredibly hard to vibe code a business if not impossible and I think people who have never built a business but who have strong opinions about software engineering mistake one for the other here You can build a product with all kinds of features that is not a problem. But a business and that is the main part of what software as a service is service part 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 part always about operating the software the implementation of changes the adaptation of software to new things. The actual value of a software as a service business and being a customer of one is that somebody is running and supplying the software not that the software itself contains the value. If you understand that that the value of a SaaS is in the service not in the software 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 coat 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 or the moment your first integration request comes in or somebody has a problem with that data that you might need to adjust in a database or build this particular feature they need a certain file format supported and they make 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 that come with that system on which it is built and every single feature request that you get will have to change these assumptions but it won't be able to and everything that your customers do or want it to be will have to lead to a re evaluation of your initial assumptions and these vibe coding systems are not good at this.

And that's the whole trick here. That's the whole basic truth that a lot of people with strong opinions seem to be intentionally forgetting: a software product is the outcome of a business effort. A SaaS is a way of solving a business problem, a challenge and to be able to comprehend not just how to solve that problem but what the problem is in the first place, who struggles with it, who should be approached to purchase the solution, who they should be talking to, how those people can be convinced, what alternative solutions they are currently using and what they think about the field and certain integrations, implementations, features, ideas. All of this takes a lot of founder experience it takes nuance and industry insight most software products exist in and come from a niche from a very specific subset of all the potential problems and solutions in an industry and if we have learned one thing about the LLM AI systems that we use to prompt our way into products now is that these tools 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.

Right? Any LLM that you task with something is trying to be the best for everybody at this particular thing and that just doesn't work in the niche setting. It is very significant that we understand this as founders. For a product to be built well the problem and the solution have to be deeply understood and then implemented and then permanently adjusted all the time. All these vibe coding tools seem to be 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 they themselves cannot solve that they cannot deliver and that burden is surprisingly bearable when it is created as a consequence of a human project because when people build something they have the strong internal understanding of what their code base, their product is about and what it's doing and how it works but it is extremely frustrating to deal with this in a Vibe Coded project if you've ever Vibe Coded anything or even heavily AI assisted something that doesn't have proper documentation then the AI will struggle and not just struggle but fail to remember what it was thinking when it was building the thing in the first place while stuff is being built while the context window exists you will find that AI tools are very very capable of maintaining internal cohesion right they have this understanding of what they're doing but the moment that window is gone either by compression or when you end your session with Lovable or whatever the internal understanding this fully fledged representation of what the vibe coater tool was meant to build is gone forever.

It literally vanishes into this unrecoverable state because it's not meant to be understood or persisted or maintained. It is just meant to exist for the moment that things are being built and then it's gone. And maybe in the future we will have ways to create this fully comprehensive internal understanding of a codebase like that I have in my mind about my own codebase right now. Maybe an AI can recall it or persist it plus everything in the business around it but right now with the tools we're talking about today we're not there and I talked about this recently on the podcast when I was discussing comprehension debt a new version of technical debt it's different than technical debt because it's not really code related it is representation related it's that internal understanding that is still for us as a founder as a developer to maintain so if we use AI tools we need to persist that kind of into text files that then can be read by AI tools and by other humans either using comments or strong architectural documentation whatever it needs we need to kind of make it more accessible to the AI system and traditionally software engineering used to work like this right somebody architects the thing they write up docs they write up specs and then they implement it.

It doesn't necessarily have to be waterfall it could also be you know scrum and you repeat it and you have sprints and whatnot but this is a thinking step, documentation step, a discussion step, and an implementation step. And people fully understood what they built at least you would hope so and they would write tests because they had an understanding of what it should be doing and then implemented it so you could test if a thing is doing what it should be because we have this 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 anymore, if it is just vanishing after you use the tool how can you know if your code base is working or doing what it's supposed to do? If it's small sure you can kind of test your way through it manually or even have an AI kind of comprehend it on the fly by reading it all but if it's not if it's bigger if it's more complicated 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 actually is not just what it does but also what it is you just don't know and a product that is that unreliable because nobody knows what they have created well that just makes a business that has high churn low retention and ultimately it turns into 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 a software as a service business as a dying concept because people can now tell Lovable or some other tool that they want a certain thing done in a certain way that's definitely not the case.

Think about why people buy software as a service products because often it's not that they couldn't build something like that themselves There are people out there who are amazing developers buying software for developers that they could have written. We often think about buy versus build and a lot of companies have let's call it a sales challenge. Right? They would rather build it themselves. 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 and that's definitely true in most cases for most SaaS but people are very well aware that they could build any software product your software product very likely because of the moat that you have that really is just time and energy spent it's really not much more than that for most software as a service businesses at least that's the perception out there right and yet they still choose to buy it.

I think the reason here is the Pareto principle 80 of the way there takes 20% of the time but the remaining 20% of the work takes like 80% of the time and most people who are in successful businesses themselves you know your buyers hopefully they understand very well that they don't see the 20 that you have figured out over the last couple years that would turn into the 80 plus percent of work for them. This is why people buy SaaS businesses products that have been around for a while. They kind of want to see that you struggled for a bit, that you did the legwork, and you've truly understood all your customer needs. Smart people will buy your product because they're perfectly aware of the fact that you've covered all the edge cases, that you've encountered every single little thing along the way. You've discovered specific, really hard to maintain integrations into systems that they don't even know exist yet because they didn't have to dive in as deep as you did.

That's why people buy your SaaS ultimately not because it's 10% cheaper than if they were to build it themselves. People who think like this they are not successful founders or successful builders or they work for companies that are so hilariously overcapitalized that they can't think it and still turn a profit. Of course a lot of people think that they have to build everything in house or otherwise it's a dependency risk that often comes up as an argument against it but building a software tool that other people employ half a dozen staff to maintain as a SaaS business all in itself clearly has opportunity costs that will likely outpace the $200 a month that you might be paying for a subscription. I often wonder why people don't seem to be able to take that particular leap. Either they pay $200 a month for my tool or they pay $20,000 a month to keep the team working on their version of my tool.

People will always have these weird issues and weird understandings when they make their purchasing decisions but I certainly feel that your ideal customer not the customer that has too much money or too little money your ideal customer the middle there they understand that they buy your SaaS for the last 20% like you're 80% but their 20%. 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 well how can we make sure that these last 20% the invisible stuff becomes visible? Not so that people can copy it more easily into their own internal solutions but so that it becomes an argument for why people should buy our solution instead of building their own and I think this is going to be the ongoing struggle over the next decade or so in this particular realm of technology. We've understood that in software as a service. We understood that customers aren't buying our software they're buying a peace of mind or they're buying having their thing figured out and that having their problem solved that's a big thing we put on our landing pages now.

This might actually swing back into the direction of them buying something that even they could kind of make themselves but it's still better because it is built from experience or it's something that would be very hard for them to get right very hard to even approach correctly. So in our self description maybe we don't sell the solution to problems as much anymore or when we do we show that there's so much complexity to this and an interdependency to all of those components that they might not have expected maybe we are upfront with our buy versus build equations too I think it's generally a good idea I've had a couple of conversations with people who are interested in buying a POTScan subscription, and they were like, yeah. We were trying to build this in house, but then we figured out this was super expensive. So I've kinda learned what people have figured out the cost of this might be. So instead, next time you talk to one of your customers in call or something, instead of waiting for customer to ask you about this, well, maybe tell them this would probably cost like $50,000 to $100,000 to build and at least $10,000 a month to maintain with a service level agreement worth of reliability.

Or here is the same thing for $2,000 a month as a subscription with the same SLA. We have integrations with like 56 different data providers to get the data that you need. You just need one login. If you were to build this yourself you would have to make those arrangements with over 50 different people. That is the stuff we now need to bring to the table.

The conversation will be shifting. We're now talking to people who are technically capable of building their own systems and maybe we always have but now it's much much easier even for the people who don't have the extreme technical talent that the larger companies had in the past. Every company now has someone who at least understands AI a little bit and people would try to consider that they could possibly build everything. Maybe we just give them a clear background. We give insight into 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 I think it's time to make this more apparent. It needs to be communicated more clearly. So vibe coding is not killing SaaS, it's changing how we need to communicate our value, the value prop, and the service in software as a service has always been the point. The edge cases, integrations, the accumulated wisdom from serving real people with their real problems that's what people are paying for and that's what they'll continue to pay for and if you're building SaaS lean into this show your work make visible what was always invisible before Because the person who can vibe code a clone of your product in an afternoon, they still cannot vibe code the years of customer conversations and all these hard won insights that made your product actually work for people.

And that's it for today. Thank you for listening to The Bootstrap Founder. You can find me on avidkahl, a r v I d k a h l. If you're a founder, a PR expert or a marketing professional wondering what people are saying about your brand, well, you might be missing these conversations. Podscan.fm monitors over 4,000,000 podcasts in real time and will alert you when people talk about you.

And if you are a founder still searching for your next venture, you can go to ideas.podscan.fm, where we identify startup opportunities from hundreds of hours of expert conversations every day so you can build what people are asking for. Please share this with anybody who needs to turn conversations into their competitive advantage because it would really help. Thank you so much for listening. Have a wonderful day and bye bye.