Why we ended up specialising in software nobody else would touch
Key takeaways
Nobody sets out to specialise in other people’s unfinished software. What thirty years of opening unfamiliar codebases teaches you, and why pricing every job up front was the decision that mattered.
Nobody sets out to specialise in other people's unfinished software. It is not a market anyone chooses on purpose. You end up there because the work keeps arriving and you turn out to be one of the few firms willing to do it.
The jobs everybody else says no to
The pattern took years to notice. Somebody would ring about a system that already existed, and the conversation would follow the same shape: they had approached two or three developers, and every one of them had recommended starting again.
Sometimes that is honest advice. Far more often it is the easier sale. Reading somebody else's code is slow, unglamorous work with no clear end point, and quoting for it means committing to a number before you know what you have found. Building from scratch is simpler to price, more enjoyable to do, and considerably more expensive for the customer.
So the takeover work fell to whoever was prepared to open the codebase and read it. We were, mostly because after enough years you stop being frightened of other people's code. It is rarely as bad as feared, and when it is bad, being told so plainly is worth more than being sold a rebuild.
What thirty years teaches you
Two things, and they are related.
Most software is salvageable. The instinct on opening an unfamiliar codebase is that it is a mess and should be replaced. Sometimes true. Usually what looks like a mess is a system that grew under real deadlines with real constraints, written by somebody competent who ran out of time. It can be understood, and once understood it can be extended.
The money already spent is not automatically wasted. When somebody has spent a serious sum on a half-finished project, telling them to write it off is a big claim, and it needs proving rather than asserting. Often a substantial amount of what they paid for is fine, and the honest recommendation is to finish it rather than start again.
Neither of those is a sales position. They are just what turns out to be true more often than not, and being willing to say so is most of the specialism.
Why it is a wedge, not the whole business
It matters to say this, because a firm known only for rescues starts to look like a firm that only does rescues.
The takeover work is where we are unusual. It is not the majority of what we do. The same week will contain a Python script that runs on a schedule, a discount code field on somebody's checkout, an integration between an accounting system and a website, and a mobile app going through its third round of App Store review. Some of it is on software we built, most of it is not.
What connects it is not the type of work. It is being willing to take on a job that is smaller, messier or more awkward than the people you asked before were interested in. The rescue work is the most visible version of that, which is why it gets its own page, but a one-line change to a WordPress site nobody will touch is the same instinct at a different scale.
The thing that actually changed
The one decision that made the difference was not technical. It was pricing every job before starting it.
Open-ended billing and inherited code are a terrible combination, and everybody involved knows it. The customer cannot tell whether four days of investigation was necessary or thorough, and the developer cannot promise it was not. So the work gets priced up front, per job, and if it turns out to be bigger than it looked we come back before doing it rather than after.
That removes most of the reason people are afraid to hand over a difficult project. It also means we occasionally do work at a loss because we misjudged it, which is the correct incentive: it is our job to estimate accurately, not the customer's job to absorb the error.
Where this leaves you
If you have something half-finished, or something nobody wants to touch, it is worth a second opinion before you accept that it has to be rebuilt. We will tell you if it genuinely does, and we will show the working.
If you have something else entirely, a new build, a small change, a script, an app, that is the same conversation. The range of work is wider than the rescue stories suggest.
Either way, you can get a fixed price without a call, and if it turns out you do not need a developer for this, we will say so.