The Long Answer

Chapter seven · The objection

No Spells

Custom software used to mean depending on whoever wrote it. That is the part that changed, and it is the objection that stops most businesses before anything else does.

August 2026 | 5 min read
Wilfred Greyling

Wilfred Greyling

Systems & Infrastructure

A clay machine standing open on a workbench with its whole inside on show: brass gears, a coil spring, copper wire and an amber light burning behind the works, still running with the panel off. An ordinary steel spanner is taped in among the gears and silver tape holds the open door, one person's undocumented fix. Behind it a rank of ordinary machines stands blurred, their portholes teal

TL;DR

The reason people flinch at having software built is real and it is historical: it used to mean depending on whoever wrote it, forever. What changed is that code is now legible: to us, to your own people, and to whoever comes next, with tools that can read a codebase and explain it. The handover cost is days of orientation rather than months of archaeology. We have watched two founders leave projects that then carried on without them.

Why did custom software get such a bad name?

Because for a long time the objection was correct.

Software written for one business, by one person or one firm, used to arrive with a dependency attached. The people who wrote it understood it. Nobody else did. There was documentation, in the sense that a folder existed, and it described a version of the system that had stopped being true about four months in.

So the price of the thing was never the price of the thing. It was the price plus a relationship you could not leave, and everybody who has been through it once can feel the shape of it coming a second time. Most of the people we talk to have been through it.

Usually it was one of two failures. Either nobody decided what was actually worth building, so a great deal got built and none of it was the point. Or what got built could only be understood by the people who built it. Both are avoidable and both are the builder’s fault rather than the buyer’s.

What actually changed?

Code became legible, and that is a bigger shift than it sounds.

Written conventionally, documented and tested, a codebase can now be read and explained in plain language by tools that anybody can point at it. Not just by us: by your own people, and by whoever you hire in three years when we are not in the picture. Somebody arriving cold gets days of orientation instead of months of archaeology.

That does not make the code write itself, and this is the part worth being careful about. Between somebody making a change and that change safely reaching a live system there are still environments, tests, migrations, access control and a person who gets a phone call when it breaks. Anybody who tells you it is a prompt away is describing a demo and not a business.

What changed is the handover cost, and the handover cost was the entire objection.

You are three people. What happens if you disappear?

We are, and it is the right question to ask.

It is also the reason everything gets written the way it does. A large firm can afford to make its work hard to leave, because the switching cost is part of what it sells. We cannot afford that even if we wanted it, so the opposite got built in from the start.

What I can point at is not a promise. Armand, one of ReadyRun's founders, left for reasons to do with work and life rather than the work itself. The API design and the clustered renderer pattern on the Folio platform are his, and they carried on without him. The same happened on Medeq. Neither client had a bad month because of it, and nobody outside noticed either.

The honest limit on that: in both cases the work was picked up by somebody already close to it, not by a stranger arriving cold. That is what the promise would mean in full, and it has not been tested that way yet. It seemed better to say so than to let the story grow in the telling.

Could we not just build this ourselves now?

Some of it, genuinely. More of it every year, and anybody claiming otherwise is protecting their own position.

But the typing was never the hard part. Knowing which bit of how you work is worth building, and which bit should be left completely standard, is the part that decides whether the money was well spent. Get that wrong and the new tools help you build the wrong thing considerably faster than before.

That is also the honest boundary of what we are selling, and it is worth stating plainly. The build is openly transferable and always has been. The judgement about what is worth building is the part that is actually charged for. An agent can read a repository and explain it. It cannot tell a business which part of how it works is its advantage.

The typing was never the hard part. Knowing what is worth building is.

What does owning it actually mean in practice?

That it survives the relationship ending, which is the only version of ownership that means anything.

The source sits in your repository. It runs in your tenancy, on conventional, widely used technology, using nothing exotic that only one firm understands. If you leave, it leaves with you: not an export of the data, the whole thing.

It also does not turn you into an IT department, which is the practical fear behind most hesitation about owning software. The infrastructure, the backups and the monitoring stay with us. You own the house; the pipes are still somebody else’s job.

None of which matters to a customer. Which is the last chapter.