The studio that fixes other people's code

Around a third of what we do is code somebody else wrote, in a hurry, and we did not choose the deadline. It is also the work people find hardest to buy, because the natural question is why should I trust this team with a system they cannot see?

Fair. Here is how we approach it.

Day one is reading, not fixing

We start by reproducing the problem on the current code. Before anything else. Because a bug that cannot be reproduced is not a bug we have diagnosed, it is a symptom we have taken on trust, and we will not quote a fix for something we have not seen fail.

Reading somebody else's code is slow and unglamorous. It is also the only part of the work that determines whether the rest is safe. The bug is usually obvious once you understand why the code was written that way, and that "why" is written nowhere.

What we usually find

Roughly in order of frequency:

A null check that was removed in a hurry. The line is still there, guarding the wrong condition, and something upstream changed three months ago.

A dependency that stopped behaving. An unpinned major version, a library that changed a default, an API quietly deprecating a field.

A race condition. Usually in code that was fine until the volume doubled, and it is the most expensive category because it is intermittent and therefore hard to sell to anyone who has not yet lost data to it.

The bug is not the bug. The symptom is real and the cause is somewhere else entirely — usually a configuration value or an environment assumption that stopped holding.

What we will not do

We will not take a project on the strength of a description. If you cannot get access to the code and a way to reproduce it, we cannot help, and any studio that says otherwise is guessing.

We will not patch around a structural problem and call it fixed. Sometimes the right answer is a one-line change. Sometimes it is that this module should not exist. We will tell you which, and if the second one is true we will say what it costs.

We will not sign an NDA and then tell you the name of the person who wrote the original code. That is their confidentiality and their liability, not ours to trade.

Why we publish a £1,000 minimum and no rate card

Because the buyer with a broken system and a small budget is the most time-pressured buyer there is, and a published rate card filters them out. "From £5,000" reads as "not for us", and the system sits broken for another six months.

A published floor puts us in front of someone who needs one thing fixed.

The part that should worry you if you are choosing a studio

Ask what happens if the fix makes it worse.

Any competent team has a branch and a way back. The question worth asking is whether the person you are talking to will tell you what caused it, even when the answer is something embarrassing about their own earlier work. If they will, you can work with them.

What you get

The fix, a test that fails without it, and a written note explaining what was actually wrong and whether the same pattern appears elsewhere in the codebase.

That last part is the one people do not ask for and the one that matters most. A bug fixed in isolation is a bug waiting to recur, and the note costs an hour.