What a vibecoded prototype still needs before it can run a business

Today, an idea for an app can become something working in a few hours. You describe what the app should do to an AI coding tool such as Cursor, Claude Code or Lovable, or to an assistant such as ChatGPT or Gemini, and by the evening you have a version you can show someone. That speed is genuinely useful: you test the idea, put it in front of real people and gather feedback before committing a bigger budget.

That is vibecoding: describing what an app should do in plain language, letting the AI write the code, and judging the result by whether it does the job rather than by reading every line. It is a new way to get from zero to something clickable, and founders and product teams are adopting it for a simple reason: it works, for what it is built to do.

Then the question changes. The prototype answered “is this idea worth pursuing?”. The next question is “can people depend on this?”, and that is a different test. A clickable demo and a product that customers, staff or partners rely on every day are two different things, even when they look identical on screen.

What a fast prototype shows, and what it does not

A vibecoded first version shows the idea can work in principle and gives you something concrete to put in front of users. It rarely shows that the software can carry real users, real data or a real operational process, because those decisions were mostly never made on purpose. Architecture, access control, error handling, what happens when something breaks: little of that makes it into a weekend build. It shows up later, once the cost of having skipped it has grown along with the user base.

None of this is an argument against building fast. It marks where the job changes: from finding out whether an idea works to answering for it running.

The four questions we ask before anything goes further

Before a prototype moves toward a pilot or live use, we run it through the same four questions, no matter where it started:

1. What does this component do when it fails, not just when it succeeds?
2. Which decisions here should stay reviewed by a person, and which are safe to leave unsupervised?
3. What happens to this at ten times today’s users or data?
4. If this stopped working at 2am, who notices, and how?

The answers sort the prototype into three piles: what can be kept as it is, what can wait while a limited pilot runs, and what has to be addressed before customers or sensitive data depend on it. That sorting is the decision. It turns “is it ready?” from a feeling into a plan.

A hypothetical example: demo, pilot, live use

Take a case invented for this article. A founder has vibecoded an interface for a small service business: staff log customer requests, assign them and track them to completion. It replaces a spreadsheet, the team likes it, and the founder wants to start using it with real customers next month.

Run through the four questions, the picture looks roughly like this.

Keep. The screens and the workflow. They came out of real feedback from the people who will use them, which is exactly what a prototype is for. The same goes for the data model, if it has held up against real requests.

Can wait through a limited pilot. Scale and polish. With one team and a few dozen customers, ten-times growth is not next month’s problem. An internal pilot with a fixed set of staff, a named owner, a manual fallback (the old spreadsheet) and sample or synthetic records instead of real customer data can start while these questions stay open, as long as everyone knows the pilot is a pilot.

Must be addressed before customers depend on it. Three things stand out. Customer records: names, contact details and request history are personal data, so where they are stored, who can read them and how long they are kept has to be decided deliberately rather than left to whatever the tool defaulted to. Access control: one login shared by all staff, or admin rights the AI wired up for everyone, is fine for a demo and unacceptable once the data is real. Recovery: if the database is lost or corrupted, there has to be a backup that has actually been restored at least once in a test, and someone who knows how to do it.

Nothing in the third pile stops the idea. Each item is bounded work with a clear finish line. What the sorting gives the founder is a decision path: start the internal pilot on sample data now, fix the three blockers while it runs, open the pilot to real customers and real customer records once those safeguards are in place, and move to live use when the pilot has held up rather than when the calendar says so.

Two different meanings of “AI review”

Two separate questions get blended when people talk about reviewing AI in software, and they need different answers.

The first is about the code. AI-generated code is code like any other: it needs a team that can understand it, test it, secure it, operate it and change it a year from now. The tool that wrote it carries none of that responsibility. Someone has to be able to read the parts that matter, know why they are built the way they are, and take the call at 2am. Custom software development is the part of the job that puts that ownership in place, once the idea has earned the investment.

The second is about decisions the product makes while it runs. If the app uses AI to classify a request, draft a reply, approve something or flag a risk, the question is no longer whether the code was reviewed but whether each decision needs to be. Good AI solutions and automation keep a person in the loop wherever a wrong call is expensive or hard to undo, and let the system run unsupervised only where getting it wrong barely costs anything. A prototype usually makes that choice by default. Live use needs it made on purpose.

What changes when we take it further

Taking a prototype toward something a business can run on is the same work we start every engagement with: understand how the business really operates, design around that reality, build in increments the client can review, and hand over in a state their own team can run and improve. Code, documentation and project accounts stay theirs the whole way through.

For a prototype, that usually means keeping what already earned its place, scheduling the rest against the three piles above, and delivering each increment in a form your team can test with real users before the next one starts. The point is a product that keeps operating after the engagement ends, with the people who own it able to change it.

Where this fits your timeline

Needing this step does not mean the idea is behind schedule. It means it is on schedule. The fastest way from an idea to something customers trust rarely means squeezing more out of the first version. It means bringing in a technical partner at the point the software needs to hold up, before that point gets forced on you by an outage, a hard security question or a user base the original build was never meant to carry.

If you have a prototype and are weighing live use

If you are deciding whether an AI-built prototype can go into a pilot or live use, the most useful thing you can send us through the contact form is four short answers: what the app does, who relies on it, what data it holds, and which failure would interrupt the business. That is enough for a first conversation. We will tell you which questions we can already answer from that description, and which need a closer look at the code and the setup.