Our AI-built app has stalled

Someone in the business, often the owner, built more of an app than anyone expected. The screens look right. The demo went well. Then it met real data and real users, and progress stopped.

The tool didn't fail. It did what it's good at: getting a working-looking version in front of people quickly. What it doesn't do is the part that makes software safe to run a business on, and that part is where the prompts stop working and the developer who would have finished it isn't there.

We treat these the way we treat a VB6 system whose developer retired. Something exists, it does part of the job, and the business needs it to do all of it.

More than people expect.

• The screens and the flow. The tools are good at these, and they're the part your team has already reacted to. They're a specification, even if the code behind them is rewritten.
• The data model, mostly. Tables and fields reflect what the business tracks. They usually need tightening, but they're a head start.
• The rules you already discovered. Every place the app got something wrong and someone fixed it is a business rule written down in code. We keep those.
• The data itself. If real records went in, they come out, and they move to whatever comes next.
• The code, when it's exportable. Lovable, Replit, Cursor and Bolt produce ordinary React, Node or Python that can be moved to your own repository and hosting. That's the case we prefer.

The parts that don't show in a demo.

• Security. Login that anyone can bypass, API keys in the front end, no permissions between users, no rate limits. This is the most common and the most serious.
• Data integrity. No transactions, so a failure halfway through an order leaves half an order. No constraints, so the same customer exists four times.
• Error handling. It works when everything goes right. Real systems spend most of their effort on what happens when it doesn't.
• Multi-user behaviour. Two people editing the same record at once, one of them wins, nobody is told.
• Deployment, backups and monitoring. Often the app only runs inside the tool that built it, and nobody has tested restoring it.
• Integrations. The link to Sage, Xero or the warehouse system was on the list and never got past a stub.

If the app lives entirely inside a hosted builder like Bubble, add one more: you don't hold the code at all, and moving off the platform means rebuilding the parts that depend on it.

Usually finish, on open technology. When the code is exportable and the data model is sound, the fastest route is to move it into your own repository, put the missing foundations under it (security, integrity, tests, deployment) and then complete the features in order of value. The screens your team already knows stay.

Rebuild when the code can't be exported, when the security holes run through the whole structure, or when the data model would have to change so much that patching it costs more than replacing it. The general keep, modernise or replace reasoning applies here too. Even then the screens and the discovered rules carry across, so a rebuild starts with the specification already written.

The assessment makes that call from the code and the data, and puts a fixed price on each option.

The shape of the takeover depends on what the tool lets you keep, so each has its own page:

• Lovable: real code with GitHub sync; the backend often lives in Lovable Cloud.
• Replit: the code exports; the database, secrets and hosting stay behind.
• Bolt: a clean front end; the back end and the hosting usually don't exist yet.
• v0: good Next.js screens; no system behind them.
• Base44: hosted and closed; the data and the screens come out, the back end has to be rebuilt.
• Bubble: no code export at all; a rebuild with the workflows as the specification.
• Power Apps: readable Power Fx source that only runs on Microsoft's platform; fix in place or rebuild, decided on evidence.
• FlutterFlow: real Flutter code, exportable on the Pro plan; finish it in Flutter.
• Zoho Creator: the structure and Deluge scripts export, the data comes out as CSV; fix in place or rebuild.
• Zapier and Make: the automations became the system; build a system for the process, keep them for the edges.
• Cursor, Claude Code and Codex: the code is already yours and in a mainstream stack; what's missing is the engineering around it.

Whatever went into the stalled app comes out. It never meets a change until the change has proven itself somewhere else: built and tested against a copy in a test environment, then run in staging with the data migrated, checked and reconciled there. Only when the tests have shown it's safe does anything connect to live.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an AI-built app the assessment is mostly reading code and testing the parts a demo never exercises, and the report says what's sound, what isn't, and what finishing costs as a fixed price. Everything after that is priced by the report. Payment terms are on the pricing page.

Everything we build or finish runs on open, widely used technology: React, Node and TypeScript, .NET, PostgreSQL or SQL Server, mainstream cloud. It lives in your own accounts from day one, with full source code and ownership transferring to you on final payment. Any competent developer can pick it up, including the next AI tool, because there's a real codebase for it to work on.

We use AI-assisted development ourselves, from first design to final release, and our own platforms run the Claude API in production. The difference is the foundations underneath it.

Read the code before promising anything. Marc Allington leads the assessment and the work that follows. He builds with AI tooling daily and has taken over enough hand-written systems to tell quickly what a generated codebase has and hasn't got. Then the same method as any other takeover: understand, stabilise, finish one process at a time, with working software at the end of each stage.