From vibe coding to a real product: the hard part begins when the app works

Building an application with AI can take a weekend. Building a product that people trust with their payment, their data and their return visit is a completely different problem.

Vibe coding has dramatically shortened the distance between an idea and something that works. We can describe an application, generate an interface, connect a database and deploy a first version without mastering every technical detail of the implementation.

This is a significant and, in my view, very positive change. People who could not previously turn their ideas into software can now experiment with them. Developers can explore alternatives much faster. Teams can put something concrete in front of users before investing months in building it.

But that speed can conceal an important distinction: a functional application is not necessarily a product.

A demo proves that an idea can be executed. A product must prove that it can survive contact with real people, real data, real expectations and problems that were not part of the script.

A demo works when everything goes right

The first version of an application is usually built around the happy path.

The user completes every field correctly, the connection remains stable, the external provider responds on time, the payment is confirmed, the process finishes and the next screen appears as expected.

Under those conditions, many applications look finished.

Reality begins when someone presses the same button twice. They close the browser halfway through a process. They enter unexpected data. They lose their connection. They use an older phone. They return a week later. They pay, but one of the services involved in the next step fails.

None of these situations is particularly appealing in a demonstration, but all of them are part of the product.

A demo answers the question “can it work?”. A product must also answer others:

• What happens when something fails?
• Can it recover without losing information?
• Does the user understand what is happening?
• Can we identify the cause of the problem?
• Is it safe to run the operation again?
• Can the business afford to repeat it at scale?

The gap between prototype and product largely lives inside these questions.

A generation in Buklea

In Buklea, a family can create a personalised story with artificial intelligence. From the outside, the flow looks simple: the user provides some information, the system generates a story and the result appears ready to read.

That is the happy path. Behind it sits a much longer process.

The system must prepare the story, generate different scenes, preserve character consistency, process images, store results and build the reading formats. Some operations depend on external providers, cost money and can take several minutes.

What happens if nineteen pages are generated and the final one fails? Should we start again and pay for the entire process twice? What if the user closes the application while waiting? What if they refresh the page or press the button again because nothing appears to be happening?

Solving the happy path makes it possible to demonstrate the application. Solving these situations is what makes it responsible to charge for it.

The system needs to know the state of every job, preserve the results that are already valid, retry only what is necessary and prevent the same request from running twice. Users should be able to leave and find their story later without keeping a browser tab open.

None of this changes the central product idea. It does determine whether the experience creates confidence or frustration.

Failures stop being exceptions

In a prototype, an error can often be solved by refreshing the page or manually changing a record. In production, failures are a normal part of the system.

An API can return an incomplete response. A model can reject a generation. A task can exceed its time limit. A service can be available and then degrade a few minutes later. Even our own code can encounter a combination we never anticipated.

The goal is not to make sure nothing ever fails. That is unrealistic. The goal is to design how the product fails.

A production-ready system will often need:

• explicit states for long-running processes;
• limited and safe retries;
• idempotent operations that do not duplicate payments or jobs;
• preservation of partial results;
• understandable messages for the user;
• a recovery path when automation cannot continue.

These decisions are almost invisible when everything works. That is precisely why they are easy to postpone while building at speed.

Storing data is not the same as caring for it

Connecting a database is now relatively straightforward. Deciding what to store, for how long, who can access it and how to recover it requires much more judgement.

Once an application handles user information, responsibilities emerge that did not exist in the demo. Permissions need to be enforced, inputs validated, secrets protected, backups created and deletion requests considered.

In products that work with photographs of children, such as Buklea, these questions are particularly important. An image is not just a file needed to complete a generation. It is sensitive information that should be used for a clear purpose and kept only for as long as necessary.

AI can rapidly generate the code that uploads a photograph to a storage service. It cannot decide the right product policy on its own or bear the consequences of a poor decision.

Moving into production means no longer thinking only about what the system can do with data and deliberately restricting what it should do.

The economics must work at scale

A demo needs to complete the process once. A product needs to do it repeatedly with sustainable economics.

This distinction matters especially in generative AI applications. Every piece of text, image, audio or video can carry a variable cost. An architecture that looks inexpensive during testing may stop being viable when more users arrive, retries occur or each final result requires several discarded generations.

It is not enough to know the price of one model call. We need to understand the cost of the complete experience:

• how many operations a finished result requires;
• how many fail or are repeated;
• which resources can be reused;
• the cost of storing and serving the content;
• which parts can run on smaller models;
• the margin left after payments, taxes and support.

Optimisation does not always mean selecting the cheapest model. It can mean avoiding duplicate work, reusing valid results, reducing asset sizes or reserving the most capable models for the steps where they create real value.

If every new user creates a loss, gaining more users will not fix the product.

Without observability, every incident is a mystery

During development, we can watch the terminal, repeat an action and trace an error. Once the product is in other people's hands, that visibility disappears.

A message saying “my story wasn't generated” does not reveal which step failed, which provider was involved, how far the process progressed or whether trying again is safe.

Operating a product requires the ability to reconstruct what happened. This means recording relevant events, linking them to a specific operation, measuring timings and receiving alerts when behaviour moves outside the expected range.

Observability is not an extravagance reserved for enormous systems. It is what lets us answer basic questions:

• Is one user failing, or is everyone affected?
• Is the problem in our code or with a provider?
• How long has the process been stuck?
• Was the operation charged?
• Can we recover it without starting again?

Without these answers, the team is not operating the product. It is reacting blindly.

The interface must explain uncertainty too

Many prototypes are designed as though every action were immediate. The user presses a button and a result appears.

AI products do not always behave this way. Some processes take time, may degrade or produce results that need another review. The experience must represent that uncertainty.

A loading indicator alone is not enough. It helps to explain what is happening, allow the user to continue with something else, preserve progress and communicate clearly when their involvement is needed.

Empty states, errors, denied permissions, partial results and content that exceeds expected dimensions must also be designed. They are less visually appealing than the main screen, but they may have a greater effect on trust.

A good experience does not pretend the system is infallible. It makes its limitations understandable and recoverable.

Every feature creates an obligation

With AI tools, adding a feature is tempting because its implementation may appear to take only a few hours. The initial cost has fallen, but the responsibility remains.

Once released, that feature will need to:

• keep working when its dependencies change;
• coexist with new versions of the product;
• be explained in the interface and by support;
• be measured to determine whether it creates value;
• be protected against unexpected uses;
• be migrated or removed when it no longer makes sense.

Generated code also becomes part of the system. Someone will need to understand, review and modify it in the future. If every new piece follows a different pattern or solves the same problem in another way, the initial speed gradually turns into friction.

Maintainability does not require a prototype to begin with its final architecture. It does require us to recognise which parts are experimental and which are becoming product infrastructure.

What AI can do and what remains our responsibility

Coding agents can help in almost all these areas. They can write tests, review permissions, add logging, identify edge cases, prepare migrations and propose a more resilient architecture.

The mistake would be to conclude that because they can execute this work, we no longer need to direct it.

An agent does not automatically know the acceptable level of risk, the promise we have made to users, the cost the business can support or which data we consider particularly sensitive. Nor can it know which compromises we are willing to make in order to launch sooner.

The most important capability is not writing every line manually. It is setting good criteria:

• what must happen for an operation to be considered complete;
• which data we cannot afford to lose;
• which actions must be reversible;
• where human intervention is required;
• which failures we can tolerate and which should trigger an alert;
• what evidence we need before expanding usage.

AI accelerates the implementation of these decisions. It does not remove the need to make them.

A checklist for crossing the gap

Before considering an application ready to become a product, it is worth reviewing at least these questions:

1. Happy path: Does the core proposition solve a real problem, and is it clear? 2. Failures: What can fail at each step, and how does it recover? 3. Persistence: Can the user close the application and continue later? 4. Duplicates: Can repeating an action charge, send or generate twice? 5. Security: Can each person access only the data that belongs to them? 6. Privacy: Are we storing only what is necessary, and can we delete it properly? 7. Costs: Do we know the actual cost of a completed experience, including failures? 8. Observability: Can we reconstruct an incident without asking the user to repeat it? 9. Support: Is there an escape route when the system cannot solve the problem automatically? 10. Maintenance: Will we be able to understand and change this area in six months?

Not every answer has to be perfect before launch. A small product does not need the infrastructure of a large platform. But risks should be conscious decisions, not gaps we have yet to discover.

The hard part begins when the app works

Vibe coding is an extraordinary way to start. It reduces the cost of exploring an idea, allows us to learn by building and opens software development to many more people.

Its limitation is not the quality of the first demo. It is mistaking that demo for the end of the work.

A real product is not defined only by what it does when everything goes right. It is defined by how it protects data, responds when something fails, sustains its costs and enables the team to keep improving it after launch.

AI has dramatically reduced the cost of writing software. We can now reach the point where the engineering, product and operational decisions that create trust begin much sooner.

The app works. That is not the end. It is the moment the product begins.