Rescuing the Bolt app a whole business was running on

A real project, kept anonymous at the client's request. A business owner ran their whole operation on an app they had built in Bolt — the daily workflow, the records, the lot. It mostly worked, until it didn't. A feature would behave one way one day and differently the next, and every attempt to fix one thing broke another, because the platform pushed each change straight to the live app with nothing in between. There was no engineer to call. We audited the code and the way the business actually used it, got a dependable version live quickly so operations did not stop, then took the time to rebuild the parts underneath.

A business owner running their operation on a Bolt-built app

The client

A business owner running their operation on a Bolt-built app

Industry
Owner-operated business

Challenge

One app, no safety net, and the business depending on it

The app had been built conversationally, a prompt at a time, and it ran the business — so when a feature stopped doing what it was supposed to, the business felt it that morning. Fixing anything was worse than living with it: the platform committed every change straight to the live app, so a fix for one screen would quietly break another, and there was no version history to fall back to and no engineer to ask. The codebase underneath had grown the way generated code does, with a simple job spread across hundreds of lines nobody could safely touch.

A non-technical owner whose operation ran on this one app. Downtime was not an inconvenience, it was the business stopping. What they needed was not a lecture about architecture — it was the thing working reliably again, and a way to change it that did not put the whole operation at risk every time.

Solution

Stabilise first, keep the business running, then rebuild

We started by auditing two things together: the code, and how the business actually used it day to day — which screens mattered, which numbers had to be right, where a failure hurt most. Then we got a dependable version live quickly, so the operation kept running while the deeper work happened. Under it, the change process was rebuilt: version control, a place to test a change before it goes live, and a review step, so a fix can no longer take the whole app down on its way in. The sprawling generated code was rewritten into something a person can read and change safely.

With the business depending on the app, the order matters more than the elegance. Get it stable and dependable first so nothing stops, then spend the time to refactor properly rather than rushing a rewrite the owner would be stuck with.

Calls we would still defend

  • We audited the business, not only the code — mapping what the app had to do each day before changing any of it.

  • A dependable build went live quickly, so the operation kept running while the deeper rebuild happened underneath.

  • The push-straight-to-live problem ended — changes now go through version control, a test step and a review, so one fix cannot take the whole app down.

  • The generated sprawl was rewritten — the hundreds of lines doing a simple job became code that can be maintained.

Results

An app the business can run on, and safely change

Before

An app the business could not run without and could not safely change — every fix risked taking the whole thing down, with no version history and no engineer to call.

After

A stable build the operation runs on, changes that go through a safe path instead of straight to production, and a codebase that can actually be maintained.

FAQ

The questions this one raises

What was actually built, the constraints it had to meet, and what we would do differently.

  • Yes. It is a real client engagement, kept anonymous because the client asked us to — the business runs on this software and they would rather it not be named. What we can describe is the work: what we found, and what we did about it.

  • Usually, yes — and it is exactly this situation. The first priority is getting it dependable so your operation does not stop, and giving you a safe way to change it. The deeper rebuild comes after that, once nothing is on fire.

  • No. We stabilised what was there first so the business kept running, then rewrote the parts that could not be trusted. A from-scratch rebuild would have meant weeks with the operation stuck on something breaking.

Keep reading

Other builds, taken apart the same way

Want to talk about yours?