Sprint Studio / Capabilities / Rescue & rebuild

Inherited a codebase nobody wants to touch?

The original team's long gone, the last agency made it worse, and shipping anything new takes two weeks of staring. We triage the codebase, ship the next thing your business actually needs, and write you an honest note on what to do with the rest.

See how we work

Sound familiar?

If three or more of these are true, you have a rescue engagement on your hands — not a feature roadmap problem.

No-one currently working on it wrote any of it
The last deploy took half a day, and broke something
There are no tests, or there are tests, but nobody trusts them
A simple change is quoted in weeks, not days
Two engineers ago said “we should rewrite it” — nothing happened
The framework version is two majors behind. Or six.
There's a critical service nobody knows how to redeploy
The CMS / admin / dashboard breaks under load you used to handle

Audit. Ship. Tell the truth.

01

Two-week audit

One senior engineer in your repo for two weeks. Reads the code, runs the system end-to-end, talks to whoever's left. Comes back with a written triage: what's salvageable, what isn't, what the next-shipping unit-of-work is, what the cheapest path to stable looks like.

Week 0–2 · fixed-price · always sold separately

02

Ship the next thing

You pick the most valuable thing on the audit list — usually a feature your business has been waiting six months for — and we ship it. Through the existing codebase, not around it. That's how you find out whether the system is salvageable or whether the rebuild conversation is the real one.

Weeks 3–8 · fixed-price by sprint · feature lands live

03

Stabilise & document

Deploys green. CI useful again. The two scariest scripts on the box committed to the repo and documented. Observability wired in so you can tell when something breaks before a customer does.

In parallel with 02 · not a separate engagement

04

The honest note

At handover: a one-page note on what should happen next. Sometimes “keep going, it's fine” — sometimes “the rebuild is now the cheapest option, here's the shape of it.” We'll happily run the rebuild as a follow-on engagement — or hand you the note and let your in-house team do it.

Final week · written note · runbooks · optional follow-on

What we won't rescue.

We're a web studio. We rescue web codebases. There are some shapes of inherited project we'll politely decline so we don't do you a half-service:

  • Native iOS / Android apps (web view layers are fine; the native shell isn't our patch)
  • Desktop apps — Electron-only welcome, plain native isn't
  • Backend-only systems with no UI surface we're shipping into
  • Pure data-engineering or ML training pipelines (we ship the product around them)
  • Anything where the right answer is clearly “buy SaaS” — we'll tell you that for free

When in doubt, send us the repo URL. We'll tell you straight whether it's ours to fix.

Got a codebase to rescue?

See pricing