Know whether it is worth recovering or rebuilding.

It is the most expensive question there is, because you can get it wrong in two directions. Rebuilding what could have been saved costs months. Saving what needed rebuilding costs years.

What really happens

What you get

The causes, not the symptoms — and the paths that stay open

The product's real state, why it got there, and the paths that stay open: discard and rebuild, keep the old alongside the new while serving users with a mix, or recover it piece by piece. Each comes with its own timeline, its own cost, and what it takes while the product keeps running.

The fastest path is not always the one worth taking. Which one it is depends on things we know about the code and things you know about the product: that's where the choice gets made, together, with the numbers on the table.

What it asks of you

Access to what exists, as it is

Even if it is in poor shape, undocumented, or the person who wrote it is no longer around. That is the normal case, not the exception.

What it is not

It is not a process that stops

The product continues serving customers while it is being assessed. Any plan that begins with ‘let's switch it off and see’ is not a plan.

Starters

The doors.

Build, Scale and Rescue are long commitments, and before taking them on it is normal to want a clear view.

Starters are a way to begin without committing: they take a few weeks, cost little, and end with something in hand that is useful even if you work with someone else afterwards. Three give you an answer before you start: a plan, a check, an audit. The fourth, the Dry Run, shows you how we work on a real piece of your project.

How we work from there

  1. Before

    You decide where capacity is spent

    Every activity is described, designed from a technical and interface point of view, estimated in terms of effort, then waits until you approve it. That way you see what will be built before time is spent building it. You are not approving an invoice: you are deciding where the time you have already bought goes.

  2. Every day

    You see the pipeline as it moves

    You have access to the tool where the work lives: its status, which two-week sprint it belongs to, whether it is ahead or behind. Not an end-of-month summary — the same view we use.

  3. During

    No one releases their own code

    The person who writes is not the person who approves. Every change passes through a second engineer before it goes anywhere.

  4. Before release

    An environment where you can test it

    The work arrives somewhere you can see it before production. If it is not what you expected, it goes back.

  5. Always

    The code and servers remain yours

    No technical constraint that forces you to stay.

The method, in detail