Rebuild · Bolt.new

Bolt.new in production: patch or rebuild?

Bolt.new is one of the fastest routes ever built from idea to working app, and if you’re here, yours worked: real users, real data, maybe real invoices. This page covers what tends to strain when a Bolt app carries production weight, who actually owns your database, and a ten-question self-assessment that answers honestly whether you need a patch or a rebuild.

Run the ten questions → Or start with 20 minutes →
bolt.new app · productionadmin access · not yours
generated frontend business logic · in the browser supabase project hundreds of client quotes you bolt your credentials end here
the app runs · the data flowseverything looks owned
Sound familiar?

Their words, not mine.

If your version sounds like any of these:

  • You can’t see or administer the Supabase project your production data lives in.
  • Builds fail with sandbox memory errors once the codebase passed a certain size, and every retry costs tokens.
  • Fix loops: the same bug eats millions of tokens without converging.
  • The app is live and selling, and you’ve realised nobody on your side can answer where the keys and credentials actually sit.
  • You want to move off the platform and can’t find a straight answer on what that involves.

“Urgent production issue — need help recovering database access. My production app is partially broken because I can’t access my original Bolt-managed Supabase project. The original production database, created by Bolt, contains hundreds of real client quotes and customer data. Already sent an email to support but no response yet. This is affecting my sales team daily.”

— Oscar Del Real, Bolt community Discord, June 3, 2026

“I’m now consistently getting sandbox memory errors when Bolt tries to run the build process. The error message shows: ‘The build process was killed (OOM in sandbox).’ Because of this, I have wasted a significant number of tokens trying to complete basic development tasks that should normally work.”

— Timmy, Bolt community Discord, May 29, 2026

“I keep sending optimized prompts, smaller prompts, and everything as manual, but it keeps saying OVER AND OVER that the agent stopped working. I wasted over 25 million credits, and since I’m on a tight budget, it’s getting so frustrating.”

— Gabriele, Bolt community Discord, June 12, 2026
Why this happens

Two structural facts explain most of it.

Neither is a bug in your app, and neither is something a better prompt fixes. Both are consequences of how Bolt.new is built to work.

01

The ownership trap

When Bolt provisions your backend, it can create the Supabase project inside Bolt’s own organisation rather than yours. The app runs, the data flows, and everything looks owned, until the day you need direct access to your own production database and discover the original project was never actually yours. That’s the exact situation in the June 2026 support thread quoted above: a live business locked out of its own customer data, waiting on platform support. Recovering access is possible; depending on it is the problem.

02

The browser does too much

Bolt’s speed comes from generating apps that run and demo instantly, which pushes logic toward the client. Security reviews of Bolt-generated apps in 2025–2026 (VibeAppScanner’s Bolt analysis among them) document the recurring pattern: API keys and third-party credentials sitting in frontend bundles, and data transformations, validation rules and access-control checks living in browser code where any user can read and bypass them. This is a pattern finding across many apps, not one incident, and it’s consistent with the wider measurement that only about 55% of AI-generated code passes security checks (Veracode Spring 2026 GenAI report).

+

The operational ceiling

The in-browser build sandbox has finite memory, so past a certain project size, builds start dying with out-of-memory errors and each retry burns tokens. That’s not a bug you prompt your way out of; it’s the platform’s shape.

None of this makes Bolt a bad tool. It makes it a prototyping tool being asked to be a production platform. The question is whether your app has crossed that line, which is what the assessment below is for.

The evidence on exposed keys and backends, with sources →
Patch or rebuild

Ten questions. An honest answer.

Not every Bolt app in trouble needs a rebuild, and this assessment will tell you if yours doesn't. No email required; the result shows immediately.

01 Where does your traffic come from?

Bolt picked one datacentre for your Supabase project when it set the backend up, and every request travels there and back. If your customers are all in one country that trip is short; if half of them are on the other side of an ocean, they wait for it on every page.

Global users on a single-region backend means latency you can't prompt away.

02 How big are the pieces of data you handle?

This is about the size of one thing a user hands your app. A booking, a name and an address, a line of an invoice is a small record. A product photo, a PDF contract or a video is a large file, and Bolt-generated code often pushes those through the same path as the small stuff instead of into file storage.

Large files pushed through the app path instead of object storage is fixable in place.

03 Does your data need to be queried later, or used once and dropped?

Some data you have to be able to look up again: customer quotes you search by name, orders you show on a history page. Other data you only need once and then never again, like a webhook payload or a log line Bolt wrote into a table because a table was the easy place to put it.

One-shot data doesn't belong in your tables; that's a cleanup, not a rebuild.

04 Is your app read-heavy or write-heavy?

Count what your app does most: showing people data that already exists, or saving new data they type in. A catalogue, a dashboard or a portfolio is mostly reads. A booking system taking orders all day, or anything writing a row every few seconds, is write-heavy.

Read-heavy apps often just need caching and query work.

05 What genuinely needs to be real-time?

Real-time means the screen changes by itself, without anyone reloading: a live chat, a seat map two people are booking from at the same time, a delivery moving on a map. If your users would be perfectly happy pressing refresh, nothing here is genuinely real-time.

Real-time at scale is an architecture decision.

06 Is the wall a hard platform limit, or the shape of your queries?

A hard limit is a wall the platform puts there: Bolt builds your app inside a browser sandbox with a fixed amount of memory, so once the codebase grows past a certain size the build dies with an out-of-memory error no matter how you word the prompt. The other kind of wall is your own code being slow or asking the database for too much at once, and that one moves once someone measures it.

The central question. The OOM sandbox ceiling is a hard limit; slow queries usually aren't.

07 Where does your business logic live?

Business logic is the part that decides things: what a customer gets charged, who is allowed to see which record, when an order counts as paid. If those rules were generated into the app that runs in your visitor's browser, they arrive on the visitor's machine and can be read and changed there. In a backend, the rules run on a server your users never touch.

Bolt tends to put logic where it's easiest to demonstrate: the browser. Client-side business logic means the rebuild scope is the logic, not just the data.

08 Is this internal glue or your product's backbone?

Ask what happens on the morning this Bolt app is down. If a few colleagues shrug and do the task by hand, it's internal glue. If customers can't buy, book or log in and your revenue stops with it, it's the backbone, and the same weaknesses cost a great deal more.

Backbone plus client-side access control is a risk you're carrying today, not someday.

09 What's your compliance surface?

Compliance surface means how much trouble a leak would bring with it, on top of the leak. Names, emails and addresses fall under GDPR; card details, patient notes and ID numbers carry their own rules. Regulators expect you to be able to show who can reach that data, which is hard to answer while the Supabase project holding it sits in Bolt's organisation rather than yours.

Regulated data behind keys you don't fully control is a conversation with your lawyer, not just your developer.

10 Who owns verification?

Verification is whatever catches a mistake before your customers do: automated tests that run on every change, and monitoring that tells you when something breaks in production. The question is whether anything stands between what Bolt regenerates and what your users get, other than you clicking through the app and hoping you touch the broken part.

Without a verification layer, every regeneration can silently reopen what you fixed.

How to read your answers

Question 6 weighs heaviest: query-shape answers pull toward patch, hard-limit answers pull toward rebuild. Questions 7 and 9 amplify: logic in the client layer or regulated data both raise what a wall costs you. For Bolt specifically, add the ownership question from the mechanism section above: if you can't administer your own Supabase project today, fix that this week regardless of everything else.

The rebuild

Keep what you proved. Own what you ship.

01

What stays

The product and the experience your users validated. That’s the spec.

02

What changes

Ownership and structure. Your data moves into infrastructure registered to you, with your credentials. Business logic comes out of the browser and into a server you control, behind real access checks. Builds run in CI with tests, not in a sandbox with a memory ceiling. Keys live in secret management, not in bundles.

03

What comes back is more than what broke

The rebuild spans product, business, design and tech in one head, so alongside the new foundation you get sharpened positioning and a senior design pass. The results show up in your numbers: support tickets down, checkout and load paths faster where customers feel it, features shipping in days again, and a system an acquirer or first engineering hire can walk into. A rebuild restores value. This compounds it.

How the work runs → The engagement and pricing →
Who's behind this

Henrik Hallengren — 20+ years across product, tech, strategy and design; brands from Google to Mondelēz, worked with across roles and projects; production systems like the multi-tenant AI platform autoply built solo and running today. Independent: no platform ties, no referral fees.

The systems →About Henrik →
Next step

Start with the diagnosis.

Diagnosis: €7,500, fixed. One week. A written architecture and code review of your Bolt app: who owns what, what’s exposed, what’s salvageable, what a rebuild costs. Useful even if you stop there.

Book a 20-minute call

Guides for Bolt