Call us when your vibe-coded option needs to grow up
At some point, your experiment becomes infrastructure. Here's how to know when you've crossed that line — and what to do about it.
The vibe-coded tool worked; now it's the system.
You built something fast, a few hours with an AI assistant, something that solves a real problem, and people started using it. Then they started depending on it; then it started touching real data, real money, real decisions. Now it's the thing everyone expects to be there on Monday morning.
That's a different problem from the one you started with.
What changes when it becomes load-bearing
A prototype and a system look identical from the outside; the difference is what happens when they break. A prototype breaks and you shrug; a system breaks and you have a crisis.
When your vibe-coded build becomes load-bearing, several things become true at once. Someone needs to understand how it works well enough to fix it when it fails. It needs to handle edge cases nobody thought of during the build, be auditable for finance and compliance, and be maintainable by someone who wasn't there when it was built.
Vibe coding optimises for speed; none of those things are fast.
The signs you've crossed the threshold
You've built something load-bearing if any of these are true: people would notice if it stopped working; it handles data you'd be embarrassed to lose; it makes decisions or calculations that affect money or contracts; or you've stopped calling it a prototype but haven't done anything differently about how you treat it.
If two or more of those are true, you're running a system with prototype-grade engineering; that gap will close eventually, one way or another.
What to do about it
A scrappy build that actually works is a good starting point; you've validated the idea, you know what people actually use and what they ignore. The job now is to make it sustainable: to understand what you have, what it needs to become, and what the path looks like between the two.
That conversation is usually shorter than founders expect; it doesn't always mean a full rebuild, sometimes it means adding the right guardrails to what's already there. But it does mean looking at it honestly, with someone who's done this before.
If your vibe-coded tool has become something people depend on, let's talk about what that means.
Robin Carswell
More on
Use vibe coding to escape the SaaS you've been stuck with — part 2
You built it quickly, it worked, and now the business depends on it. Here's how to tell whether your vibe-coded build is worth stabilising or worth replacing — before the next thing breaks.
Use vibe coding to escape the SaaS you've been stuck with
You've got at least one SaaS tool your team complains about and you've been meaning to replace. Vibe coding has made it cheap enough to run a proper experiment — here's how to find out if your worst offender is simpler than it looks.