There are wild claims that AI-generated vibe-coded apps can be a replacement to SaaS (software-as-a-service) products. From paid-per-user to full enterprise contracts, the idea that 3 hours and a $100 of Claude tokens can replace a maintained software products is both laughable and dangerous.
While it might seem attractive to a CTO or startup looking to cut costs with a quick AI vibe-coded replacement, what quickly becomes apparent is all the things you didn’t realise you were paying for:
You are paying for all of the features you aren’t using
You are paying for features you didn’t realise you are using
You are paying for all of the features that haven’t been developed yet
You are paying for someone to maintain it
You are paying for security - you are paying a lot for security
You are paying for someone to blame when things go wrong
For all these reasons, there are trade offs (which I’ve included below) that will help clients and salespeople figure out the answer to “do you want to keep subscribing or just vibe-code your own”.
I won’t say that AI code isn’t interesting and fun. I’ve used it in some personal projects to fill in some of the less fun parts of coding or to quickly generate UIs. What comes out of these experiments is interesting and functional. But investigating AI-generated code you quickly see misunderstandings of requirements, overly complicated logic, or hardcoded approaches that can’t scale.
As a founder of a business-to-business SaaS company, I’ve also had many conversations with price-sensitive clients negotiating on cost. Some of the more interesting negotiation tactics I’ve heard have included:
You’ve already built the software, can we just pay for the server costs (lol, no)
We’d like this feature, can you build it for us (sometimes - but usually its so bespoke no one else wants it)
We don’t need this feature, do we have to pay for it (usually no because its a core feature - but pricing is always negotiable)
Clients are always in their rights to negotiate a good deal for themselves, and if I can’t prove value they are also entitled to walk away - and some have. But some of them have also come back, because they realised how difficult building software is.
We had a situation with a client during a subscription renewal, and their internal IT team assured them they could replicate one of our tools in 6 weeks - and since the team was already on staff, they were already paid for it would have no cost. We could have tried to fight this mentality or give them an unsustainable discount. Instead, we gave them a spec sheet and list of features they insisted were non-negotiable, suggested they speak with their IT team, and wished them well. They returned about 3 weeks later, and the subscription was renewed.
When you build a pay-to-spec product it does exactly what a client wants and nothing more. But as a SaaS provider, you need to build features that meet most of the needs of most of your clients. If I had to estimate, I would say that we do about 80% of our clients need. There are always edge cases that are so specific to a single client that its not worth building.
The flip side is that there are about 30% of features that clients aren’t using. If we have features A,B,C,D one client might be using A,B & C and another A,B & D. The first client might think that they should be paying for D, or might not even realise feature D even exists.
What to ask: are there features in our subscription we aren’t using? If so, do any of them add value?
Another challenge of working with B2B SaaS tools is the adage, that the person who uses the tool is rarely the person who pays for it. This means there is a disconnect between users, sales and owners, and you may never meet everyone who uses the tool.
What this also means is that there are feature that only one or two users will you, and maybe infrequently at that. Good examples are features like reporting, which are only used monthly, quarterly or yearly. And not at the same time as contract negotiations.
Another “feature” that you might pay for and never realise is backend infrastructure, such as high-availability, to meet unusual surge demand. Cloud infrastructure makes it easy for SaaS providers to scale servers on demand, which can be vital for clients with unusual load. This could be an online jewellery store with surges around Valentines Day. Because surge cloud capacity comes at a high cost, a way for the SaaS providers to mitigate this is to spread the cost over all clients over all months. Rather than have a low monthly cost, with high costs in some months, they may spread this over the contract and absorb any excess if it occurs.
What to ask: have we accounted for all the features we use - look to infrequent admin features, and ask, do we really need high-availability?
One of the coolest things about running a product company is I get to build feature I think are cool. I really like building metadata software, I like going to conferences and reading about the market, and I like talking to clients about their issues. It’s a bit of a problem for me. But it also means I like surprising clients with new features that solve problems they didn’t even realise they have.
This is why you are paying for a SaaS. I understand that no subscription is guaranteed, and I tell clients this - “as your SaaS provider I don’t treat your renewal as a sure thing, I have to earn it”
It also means that you are paying a small monthly cost for very expensive development time, including development, testing, documentation and use cases.
What to ask: What features are coming up on the roadmap? Can we give you ideas for the upcoming roadmap?
What ever you build, you are responsible for. It doesn’t matter if its hand coded or vibe coded, its still your responsibility. This is especially true when it comes to matters of security.
There are plentiful examples of vibe-coded solutions with hardcoded and exposed database credentials, or web apps built with no permission controls at all. All of these are potential vectors for a hacker to enter your system and take the data they are looking for.
But securing an application isn’t just adding a password to the database. Security is how the app is built, but also the password on the database, the strength of the password on the database, how the key to the database is secured and shared, network controls to limit access to the database, auditing to detect if anyone misused the key and even the auditing to detect if anyone misused the audit logs.
These are all the things that are reviewed when it comes time for a security audit like ISO27k, FedRAMP or IRAP. Not just the technical security of the system, but all of these auditing and policy controls around it.
Not only does the cost of implementing these controls come at a cost, getting assessed costs a lot more on top. ISO27001 or IRAP assessments can range from tens to hundreds of thousands of dollars.
When you build your own system, if you need this level of security, you are now taking 100% of this cost on board. When you bring in a SaaS, there is the option for them to spread this cost over many clients. In the example above $170k a year may just be the cost of a security assessment alone, without even including the cost of the tool itself.
What to ask: how secure does our app need to be, do we really need that security tick of approval? And if we do, how much will it cost to get that assessment.
If you vibe code you own solution, you have just accepted responsibility for it. If there is a bug, you have to fix it.
Even if your SaaS provider never adds another feature, there is a lot that goes into maintaining software. As mentioned, there will likely need to be security updates, and this means dependencies change, which means code needs to be updated to support these new libraries. Features could be depredated, UI widgets may change, APIs may need to be redone.
All of this is what goes into maintaining quality software, and it takes a lot of effort to do so, and that is what you are paying for.
But you are also paying for the invaluable service of someone you can blame. On of my former managers introduced me to the term “blame sponge”. Someone whose entire role is to absorb all of the blame when something goes wrong.
Your SaaS provider is your blame sponge.
If something ever goes wrong with the software, your SaaS provider is there to fix it and give you an apology. If something doesn’t go wrong with your software, your SaaS provider will also be there to give you an apology. If you forgot to run a report and your boss gets made, call your SaaS provider and they will probably soak that blame for you - it was a scheduling bug, cosmic rays flipped unshielded quantum bits that turned a server off. If it helps the client, the SaaS vendor will do it, knowing that by renewal time it’ll be long forgotten.
What to ask: do you have the time or budget to support this software in the long term - and who will you talk to when things go wrong.
This is what you pay for when you pay for a SaaS because the first word is “software” but the last word is “service”. And take it from someone with experience founding and sustaining a B2B SaaS startup, most of the cost of a SaaS is in the service, not the software.
As a buyer, if you aren’t getting the service they you need to look elsewhere - but you also need to look a little deeper beyond the software to see what you are really paying for.
As a B2B or enterprise SaaS seller, this is your opportunity to really shine and stand out from the pack - think about the service you really offer and how you sell that. People will always pay a premium for piece of mind, if you can demonstrate how your offering does that, no vibe-coded tool will replace that.