Vibe Coding Is Easy. Production Is Where It Gets Hard

There’s a pattern emerging across conversations with our clients right now, and it’s worth some attention. Across companies of all sizes, “solutions” are being “built” in a matter of days using AI-assisted development. These “solutions” do exactly what the team had described as the business problem; the prototype is clean, and the business case is obvious. AI tools have made prototyping genuinely fast. What used to take weeks can now take minutes. A developer, a business analyst, a product owner with the right tools can produce something working, interactive, and convincing in a very short window.

This is real progress, and we use those same tools. The speed isn’t an illusion.

But three months on, the “solution” isn’t live and the problem isn’t solved. And this is where the real pattern lies – building a prototype is now (inconceivably) easy, but building a secure solution that can scale and is ready for any future iterations (“a version two”), still requires domain judgement and technical expertise. The real technical hurdles to building robust, production solutions remain in place – cost to run at scale, secure access and control, a comprehensive testing approach, and probably most importantly, knowing what could happen if something went wrong in production.

Getting the prototype working is roughly 20 percent of the job. The other 80 percent is what most people don’t see until they’re already in it.

What The Gap Contains

A prototype and a production system are genuinely different things. The prototype demonstrates the concept. The production system has to serve real users, handle real load, stay up when things go wrong, and be maintained by whoever inherits it next. This transition is where most vibe-coded systems get stuck, and it’s the part that tends to get underestimated at the start.
Most prototypes that aren’t yet production-ready share the same set of gaps. They almost always come down to some combination of the following:

Security and governance

Vibe-coded prototypes are built fast, and fast tends to mean permissive. Access controls are minimal, MFA is hard-coded and there is almost always no audit trail. These aren’t problems you can ignore if the system is handling anything sensitive and regulated, which most business systems are.

Scalability

A prototype that works with one user often doesn’t work with two thousand. The assumptions baked into the architecture at speed, single-instance designs, no queuing, no handling of concurrent requests, become structural problems when real users arrive. Rearchitecting when the system is under load in production is often expensive and disruptive.

Cost

This one surprises people. A poorly designed system can be remarkably cheap in development but unexpectedly expensive in production. LLM pricing is token-based, and architectures that pass every context window into the model regardless of relevance will definitely mean money at scale. Cost optimization has to be a design consideration from the start.

Reliability

What happens when something fails? Prototypes typically have no retry logic, no graceful degradation, no fallback paths. A production system needs to stay up or recover cleanly, and that requires infrastructure decisions and disaster recovery thinking that often doesn’t happen during the prototype phase.

Automated testing

Prototypes are built quickly and, as a result, long-term testing and test coverage is not considered. A system with no test coverage can cause damage downstream and every change becomes a risk. In the long term, as the code needs to change as the business changes, the production system may technically work but nobody wants to be responsible for it.

Observability

If something goes wrong in production and you have no logging, no monitoring, and no audit trail, your options for diagnosing it are limited. Good observability is what turns a production incident from a crisis into a solvable problem.

The Version-2 Test

There’s a useful litmus test as to whether a system is truly production-ready: is version two of the solution cheap to build?

Vibe-coded systems often pass the first test. Version one ships and it works, but as the team tries to build version two, the code is full of hidden dependencies, the abstractions don’t fit the new requirements, and the architecture won’t flex without breaking.

The mitigation strategy isn’t to add tests at the end as that treats the symptom rather than the cause. The real fix is to build version two from the beginning, with architectural tests that maintain the architecture’s structural integrity and behaviour, CI/CD pipelines that make it safe to change things, and event-driven design where it earns its place. These decisions have to be made early, because retrofitting them later costs far more than building them in.

What Closing The Gap Looks Like

The answer is not to avoid prototyping. Prototyping is incredibly valuable, and we love to prototype. It proves the concept, visualizes the solution, creates alignment across teams, and often reveals requirements that would not have surfaced in upfront documentation.

The answer is to treat the prototype as the beginning of the solution design rather than the end of it. When we work with a prototype, we walk it against each of the attributes above, identify the gaps, prioritise the ones that matter most for that particular system and context, and build a path to something the organisation can actually rely on. That might mean rearchitecting for scale, reviewing security with a fine-toothed comb, or introducing a proper testing harness and accepting that things will slow down for a few weeks so they can go faster later.

The organisations making the most progress right now aren’t the ones who moved fastest from idea to prototype but rather treated the prototype as a proof of concept and invested in closing the gap properly before they scaled. This distinction matters more than most people realise until they’re staring at a system they can’t change.