Bolt.new is genuinely impressive. Describe an app, and in an afternoon you have something that runs, clicks and demos beautifully. Then you try to put it in front of real users and it falls over, and you are left wondering whether you did something wrong. You did not. You hit the production gap, and it catches almost everyone, because the tool is brilliant at exactly the part of software that was never the hard part.
The production gap, mapped
Here is what Bolt.new hands you versus what a product actually needs. The middle column is the work between "it demos" and "it ships", and it is not optional.
Run the 30-minute production-gap audit yourself
Before you hire anyone or write a line of new code, you can grade your own Bolt.new app in about half an hour. Open the project and answer these honestly:
- Auth: log in as one user, then try to load another user's data by changing an ID in the URL or the request. If you can see it, authorization is missing, not just weak.
- Data: create something, then refresh and restart the server. If it vanishes, you are on mock or in-memory data, not a real database.
- Input: submit an empty form, a huge string, and an obviously wrong value. A blank screen or a crash means validation and error handling are not there yet.
- Secrets: search the front-end code for API keys. If they live in the client, treat them as already public.
- Deploy: ask how a code change reaches real users. If the honest answer is "copy the files across," there is no pipeline.
Every "no" is a line item in the production gap. Two or three of them is completely normal for a prototype, and that list is exactly the work that turns a demo into something you can charge money for. It also tells you whether you need a full rebuild of the spine or just a focused hardening pass, which is the difference between a few weeks and a few days.
What everyone gets wrong: "the AI wrote it, so it is basically done"
The demo running is not the finish line, it is the starting line dressed up as the finish line. When we open these projects, the pattern is almost always the same: the data is demo data the AI seeded and rendered on the front end, the code is one monolithic blob with no real separation between backend and front end, everything is client-side and unfit for an actual server deployment, and the components are loosely wired with routing that falls apart the moment you leave the happy path. The most expensive version of the mistake is shipping that prototype to real users with the demo auth still in place, then discovering any account can read every other account's data.
But the deeper thing the tool cannot give you is not code at all. Bolt.new, Cursor, Lovable and the rest write code; they do not tell you which features actually matter, how your users behave, what the trade-offs are, or what will happen to your business if you ship it a certain way. And code does not make a business successful. Strategy, the right features, customer orientation, a real launch plan, marketing and re-marketing, handling complaints, and smooth day-to-day operations do. Treat an AI build as a fast, high-quality first draft of the front end, and assume the thinking, the backend, the security and the data layer are still to be engineered.
What we keep, what we rebuild, and when to walk away
Being honest about this saves everyone money. When we inherit an AI-built app, we usually keep the front-end design and styling, it is client-approved, it looks good, and reusing it saves roughly 30 percent of the cost and time (it also tells us the founder is serious, which matters). We almost always rebuild the spine: the architecture, backend, auth and data layer. And we will tell you when it is not worth acting on at all. If your total budget is only one or two thousand dollars, productionizing an AI prototype into something real is not going to work out, and it is fairer to say so than to take the project and disappoint you.
This also frames where vibe-coding genuinely earns its place. It is excellent for design conceptualization and evaluation, getting an idea on screen fast so you can react to it. It is not a substitute for engineering, because it misses everything above. Use it for what it is brilliant at, and bring in real engineering for the part that keeps the app alive under real users.
Tell us what you have in mind. We turn AI prototypes and fresh ideas into shipped, scalable products, from India, for the US and UK.
The order of operations that actually ships it
Do this in sequence. Securing and stabilizing comes before new features, always, because building features on an unstable base is how you pay twice.
- Audit first. A short review of the code, data model and dependencies tells you what to keep and what to rebuild. Skip this and you polish things that should be thrown away.
- Rebuild the spine: real auth and permissions, a production database with a proper schema, validation and error handling.
- Security pass: lock down keys, add authorization checks and rate limits before anyone real logs in.
- Make integrations real, then test them with mock orders. Payments, email and any third-party system (POS, accounting, inventory) need real keys and failure handling, not the stubs the tool left. The near-miss that taught us this: integrations that "looked connected" but were never exercised end to end. Now we run internal mock orders before every launch to confirm the whole flow syncs, that every field lands in the right format in each system, and that bulk import and export behave. It is boring and it is the difference between a smooth launch and a public one that breaks.
- Tests, monitoring, deploy, and compliance: the pipeline that makes shipping updates routine instead of risky, plus the security protocols and the country-specific data, accessibility and legal rules your market requires before real users arrive.
This is exactly the work our AI development and app development teams do: take an AI-generated head start and engineer it into something that survives real users, usually keeping the front end and rebuilding everything under it. If your app is further along and simply misbehaving, start with why an AI-made app breaks and how to fix it, or, if you began from a design rather than code, converting an AI design into a scalable web app.
Frequently asked questions
Can a Bolt.new app go to production?
Yes, but not as-is. Bolt.new generates real, standard code (usually a React or Next.js front end with a light backend), so it is a genuine head start. What it does not give you is the production spine: hardened auth, a real data model, validation, security, tests, and a deploy pipeline. Add those and it ships.
Why does my Bolt.new app break when real users touch it?
Because it was generated to pass a demo, not to survive load, bad input and concurrent users. The happy path works; everything around it, error states, permissions, data that must persist and stay consistent, was never the tool's job. That gap is normal and fixable.
How much of the work is left after Bolt.new?
This is the counterintuitive part: the tool writes maybe 80 to 90 percent of the visible code, but that visible code is often only 40 percent of the work to a real product. The remaining "10 percent", security, data integrity, testing, scale and deployment, is where the real engineering time goes.
Should I rebuild a Bolt.new app or keep it?
Usually keep the front end and rebuild the spine. A clean Bolt.new UI is worth finishing; the backend, auth and data layer often need to be rebuilt properly rather than patched. A short audit tells you which parts are salvageable before you commit budget.
Is Bolt.new code secure?
Not by default. Common gaps are exposed keys, missing authorization checks (any logged-in user can read anyone's data), no rate limiting, and unvalidated input. None of this is a knock on the tool, it optimizes for a working demo. Any AI-generated app needs a security pass before real users or real data.
How long does it take to productionize a Bolt.new app?
For a clean prototype, hardening and shipping a solid MVP is often a few weeks. A tangled prototype with no real data model can take longer to untangle than to rebuild the core. The audit decides which situation you are in.
What exactly needs to be added?
Real authentication and authorization, a production database with a proper schema and migrations, input validation and error handling, real integrations (payments, email) with keys and failure handling, automated tests, monitoring, and a deployment pipeline. That list is the "production gap".
Can appico finish an app I started in Bolt.new?
Yes, this is core to what we do. We audit what exists, keep what is good (often the UI), build the real backend, security and data layer, add tests and a deploy pipeline, and ship it, with the code and accounts in your name. Finishing an AI-built app makes it more yours, not less.
“Disciplined, committed, over-delivers. Three years in, I would re-hire any day.”
“A factory of ideas.”
“A fantastic-looking and performing website.”
Talk to the team, we reply within 24 hours, and the first consultation is free.
Start a conversation →