When to Stop Prompting Bolt and Start Hiring

There is a moment in every Bolt project where the tool stops feeling like a rocket and starts feeling like quicksand. The same prompt that built half your app in an afternoon now takes eight attempts to rename a button. A bug gets fixed, another appears in a file you never asked it to touch. You blame yourself, then you blame Bolt, then you refresh the window and hope the next session goes better. It usually does not.

The reason is not that Bolt got dumber. Bolt is the same today as it was the week you started. What changed is your project. It crossed a complexity threshold that no in-browser AI IDE can service, and every additional prompt is now spending tokens to dig the hole deeper. The mature move at this point is not a better prompt. It is a handoff.

This is a guide to recognising the threshold. Five signals that your project has outgrown the tool, and what to do at each one, including the cleanups to run before you hire and the brief to hand the developer when you do. Bolt is extraordinary for the first seventy percent. The article is about the last thirty, and why trying to do it in the same place you did the first seventy is the most expensive mistake a non-technical founder can make.

Signal One: You Are Rewriting the Same File for the Fourth Time

The first signal is the most telling, and almost nobody names it. Look at the file Bolt has been touching this week. If it is the same file it was touching last week, and the one before that, and you can remember at least three distinct moments where Bolt said something like "I've rewritten this cleanly now, this should resolve the issue" and then introduced a new bug, you are in what engineers call a local minimum. The model cannot escape it, because escaping would require refactoring the surrounding code, and the surrounding code is too large to fit in the prompt alongside the file being edited.

What is happening underneath is a token economics problem. Every time Bolt rewrites a 400-line file from scratch, it reads the file, decides on a strategy, and writes the replacement. Do that four times and you have spent close to five thousand tokens on pure regression cost. Not features, not even bug fixes that held. Just iteration on a problem the model has already failed to solve three times, with no new information in its context on attempt four that was not there on attempt one.

The heuristic is blunt. Count rewrites per file per week. One is healthy. Two is the tool working. Three is the tool struggling. Four is the tool stuck. At four, the right action is to stop, export the project, and find a human who can hold the whole file in their head and see why the fix keeps failing. A developer with a working LSP and fifteen minutes of focused attention will usually identify the coupling that pulls the model back into the same local minimum. Bolt cannot see the coupling.

Signal Two: You Cannot Isolate a Bug

The second signal is the minimal reproduction test. This is a question professional developers ask themselves ten times a day, and the answer is usually the whole debugging strategy. The question is: can I reproduce this bug in isolation? If yes, the fix is usually a single commit away. If no, the codebase is telling you it is too tangled to debug surgically.

Run the test on your project. Pick a bug you have been chasing. Not the gnarliest one, a middling one. Then try to describe it in the form "when I do X on page Y, Z happens instead of W." If you can write that sentence and the bug stays reproducible when you try the exact steps in a fresh browser, your codebase is healthy enough. If you find yourself writing things like "sometimes after I log in, if I refresh twice, the dashboard shows old data, but only on the Safari preview, and only if I edited something in the last session," you are looking at a symptom of deep coupling. State is leaking across components that should not share it. Data fetching is happening in places that should be pure. Routing is intertwined with authentication in ways nobody planned.

Bolt cannot fix this class of bug, and neither can any in-browser AI. The fix requires standing the code up in a proper local environment, running it under a debugger, stepping through the render lifecycle, and often pulling half the code apart to see where the state is hiding. None of that is possible inside a preview tab. When a project fails the minimal-repro test, the cost of every subsequent feature goes up, because every feature lands on top of a foundation the model cannot reason about cleanly. The sooner you hand off, the smaller the cleanup.

Signal Three: Tests Do Not Exist, and Nobody Noticed

The third signal is one almost no vibe coder thinks about until it is far too late, because the tool never surfaces it. Open your project and search for a test file. Something ending in .test.ts, .spec.js, .test.tsx, anything. If you find zero tests, or you find a handful of autogenerated renders-without-crashing tests that were written at the start and never updated, your project has the test coverage problem.

This matters because of what tests do for a codebase the author cannot hold in their head. Tests are the contract that says "this behaviour must not break." Without them, every new feature is a coin flip on whether old features still work, and the only way to find out is to click through every page manually and hope you remember all the edge cases from three weeks ago. You will not remember. Neither will Bolt, because Bolt has never seen most of those pages in a single context window.

AI coding tools, including Bolt, systematically underproduce tests. The reason is structural: writing a meaningful test requires understanding the intent of the code, which requires conversation history the model does not have access to in a fresh session. So the model writes tests that verify the code does what the code does, which is useless. A project past roughly fifteen hundred lines of code without real tests is, for practical purposes, a write-only codebase. You can add to it. You cannot safely change any of it. Every edit is a bet.

When you notice this signal, the response is not to ask Bolt to write tests retroactively. It will, and they will be shallow, and you will now have the false confidence of a green test suite on top of a still-unverified codebase. The response is to bring in a developer who can add tests at the seams that matter, which requires understanding the product, which requires a conversation you cannot have with a model.

Signal Four: The Deploy Loop Is Eating Your Week

The fourth signal lives in your deployment history. If you can scroll back through the last seven days of deploy attempts and count more than five, with each "fix" introducing a fresh failure, you are in the deploy loop. This happens because the preview environment inside Bolt is not the same environment as your production host. Env vars differ. The build command behaves differently. A dependency version that worked in preview is missing a peer in production. CORS rules that localhost ignores come alive on your real domain. Cookies set with sameSite defaults that work on the preview iframe break on the live site.

Bolt cannot debug production, because Bolt cannot see production. It sees the error message you paste into chat and guesses at a fix based on the shape of the message. That guess is often right for small, local issues and is almost always wrong for environment-specific ones. You end up in a cycle where Bolt proposes a change, you deploy, a new error appears, you paste it, Bolt proposes another change, and the logic between attempts degrades each time because each attempt has added more code to reason around.

A working developer fixes deploy issues by reading the build logs, reproducing locally with the same node version and env setup, and often stepping through the deploy pipeline with the host's CLI. None of this is possible inside a Bolt session. If you have spent three days on a deploy, the cheapest path forward is a two-hour engagement with someone who has deployed a hundred apps to the same host. They will usually find the problem before you finish explaining it.

Signal Five: Tokens Are Burning and Nothing Is Shipping

The fifth signal is financial, and it is the cleanest of the five. Check your Bolt billing. If you have spent more than the cost of a day of contract developer time in the last month, and the app today is not meaningfully better than the app a month ago, the tool has stopped paying for itself. The math is simple. A good last-mile developer charges somewhere between three and eight hundred dollars for a focused day of work. If your token spend over four weeks is climbing past that number and you cannot point to five concrete things that shipped, you are funding a treadmill.

This is not Bolt's fault. It is the nature of a pay-per-token tool working on a codebase that has exceeded its effective context. Every prompt reads more of the codebase than the last, every rewrite costs more than the last, and the value per token declines steadily as the project grows. At a certain project size, you are paying retail rates for the model to re-learn the codebase every session, then failing to edit it productively. A human picks up the codebase once, holds it, and amortises that investment across weeks of work.

The trigger to hire, financially, is when your weekly token spend has plateaued or risen while your weekly shipped-feature count has dropped. You do not need precise metrics. You need honesty about the trend. Most founders feel this trend for three or four weeks before they act on it, and every one of those weeks is money that would have been better spent on a developer.

Before You Hire, Do These Three Cleanups

Handing a tangled Bolt project to a developer without preparation is the expensive way to hire. The developer will spend their first day, at your rate, doing work you could have done in an hour. The following three cleanups will save you more than they cost you, and you can do all of them without writing a line of code.

First, export and freeze. Pull the project out of Bolt through the GitHub integration, or download the zip and commit it to a fresh repository. The goal is a stable baseline nobody is editing while you prepare the handoff. Keep prompting Bolt after you have decided to hire and you hand the developer a moving target.

Second, write a one-page document titled "what works and what does not." List every page of your app. Next to each, write one line on whether it loads, what a user can do on it, and what breaks. Add a section for errors you have seen, including the exact text and the page you saw them on. This is unglamorous work and it is worth several hours of a developer's discovery time, because you have context no developer can reconstruct from reading the code. Write it yourself. It will also force you to notice which parts of the app you have not actually tested in a while, which is itself useful.

Third, collect the credentials. Hosting account login, backend service (Supabase, Firebase, whatever you picked), domain registrar with DNS access, any third-party API keys. Put them in a password manager you can share. A developer who starts work at nine in the morning and has to wait until two in the afternoon for a Stripe test key has billed you for five hours of nothing.

How to Brief a Developer for a Bolt Graduation

The brief is short on purpose. A developer who knows what they are doing needs less from you than you think, but what they need, they need precisely. Six pieces, each one or two sentences.

Product in a sentence. The user and what they do. The current state, with a link to the repository and the live preview if one exists. The specific outcome you are paying for, stated as something a reasonable person could check at the end of the engagement. The budget and the deadline. What you will provide, which is usually credentials, product decisions on the ambiguous bits, and your availability for questions.

Notice what is not in the brief. There is no list of technical tasks. A developer worth hiring will produce that list themselves after looking at the code; if you produce it, you will either under-specify and miss the real problems or over-specify and prevent them from making the right call. Hire for outcomes, not tasks. The outcome is almost always the same: a working version of the app you already have, shipped to production, on a foundation someone can safely add features to for the next year.

Where WitsCode Comes In

This is the part of the Bolt lifecycle WitsCode was built for. We are the last-mile developers for vibe coders: the engineers who take an exported Bolt project at signal three or four or five, run the cleanups, stabilise the deploy, add the tests that should have been there, and hand you back something a future team can keep building. We do not rewrite your app. We finish it.

If you recognised three or more of the signals above, the next step is a thirty-minute codebase review with one of our engineers. Send us the repository link and your what-works-and-what-does-not document. We come back with a priced proposal for what it takes to get your project to production. No retainer, no rebuild talk. The point is to get you out of the spiral, not into a new one.

The best moment to stop prompting Bolt is the moment you first suspected it. Most founders wait another month, and that month is the expensive one.