Bolt.new developer help · JavaScript, Bolt Cloud, Supabase, Netlify
Fix your broken Bolt app.
It runs in the preview, then breaks when you publish, or every "Attempt fix" makes it worse. A senior engineer finds what is actually wrong and fixes it, in code you own, keeping what works.
Photography is illustrative.
- Built in
- Your browser, on StackBlitz WebContainers: JavaScript and Node.js only
- Back end
- Bolt Cloud database, sign-in and server functions; Supabase as an option on Pro and Teams plans
- Hosting
- Bolt hosting on a bolt.host address by default; Netlify as an option
- Code
- Two-way GitHub sync, and ZIP download
Who this is for
For founders whose Bolt app works in the preview and stalls on the way to real users.
You built a real app in Bolt. The preview looks right and people can sign up. Then the published site stopped matching the preview, a fix attempt broke something else, payments half work, or someone asked whether your data is safe.
Bolt runs a complete development environment inside your browser, on StackBlitz's WebContainers, and builds in JavaScript with Node.js on the server. The database, sign-in and server functions come from Bolt Cloud or from Supabase, and the site is hosted by Bolt or on Netlify. All of that is ordinary JavaScript we write every day, so we can read your app as code, fix the cause, and leave it ready for you to keep building.
Failure modes
The ways Bolt apps break.
These are what we look for first in a Bolt app. Several come straight from Bolt's own documentation; none of them means starting over.
-
Database rules that let anyone read
- What you see
- Bolt's database check flags a rule like "anyone can read", or a user sees data that is not theirs.
- What is actually wrong
- The browser talks to the database directly, so access rules are what keep one user's rows from another. A rule written to get a feature working is often wider than it should be, and on Supabase a table without row-level security is readable with the public key the app ships.
- How we fix it
- We list every table the app can reach, write each rule against who should see the row, and prove it by signing in as one test user and trying to read another's data. Each rule gets a test.
-
"Attempt fix" loops
- What you see
- Each fix breaks something else, and tokens go on the same error.
- What is actually wrong
- Bolt's own guidance is to avoid clicking Attempt fix over and over, because each attempt costs tokens. The AI patches the symptom it can see, and with no automated tests nothing tells it what must keep working.
- How we fix it
- We go back to the last good version, pin down what works with tests, fix the cause in the code, and add checks so the next prompt cannot quietly undo it.
-
A restore that brings back the code but not the data
- What you see
- You restored an earlier version and the app now errors on data it used to read.
- What is actually wrong
- Restoring a version in Bolt does not change Bolt or Supabase databases. The code goes back in time; the tables do not, so the two no longer match.
- How we fix it
- Database changes captured as migrations in the repository, backups turned on, and a written procedure for rolling code and schema back together.
-
GitHub sync that overwrites work
- What you see
- A developer's commit disappeared, or the code in GitHub suddenly matches Bolt again.
- What is actually wrong
- Bolt checks GitHub for changes about every 30 seconds, and if both sides change at once it overwrites the GitHub version. Disconnecting the repository is permanent unless Bolt's support reconnects it.
- How we fix it
- One agreed place to edit at a time, developer work on branches merged by pull request, and branch protection on the main branch.
-
Publishing that fails, or a site that goes dark
- What you see
- Publishing stops with "could not find a build output directory", the custom domain points at nothing after a fork, or the public site vanishes until next month.
- What is actually wrong
- Bolt publishing fails above 100 MB or without a build output directory. Forking a project loses its Netlify connection, and reconnecting creates a new site the domain must be pointed at again. A site that reaches its plan's hosting limit stops showing publicly until the next billing cycle. And Netlify cannot host a database or a traditional back end.
- How we fix it
- A clean build configuration, hosting in an account you own with known limits, the back end in a home that can run it, and a deploy pipeline that tests before it publishes.
-
Two payment paths, half wired
- What you see
- Some purchases unlock access and some do not. Nobody is sure which Stripe code is live.
- What is actually wrong
- Bolt's native Stripe integration registers webhooks and verifies their signatures, but it needs server functions and sign-in, and on Supabase the changes must be applied before it works. Custom Stripe code written earlier cannot move onto the built-in integration, so many apps end up with both.
- How we fix it
- One payment path, subscription state stored on the server and used to decide access, and checkout, renewal, failed payment and cancellation each tested.
Before you hire anyone
What to try yourself first in Bolt.
- Roll back with version history, not prompts. Bolt's docs point out that rolling back through version history costs no tokens. Remember that it restores code only; your database stays as it is.
- Plan before it builds. Use Plan Mode, which makes no code changes, to have Bolt explain the problem and propose a fix. Then make one change at a time.
- Run the checks you already have. On paid plans, run the security audit from the Publish menu. On any plan, run the database check and fix any rule that lets anyone read.
- Keep a copy outside Bolt. Connect GitHub or download the project as a ZIP. While GitHub is connected, do not edit in GitHub and in Bolt at the same moment.
- Read the publish error. A failed publish usually says why: a missing build output directory, or a project over 100 MB. Fix that, rather than prompting around it.
- Rotate anything you pasted. A key you pasted into front-end code or the chat is readable by anyone: create a new one and revoke the old.
How we work
How we work on a Bolt app.
Bolt syncs with GitHub in both directions and overwrites the GitHub version when both sides change at once. So we agree with you who edits when: while we work, changes go through branches and pull requests, and you go back to prompting in Bolt once they are merged. You can download the project as a ZIP at any time.
Where the database lives decides what moving off Bolt would involve. A Supabase database is already in an account you can own. A Bolt Cloud database is managed by Bolt, and Bolt's documentation is not consistent about moving one to Supabase, so we check what your project allows before promising anything.
-
A free 20-minute call
You show us the Bolt app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.
-
Quick Security Check or App Readiness Review
A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.
You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.
-
Fixed-price fixes
Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.
-
Handover
Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.
Prices
Where to start, and what it costs.
-
App triage call
Free
20 minutes
-
Quick Security Check
$495
Delivered in 48 hours. The fee is credited toward the App Readiness Review.
-
App Readiness Review
$1,500 flat
5 business days. The fee is credited toward any fix booked within 30 days.
Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.
Proof
Who does the work.
A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Bolt partner or agency. Across the systems the team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Bolt questions, answered.
Can I keep building in Bolt after you fix it?
Yes. We work in the GitHub repository Bolt syncs with, and agree with you when each side edits so the sync does not overwrite anything. Automated checks then run on every change before production.
Can you move my app off Bolt hosting?
Yes. The front end can go to a host in your own account. Netlify cannot host a database or a traditional back end, so those need a home of their own, and we say which on the first call.
Is my data exposed?
Nobody can say without checking. Run Bolt's database check first. The Quick Security Check tests access from the outside, as a stranger and as another user, and tells you in writing what is exposed.
Will you rewrite everything?
Rarely. The screens, flows and much of the data model are usually worth keeping. The review marks each part keep, change or replace, with the reason, before any work is priced.
Are you affiliated with Bolt or StackBlitz?
No. Oracis is an independent US software engineering firm. We fix and finish apps built with Bolt, alongside apps from Lovable, Replit, v0 and other tools.
What does it cost to fix a Bolt app?
The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.
Send us the Bolt app.
The Bolt project link or the GitHub repository, what is going wrong, and when you need it live.