Reliability
We hear about bugs from our users.
- The same bug returns after every AI fix
- Customers spot wrong payments or bookings first
- Someone checks records by hand to be sure
Rescue and modernize
Rescue a codebasethat cannot survive its first real users.
Software written fast to prove an idea is not the same artefact as software that carries traffic, money and other people’s data. The Vibe Code Rescue Sprint closes that gap on one agreed price, without a rewrite.
Every mark here links to the engagement it belongs to. See the work →
A Vibe Code Rescue Sprint turns a prototype, a stalled build or an inherited codebase into a tested, deployable foundation, in four to six weeks, priced to the outcome after a free initial audit. The work is triage first: what is unsafe, what is unknown, and what has to be true before the software can carry real traffic. The sprint suits a funded prototype approaching real users, a handover that failed, or a release process nobody trusts.
Choose thiswhen
- A funded prototype is nearing real users
- A handover failed or releases are unstable
- Security and dependencies are unknown
You get
Risk and dependency triage, tests, CI and a deployable build, and a prioritized handover document.
Pricing
Priced Outcome
One agreed price for an agreed outcome, quoted after a free initial audit and approved before delivery begins.
What the estimate depends on- The scope of the outcome you want
- The stage the application is at
- The condition of the existing codebase
- The team the work requires
- How the system is used in production
- The operational complexity around it
Work out what it has to return first: the ROI calculator for operational work, how we measure for everything else.
Why teams call
The five momentsthat make this urgent
One problem in five forms: the business depends on the app more than anyone trusts it.
Change risk
Every change might break something else.
- Simple changes take rounds of prompt-and-fix
- Stable features break after unrelated edits
- A growing list of code nobody will touch
Security
We cannot prove this is safe to trust.
- A security questionnaire from an enterprise prospect
- Requests for SSO, roles or audit history
- Credentials and access nobody has reviewed
Scale
We do not know where it breaks.
- Pages and reports slow as records grow
- Timeouts and API limits under real load
- Cloud and AI costs outrunning usage
Ownership
The app depends on one person.
- Key knowledge lives in one head or chat history
- No process for IT or a new hire to inherit
- The founder is the escalation path for everything
The answer
What we do about each one
Every moment above maps to work in the sprint. Nothing here is a separate purchase.
- Reliability
- Tests on the money, identity and data paths, and alerting on failures.
- Change risk
- Continuous integration, a repeatable deploy and a tested rollback.
- Security
- Dependency triage, secrets rotated behind a manager, access documented.
- Scale
- The breaking point found on purpose, and what it costs to move it.
- Ownership
- A deploy anyone can run, and a prioritized handover document.
Deliverables
What weactually deliver
Risk and dependency triage
Everything that could take the product down or leak data, ranked by likelihood and blast radius, written plainly enough for a non-technical founder to act on.
Tests around what matters
Not coverage for its own sake. The paths that carry money, identity and data get tests first, so the next change is safe to make.
A build that deploys itself
Continuous integration, a repeatable deployment and a way back. Releasing stops being an event.
A prioritized handover document
What was fixed, what was deliberately left, and the order to do the rest in - so the work continues whether or not we continue it.
Where it starts
The four places thisusually shows up
Operations
Work moves between people by hand, and every handoff can stall.
- The same record is typed into two systems
- A spreadsheet sits between two applications
- Volume grows, headcount is the only lever
Finance operations
Invoices and approvals depend on somebody remembering to check a folder.
- Month end is a week of copying
- Approvals live in an inbox rather than a system
- Nobody knows the cost per document
Customer support
The answers exist, in documents and past tickets, and finding them is the job.
- The same answer is rewritten daily
- Response time depends who picks it up
- The demo worked, production did not
Reporting and data
The number the business runs on is assembled by hand, twice, differently.
- A report is rebuilt weekly from exports
- Two dashboards disagree
- The data cannot be queried safely
Is this the right engagement for you?
Describe what is actually going wrong. We come back with the outcome, the engagement that fits and the price basis - after a free initial audit.
How we decide
A rescue is triage, not a rewrite.
The instinct with inherited code is to start again, because starting again is easier to estimate. It is also the option most likely to end with two half-finished systems and a business waiting on both.
- We stabilise what exists before proposing to replace any of it.
- The price is set after the audit has read the code, not before it.
- Anything we choose not to fix is written down, with the reason.
- If the honest answer is that a rewrite is cheaper, we say so in week one rather than billing six weeks to arrive there.
In practice
What fixing a build that cannot survive real userslooks like
Audit → rotation → secret manager → CI
Credentials in the repository
Keys committed during a fast build get rotated and moved, and the history is dealt with rather than ignored.
Schema capture → migrations → repeatable environments
The unversioned database
A schema that only exists in production becomes a migration history, so a second environment is possible at all.
Build → test → staging → production → rollback
The manual deploy
The ritual becomes a pipeline. The rollback path is the part that gets tested first.
Inventory → licence and maintenance check → replace or pin
The dependency nobody chose
Unmaintained packages are either replaced or pinned deliberately, and the decision is recorded.
Questions
About a build that cannot survive real users
It is not. The free initial audit reads the repository first, and the sprint price is quoted after that, for you to approve before anything starts. Fixing a price before looking is how a rescue turns into an open-ended bill.
Almost certainly not. A rescue sprint stabilises what exists. If we conclude a rewrite is genuinely the cheaper path we tell you in the first week, with the reasoning, rather than starting one quietly.
No, and it is most of what we see. Code generated quickly tends to be locally correct and globally inconsistent: the pieces work, the seams do not. That is a tractable problem and it is what the sprint is shaped around.
You have a tested, deployable build and a written list of what is left, in priority order. Some teams take it from there. Others move to Product Care or an engineering pod. Neither is assumed.
Not this one?
The otherengagements
Our roadmap needs a senior team behind it.AI-Native Engineering Pod3 months minimumPriced OutcomeThe AI demo has to work in production.AI Integration Sprint4-8 weeksPriced OutcomeManual work is eating our capacity.Agentic Workflow Automation8-12 weeksPriced OutcomeThe old system is too risky to change.Legacy Modernization2+ quartersPriced OutcomeNobody owns the product after launch.Product CareOngoingPriced Outcome
Before you commit
What you wouldbe signing up for
One bounded outcome
A named result, a fixed window and a scope agreed in writing before delivery starts.
- Commitment
- 4 to 12 weeks
- Price basis
- Priced Outcome
- The problem has an edge you can describe
- You want the cost known first
- Someone inside owns the result
A team against a roadmap
Senior capacity inside your codebase, moving a roadmap week after week.
- Commitment
- 3 months minimum
- Price basis
- Priced Outcome
- The work is continuous, not bounded
- Recruiting would cost a quarter
- You want the same people throughout
Ownership after launch
Monitoring, patching, upgrades and a named engineer for live software.
- Commitment
- Ongoing, cancellable
- Price basis
- Priced Outcome
- It is live and business-critical
- Nobody owns it out of hours
- The risk needs an owner
One agreed price for an agreed outcome, quoted after a free initial audit and approved before delivery begins.
Named quotes go here as clients approve them. See what the engagements produced →
Next step
Have something that works until somebody touches it?
Send us the repository and tell us what you are afraid of. We will tell you what it would take to make it safe to change, and whether six weeks is the right number.