Finishing a stalled Bolt app

A front end, fast, and a clean way out. Bolt.new builds React applications and runs them in the browser as you work, using StackBlitz's in-browser environment rather than a server. When you export, you get a standard project: open it, install the packages, run it, and it works on your machine the way it did in Bolt. Push to GitHub is built in.

For the back end, Bolt offers its own database or a connection to a Supabase project, which gives you a real database, login and server functions. Whether your app has any of that depends on how far the prompts got.

A server. Bolt's whole approach is to run the project in the browser, which is why it feels so fast and why the export is so clean. It also means the app has never run in production. There's no hosting, no domain, no environment variables set anywhere but the tool, no scheduled jobs, no logs.

The other gap is the back end itself. A Bolt app often has beautifully finished screens for features whose server side is a placeholder: the form that "submits", the payment that "processes", the report that shows sample data. The front end is the specification for a back end that still has to be built.

• The back end. Server functions that exist as stubs, or as calls to a database that has no rules.
• Database security rules. If Supabase is connected, the same finding as with any browser-facing database: without row-level security on every table, users can read each other's data.
• Environment variables and secrets. Keys in the front-end code, because that's where Bolt could reach them.
• Hosting and deployment. Nothing exists outside the tool.
• Integrations. The link to Stripe, Xero or the warehouse system was on the list and got as far as a button.
• Tests and staging. The app was tested by looking at it.

Finish the front end, build the back end. The screens are usually worth keeping as they are, and the export makes that straightforward. The back end is often built rather than fixed, because there's little to fix, and it's designed from the screens, which is a good order to do things in.

The general keep, finish or replace reasoning applies, and the assessment makes the call from the code.

1. Export to GitHub, into a repository in your organisation, and confirm it builds on a clean machine.
2. Read it. The assessment: which screens are wired to something real, which are wired to nothing, what the database looks like if there is one, and what the app expects to exist.
3. Give it a back end. A database you own with rules on every table. Server functions for the things the screens assume. Secrets out of the front end and into a store you control.
4. Give it a home. Hosting in your accounts, a domain, environment variables set properly, logs.
5. Foundations. Test and staging environments, integrity constraints, error handling, a backup that's been restored.
6. Finish the features, one at a time, each priced before you commit.

Often there isn't much yet, which makes a Bolt takeover simpler than most. Where there is, it never meets a change until the change has proven itself somewhere else: tested on a copy in a test environment, then run in staging with the data reconciled, before anything connects to live.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Bolt app it establishes which screens have a real back end and which don't, then prices building the rest as fixed numbers. What drives the price and the payment terms each have a page.

Keep the screens, build the system behind them. Marc Allington 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. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment.