Use vibe coding to escape the SaaS you've been stuck with — part 2

Use vibe coding to escape the SaaS you've been stuck with — part 2

You built it in an afternoon. It was supposed to be temporary — a quick fix while you waited for budget to buy the proper solution. Then it worked, and people started using it, and now it's handling 300 submissions a week and occasionally dropping them.

This is not a failure. It is exactly how useful software gets built. The problem is what comes next.

The signs

A vibe-coded build tells you it's outgrown itself in fairly consistent ways.

It starts missing things. Submissions drop. Notifications fire twice. Exports come out wrong on the third Tuesday of the month when there's a bank holiday in the previous week. You fix one thing and something else breaks.

The person who built it — probably you, or someone on your team who spent a weekend with an AI assistant — can no longer explain with confidence how all the parts connect. It works, mostly, but the mental model of why it works has faded.

And it's now in the critical path. Whatever it was meant to do temporarily, the business is depending on it.

What growing up looks like

This is where the decision splits.

Some vibe-coded builds are genuinely worth replacing properly — with a real SaaS tool, a proper integration, or a piece of software built by someone who writes tests and documents their decisions. If the function is important enough and the build has become fragile enough, rebuilding on solid foundations is the right answer.

Others are worth keeping and stabilising — not throwing away, but documenting, testing, and making less dependent on tribal knowledge.

The question is which category yours is in. That depends on what the build actually does, what it connects to, and how much it matters if it fails.

That is the conversation worth having before the next thing breaks.

That's the conversation we have with founders who've got something working and need to decide what comes next. Get in touch