The demo works. The product doesn't.

There is a particular kind of call we take a lot now. Someone has built a product using an AI tool. It looks finished. It has a landing page, a signed-in area, a dashboard with charts on it. They have shown it to prospective customers and the prospective customers liked it. Then they tried to let one of those customers actually pay for it, and everything stopped.

This is not a story about AI tools being bad. They are extraordinarily good at the thing they are good at, which is producing a plausible interface faster than a human team can. The problem is that an interface is the visible tenth of a software product, and the invisible nine tenths do not get generated along with it. What the tool produced is a demo of the product. What the customer is asking to buy is the product.

What the demo is actually missing

When we audit a stalled AI build, the gaps cluster in the same three places nearly every time. None of them are visible from the screen. All of them are the difference between a thing you can show and a thing you can run.

Money

Taking a payment is not one feature. It is a small system with its own failure modes, and the demo version of it is usually a button that changes a value in a table. A real one has to survive a card being declined halfway through, a customer disputing a charge six weeks later, a subscription that needs prorating because someone upgraded mid-month, and tax rules that differ by where the buyer is sitting. It also has to be reconcilable, which means somebody has to be able to answer the question "did this person pay us, and how much, and for what" without reading application logs.

Identity

Generated auth tends to answer "is this person logged in" and stop there. Real products need to answer harder questions: which organisation does this person belong to, what may they see inside it, who may invite others, what happens when they leave, and how do we prove after the fact who did what. The moment a product has more than one user per customer account, permissions become the shape of the whole data model rather than a check you add at the top of a page.

Data integrity

This is the one that costs the most to fix late, because it is not a missing feature but a set of assumptions baked into every table. Prototypes are generated to make one happy path work, so they tend to store things in whatever shape was convenient for the screen that displayed them. Amounts as floating point numbers. Dates as free text. Statuses as strings a developer typed by hand in four places, spelled differently in two of them. Relationships implied rather than enforced, so nothing stops a record from pointing at a customer that no longer exists.

What we keep, and what we throw away

Founders arriving from a stalled AI build often expect to be told the whole thing is worthless and needs starting again. That is rarely what we find, and it is rarely what we recommend. The generated work has real value — it just is not evenly distributed.

• The interface and the flows are usually worth keeping. Someone has already made hundreds of small decisions about what appears where, and those decisions have been shown to real people and survived.
• The product definition is worth keeping, and it is the most valuable artefact of all. A working demo is a far better specification than a document.
• The data layer usually gets rebuilt. Not because it is bad work, but because it was written to satisfy a screen rather than to hold a business.
• Anything touching money, permissions, or third-party services gets rewritten. These are the parts where being almost right is the same as being wrong.

In practice this means the rebuild is far less frightening than it sounds. The front end is refactored rather than replaced. The schema is redesigned properly and the existing data migrated into it. The integrations get written once, with retries and idempotency, instead of being called optimistically and hoped over.

The half nobody budgets for

The features a founder lists when describing their product are the features customers will notice. The work that decides whether the product survives contact with those customers is almost entirely unlisted. Error states for every call that can fail. A refund path. An export, because someone will ask. A way for support to see what a specific user saw at a specific moment. Logging that answers questions rather than filling disks. Something that tells you the product is down before a customer does.

None of that demos well, which is exactly why generated builds skip it, and exactly why launches stall on it. When we scope a rescue, this work is a named line item with its own estimate, because pretending it is free is how projects end up six weeks past a date that was never real.

1. Audit what exists and separate the keepable from the rewritable.
2. Redesign the data model and migrate whatever real data there is.
3. Rebuild money and identity properly, with tests around both.
4. Add the operational layer: monitoring, support tooling, exports, error handling.
5. Launch behind a small number of real users before opening it wider.

The encouraging part is how short this list is compared with building from nothing. A stalled AI build is not a failure. It is a product with its cosmetic work already done and its structural work still ahead, which is an unusual and quite favourable place to start from — provided nobody keeps pretending the structural work has been done.