This part is animated. Your browser can't show the animation, so here's the still.
How we build for the heat
Every project we take on goes through the same six stages, new build or rescue. On a rescue the first three move faster, because something is already on fire and the first job is to stop it spreading. The order doesn't change.
Scroll to move the bar through all six
Most software that fails under load was never tested under load. Usually there was a plan. Somewhere along the way, someone skipped the part where you find out what the system will face and build it to survive that. These stages are that part.
Stage 1: Find where the heat will be
reading the fire before the metal goes in
We work out what the system will really carry and where it is most likely to give. That means peak traffic and when it comes, how much data piles up and how fast, every service it depends on, who uses it and what they do most, and what it costs the business for each hour it is down. On a rescue we start from the evidence: the logs, the code, the infrastructure and the last few things that changed.
What you get
A short list of risks in plain language. For each one: what could fail, how likely it is, what it would cost you and what we propose to do about it.
When this is skipped
The heat turns up in production instead, usually on launch day or during the first big campaign. Whoever is on call makes the fix under pressure, and it tends to stay in the code long after the night it was written.
Stage 2: Decide the shape
the shape is set before the first blow
We choose the architecture for the load we found in the first stage. We decide what gets built, what gets bought and what stays, how data moves between the parts, how code reaches production and how each change can be undone. Then we order the work so the risky pieces go first, while there is still time to change course.
When a live platform has to change underneath its users, this is where the route is drawn. On one CRM and loyalty rebuild, a bridge version ran the old core and the new services side by side, so brands could move across in waves.
What you get
The architecture on one page, a written plan, the order of work and a way back for every step that touches something live.
When this is skipped
Teams pick a structure that suits the first few customers and find its limits at the hundredth. A codebase that grows with every client becomes slower to change every year, until any fix needs weeks.
Stage 3: Build, with an engineer on every line
at the anvil
We build in short rounds, and every round ends in something working that you can open and use. AI does much of the making: it drafts code, tests and screens quickly. A senior engineer decides what is made, reads what comes back and is accountable for every line that merges. Everything goes through one reviewed path to production, in your repository.
1export async function chargeOrder(order) {
2 const body = {
3 amount: order.total,
4 card: order.card,
5 };
+ const key = 'charge-' + order.id;
6 while (true) {
+ for (let n = 1; n <= 3; n++) {
7 try {
8 const res = await pay.post(
9 '/charges', body);
+ '/charges', body,
+ { idempotencyKey: key, timeout: 5000 });
10 log.info('charged', body);
+ log.info('charged', { order: order.id });
11 return res;
12 } catch (err) {
13 await sleep(1000);
+ if (n === 3 || !retryable(err)) throw err;
+ await sleep(250 * 2 ** n);
14 }
15 }
16}- line 6unbounded retry: capped at 3, with backoff
- line 9no idempotency key: a retry could charge twice
- line 9no timeout: 5 s per call
- line 10logs the card: now the order id only
- line 13retries every error: only retryable ones now
signed off senior engineer, accountable for every line above
What you get
Working software early and often. A repository you own, with a history you can read.
When this is skipped
Code that looks right and isn't. AI makes plausible output cheap, and without someone who knows what correct looks like, the plausible version ships. The bill arrives later, usually as a rework.
Stage 4: Put it under load
testing the heat
We push the system past the load it should expect and watch what gives. We take parts away on purpose, a server, a database connection, a third-party service, and check that it recovers the way the plan says it will. We review access, secrets, data handling and dependencies. Where people with different needs will use it, we test keyboard paths, zoom and reflow on small screens.
Before anything goes live there is a final test, and it gets a straight go or no-go. On one platform takeover the morning test failed on two blockers. The date held, both were fixed by midday, the retest passed at 14:05 and the platform went live that afternoon.
What you get
Test results you can read, a list of what was found and fixed and a go/no-go decision made on evidence.
When this is skipped
Launch becomes the first load test and customers become the testers.
Stage 5: Cool it properly
the quench
We fix what testing found, then make the system something your team can run. That means monitoring with alerts that reach a person, logs you can search, backups we have restored at least once so we know they work, and runbooks for the things that will go wrong at 2am. The accounts, code and servers move into your name, and we walk your team through all of it.
We also write down what we didn't do. When a migration plan leaves something out, such as a penetration test or fixes to old code, it says so at the start.
What you get
A system your team can operate without us, plus a written list of known limits.
When this is skipped
You end up with a system only its builder understands. When that builder leaves, you're the one holding something still hot.
Stage 6: Stay for the next release
keeping the fire lit
Software decays if nobody looks after it. Dependencies age, the platforms under it change and small fixes pile up. If you want us to stay, we run it release by release: numbered releases on one roadmap, with your other projects planned against them, patches and dependency updates on a schedule, and the measures you care about reported against a baseline.
What you get
A release rhythm, release notes and regular reporting on what moved.
When this is skipped
A change that should take a day starts taking a month, and the next vendor quotes for a rebuild.
A few things we won't do, even when asked.
Patch and pray.
When something fails we find the cause. If a temporary fix is needed to stop the damage, it is labelled temporary and comes with a date for the real one.
Hand over something still burning.
Open issues and known limits are written down before we leave. You won't find out about them from your customers.
Move a live system without a way back.
Rollback is proven before the first move, and the old system stays one change away until the new one has held.
Ship code nobody has read.
AI writes plenty of it. A senior engineer reads all of it.
Ship on a failed test to protect a date.
We'd rather fix it the same day, as we have before, than find out from your support inbox.