Know what it can handle, before you find out.

The product works for today's users. The question is what happens with the ones you are expecting, and the answer cannot be guessed.

What really happens

What you get

A map of the points that fail first

A performance analysis of the software and infrastructure, issues ranked by severity, improvement points, and an action plan with timelines and costs. Not a list of things to fix: a sequence, because the order is what makes the difference between spending well and spending a lot.

What it asks of you

Access to the code and infrastructure

And, where possible, time from the people who know it: many choices have a reason, and anyone who judges them without asking gets it wrong. When that person is gone — which happens often — we rebuild it from the code.

What it is not

It is not the prelude to a rewrite

The most common outcome is that some things need changing and many do not — and knowing which ones is what makes the difference between spending well and spending a lot.

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