Why a Vibe-Code Rescue Should Be Fixed-Scope, Not Hourly

Written By
SprintX Team
AI & Product Engineering
July 23, 2026
8 min read

The case for buying rescue work as fixed scope rather than hourly, what the contract needs to say, and the situations where hourly is genuinely the right call.
The standard offer for fixing someone else's codebase is an hourly rate and a shrug: nobody can estimate unfamiliar code, so you buy time and hope. It sounds like the honest position. On rescue work specifically, it is the worse deal for you, and often for the vendor too.
The reason is not moral. It is that rescue work has a property most software projects lack — the unknowns can be converted into a list before anyone commits.
Hourly is a bet you are not equipped to price
When you buy hours on a codebase you do not understand, from a team that has not read it, you are taking on all the estimation risk while holding none of the information. You cannot tell whether week three was slow because the problem was hard or because the approach was wrong. You cannot tell whether the work is 40 percent done or 80. And your only lever, once you are worried, is to ask for updates, which costs hours.
There is also a structural oddity nobody enjoys naming: under hourly billing, the vendor's revenue rises with their own inefficiency. Most people are honest and it still shapes behavior at the margins — the extra refactor, the tool evaluation, the long investigation nobody stopped.
What makes rescue work estimable
Feature development is genuinely hard to fix-price because the requirements move. Rescue work is different: the requirements are the same for every app of this type. Secrets rotated and moved server-side. Authorization enforced and verified from a second account. Constraints and migrations in place. Failure paths for every external call. A deployment you own with a rollback. Tests around auth and money. That list does not change based on what your product does — it is essentially the production readiness checklist, and it is the same list every time.
What varies is which items your app fails and how deep each hole is. That is exactly what an audit determines, in two to five days, for a small fixed price. Once the audit is done, the remaining uncertainty is ordinary engineering estimation on a known list — and any team that has done twenty of these can price it.
So the correct structure is two purchases, not one:
- A fixed-price audit. Small, bounded, delivers a report you own.
- A fixed-scope fix, quoted off the audit, itemized per finding.
You can stop between them. You can take the report to another vendor. You can do half the fixes yourself. Pricing for both stages is laid out in what an AI code audit costs and what a rescue costs overall.
How the models compare
| Hourly | Time and materials with a cap | Fixed scope | |
|---|---|---|---|
| Who carries estimate risk | You | Shared, badly | The vendor |
| Incentive on speed | Against you | Neutral | Aligned |
| Requires an audit first | No | Rarely | Yes |
| Scope changes | Invisible, just more hours | Absorbed until the cap, then a fight | Explicit change request |
| Ends when | You stop paying | The cap is hit | The list is done |
The cap deserves the middle column's scepticism. A cap without a defined deliverable means the vendor is incentivized to reach the cap and then negotiate about what "done" meant. You get the downside of hourly and the tension of fixed price at once.
What the agreement has to say
A fixed-scope agreement is only as good as its definitions. Insist on five things:
An itemized list of work, not an outcome adjective. "Rotate and relocate all credentials; implement and test row-level policies on the seven user-data tables; add webhook signature verification and idempotency" — not "make it production ready."
Acceptance criteria per item. How you will know it is done. For authorization that means a demonstrated test from a second account, not an assurance.
Explicit exclusions. New features, design changes, third-party accounts you have to buy, anything discovered outside the audited surface. Both sides need this in writing; it is what makes the fixed price safe to offer.
A change request path. Real projects find things. The agreement should say what happens when they do — a written change with its own price, approved before work, not absorbed silently or argued about at the end.
Deliverables and ownership. Repository, environments, credentials, documentation, and the report, in your accounts and your name at the end. Vendors doing this well will already have this in the template; the ones who do not are telling you something.
When hourly is the right answer
Not never. Three cases where it genuinely fits:
- Ongoing work after the rescue. Once the app is stable and you want continuous improvement, fixed scope becomes bureaucratic overhead for small changes. Move to a retainer or hourly then.
- True exploration. "Figure out why our costs tripled" is research. You cannot price a conclusion you have not reached.
- Very small jobs. A four-hour fix does not need a scoping exercise longer than the fix.
The pattern is that hourly suits open questions and continuous relationships; fixed scope suits a defined transformation with an end state. A rescue is the second thing.
The tell when you are shopping
Ask a prospective team to quote fixed scope after an audit. The answers sort them quickly. A team that says yes with an itemized list has done this repeatedly and knows their own numbers. A team that says "it depends, we would need to see" — before an audit — is being reasonable. A team that refuses fixed scope even after a paid audit is telling you they do not trust their own assessment, which is worth knowing before you hand them a budget.
More of that filter is in how to choose a team, and the trade-off between a solo contractor and a team is in contractor or agency.
Frequently asked questions
Will a fixed price be higher than what hourly would have cost? It includes a risk premium, so on a job that goes perfectly, yes, slightly. On the average job it is lower, because the vendor's margin now depends on efficiency rather than duration, and because you are not paying for the learning curve twice. What you are buying with the premium is a number you can plan around.
What if the vendor finds something serious mid-engagement? That is what the change request path is for. A serious finding gets written up with its own price and you decide. What should not happen is silent absorption — a vendor quietly eating a large discovery will cut corners somewhere you cannot see.
Can I fix-price the audit and then do the work myself? Yes, and plenty of technical founders do exactly that. A good report is ordered by severity with enough specificity to act on, which makes it a work plan. Just confirm before buying that the report is yours to use however you like.
If every quote you have is an hourly rate and a hopeful range, you are being asked to fund someone else's uncertainty. SprintX audits at a fixed price, then quotes the fixes as a fixed-scope list with acceptance criteria per item. Send us your repo or builder link.


