Close the four holes Bolt leaves open, then ship it properly
Bolt gets a full-stack app running in an afternoon and it is genuinely good at that. The gap between "runs in the Bolt preview" and "runs in production for paying users" is remarkably consistent across projects, which is convenient: it means the work is known before we start.
- Typical timeline
- 2–4 weeks for a typical app
- Pricing
- Fixed quote after a free Production Check
- Rollback
- Written, rehearsed, and executed by you before handover
What staying on Bolt.new actually costs
Not a list of features you are missing. These are the four things that reliably turn into an incident, an invoice, or a lost deal.
- 01
Authorization was never on the server
Bolt writes a convincing login flow: a form, a session, a user object, and routes that redirect when it is missing.
- 02
The same four findings, almost every time
Service-role key compiled into the client bundle. Tables where row-level security was never enabled.
- 03
Local state is not persistence
Where a database was not wired up, Bolt reaches for localStorage and in-memory arrays.
- 04
Long sessions leave sediment
Past about twenty components the model loses the thread: duplicate utilities, two competing fetch patterns, business rules implemented twice with different edge cases.
The sentences we hear most, and what we do about each one
These are paraphrases of things founders have actually said on scoping calls. The left column is the experience; the right column is the work.
"I already spent a fortune on tokens trying to fix this"
The failure mode is specific and expensive: a bug the model cannot fix, re-prompted twenty times, each attempt rewriting adjacent working code.
How we helpWe diagnose first and tell you which problems are prompt-shaped and which are architecture-shaped.
"It works perfectly when I test it"
Because you are always logged in as yourself, on your own account, with your own data.
How we helpWe test the way an attacker does: a second account, an anonymous session, and a terminal.
"I need this for a customer next month and I do not know what is missing"
The pressure is real and the unknown is the worst part.
How we helpThe Production Check is free and takes three to five business days. It ends with a ranked list and effort estimates, so "am I two days or two months away" becomes a number. Plenty of clients read it and do the work themselves.
"I want to keep building in Bolt"
Founders assume hardening means abandoning the tool that made them fast, and that trade-off is genuinely unattractive.
How we helpIn most cases you keep it. We harden the server side, put the app in git with a pipeline, and set the boundary of what is safe to regenerate.
Component by component, before and after
Every line is a decision we will walk you through, and every one of them is written down in the handover documentation.
| Today | becomes | After the migration | Why it matters |
|---|---|---|---|
| Client-side route guards | Server-side authorization on every endpoint | Checked against the record being touched, not just against the presence of a session. | |
| Service-role key in the bundle | Privileged calls server-side, key rotated and revoked | Rotation is sequenced so the running app does not break during the change. | |
| Tables with row-level security off | Policies per table, covered by cross-tenant tests | Postgres denies by default, so the dangerous state is RLS off, not RLS on with no policy. | |
| Unescaped user input rendered as HTML | Escaped output, with an allowlist sanitiser where rich text is genuinely needed | Plus a content security policy so a missed case is not automatically exploitable. | |
| Unthrottled login and signup routes | Rate limiting, lockout, and verified email | Credential stuffing against an unthrottled login is entirely automated and very cheap to run. | |
| localStorage and in-memory arrays | PostgreSQL with migrations and backups | The schema is designed from the shapes the UI already uses. | |
| Deploy by export | Git, CI, preview environments, rollback | The app stops living in one browser tab. |
Four phases, each with something you can hold
Scope is fixed after phase one. Every phase ends in artefacts you keep, whether or not you continue to the next.
- 013–5 days
Production Check
Free, and first. We reproduce each finding as an actual request so the severity is demonstrated rather than asserted, and rank the results by what they cost you.
You receive
- Reproducible proof for each critical finding
- Secret scan across the bundle and git history
- Ranked remediation plan with effort estimates
- Live walkthrough of the findings
- 025–8 days
Close the criticals
Authorization moves to the server, policies are written and tested, exposed keys are rotated, output is escaped, and the auth routes get rate limits.
You receive
- Server-side authorization with tests
- Row-level security per table, cross-tenant tests passing
- All exposed credentials rotated and revoked
- Rate limiting and email verification on auth routes
- 035–10 days
Give it a real backend
Client-side state becomes tables with migrations and backups. The duplicated logic that long sessions left behind is consolidated where it actually costs you, and left alone where it does not.
You receive
- Schema, migrations, seeds, and verified backups
- Consolidated data access and validation
- Tests around the invariants that matter
- 043–5 days, plus 30 days support
Ship and instrument
Deployment to infrastructure sized for your traffic, with a pipeline, monitoring, and a documented boundary for what is still safe to regenerate in Bolt.
You receive
- CI/CD with preview environments and rollback
- Error tracking, uptime monitoring, structured logs
- Written boundary: what to keep building in Bolt, what not to
- 30 days of post-launch support
What can go wrong, and what stops it
We would rather write these down than discover them together. Each one is a real failure mode from a real migration, with the control that prevents it.
Regeneration reintroducing a closed finding
The security-critical paths move out of the regenerated surface, and the cross-tenant test suite runs in CI.
Key rotation breaking a running integration
New credential issued and deployed first, verified, then the old one revoked.
Adding rate limits and locking out real users
Limits are set from observed traffic, not from a default, and the first week runs in log-only mode so we can see what would have been blocked before anything is.
Before you book the call
Almost all of it. This is hardening and wiring, not a rewrite.
Not definitely, and we will tell you if it is clean - that is a real and reportable result.
Usually yes, with a documented boundary. You keep iterating on the interface; the paths carrying authorization and money stop being regenerated casually.
Related migrations
v0 → production
v0 produces genuinely excellent React - clean components, sensible Tailwind, real accessibility primitives. It does not produce a backend, and most v0 projects reach us as a finished interface wired to mock data.
Read the planLovable → your own cloud
Lovable produces a real React application against a real Postgres database, which makes this the most tractable migration on this page.
Read the planReplit → DigitalOcean
Not every app needs AWS. If you want your own infrastructure without acquiring an ops habit, DigitalOcean gives you managed Postgres, container hosting, object storage, and a bill you can read - three moving parts instead of thirty.
Read the plan
Thinking about moving off Bolt.new?
The scoping call is free, and it ends with a straight answer about whether it is worth doing yet.