The case against custom software just expired

Ask anyone who has run an operations-heavy business what they think of custom software and you will hear a version of the same story. It took twice as long as promised. It cost three times the quote. The developer who understood it left, and now nobody dares touch it. So the next time around they bought something off the shelf, and spent the following decade working around it.

That story produced a rule that has governed business software for thirty years: buy, don't build. Adapt your process to the product. Custom is for companies with engineering departments.

The rule was correct. It is worth being precise about why, because the reasons are what changed.

Why the old advice was right

Custom software had three real problems.

It was expensive to build. Every system, however ordinary, began from a blank page. Logins, permissions, audit trails, file uploads, notifications, reporting — the unglamorous plumbing every business system needs consumed most of the budget before anyone wrote a line that was specific to the business paying for it.

It was expensive to change. A business is not a fixed specification. Pricing rules change, a new product line arrives, a regulator asks for a new report. Each change meant finding a developer, waiting for them to re-learn the system, and paying for the re-learning. So changes were rationed, and the software drifted away from the business it was written for.

It made you dependent on its author. This was the worst of the three. Legally, the client owned the code. Practically, the code lived in the head of whoever wrote it. Understanding an unfamiliar codebase took a capable engineer weeks or months, which meant the original developer held a quiet monopoly. The client owned the system the way you own a safe you don't have the combination to.

Against those three costs, the alternatives looked rational. Off-the-shelf software was fast to buy and someone else's problem to maintain. The price was fit: you ran your business the way the product imagined businesses run. Where the product's imagination ran out, a spreadsheet appeared. Then another. Then an Access database somebody's nephew built in 2009, which is now load-bearing.

This is how a typical established company arrives at its current state: an ERP nobody likes, a dozen subscriptions that don't talk to each other, and a layer of spreadsheets, email approvals, and institutional memory holding it all together. The real operating system of the business is the people moving information between systems by hand.

What actually changed

It is tempting to summarize the shift as "AI writes code now." That is true and it is the least interesting part.

Building got dramatically faster. An experienced engineer working with modern AI tools produces working, tested software at a pace that would have been implausible a few years ago. Not because the machine replaces the engineer's judgment — it doesn't — but because the hours that used to go into typing out the predictable parts now go into the parts that need thought. The plumbing that once ate the budget can be standardized once and reused; the engineering effort goes into the model of your business.

Changing got cheaper. The same tools that accelerate building accelerate modification. A change that once required a week of re-familiarization can begin in an afternoon. That matters more than build speed, because most of the lifetime cost of software is change, and because software that is cheap to change can stay aligned with a business that keeps moving.

Understanding got cheap. This is the one that breaks the old model, and it is the least discussed. An AI system can read an entire unfamiliar codebase and explain it: what the modules do, how data flows, where a given rule is enforced, what would break if you changed it. The thing that used to take a new engineer months — building a mental map of someone else's system — now takes days, and the tools keep improving.

Follow that through. If understanding a codebase is cheap, the author's monopoly is gone. If the author's monopoly is gone, the dependency problem — the most serious objection to custom software — is no longer a law of nature. It becomes a design choice.

Dependency is now a design choice

Here is the uncomfortable part for firms like ours. Lock-in was never only an accident of the technology. It was also a business model. A client who cannot leave is a client who renews.

Software-as-a-service made this explicit: pay forever, your data lives with us, your workflows fit our product, and our roadmap decides what you can do next. Traditional custom development made it implicit: you technically own it, but only we understand it.

If the cost of understanding is collapsing, then a builder can choose to push it toward zero on purpose. That means mainstream technologies rather than clever ones. A predictable architecture that looks the same from project to project. An explicit model of the business in the code — customers, quotes, orders, jobs — named the way the business names them. Strong typing and tests, so a newcomer can change things and find out immediately whether they broke something. Records of why decisions were made, not only what was decided. Documentation for deploying, restoring, and recovering. And structured context written specifically so an AI system can orient itself in the project.

Every one of those choices makes a system easier for the next engineer to pick up, whether that engineer is a person, a machine, or most likely both working together. We think of it as shipping the instruction manual with the machine.

Software should never become organizational archaeology. When it does, it is rarely because the problem was hard. It is because nobody was paid to make it legible.

This is not a claim that maintenance is free or that technical debt has been abolished. Systems still need care, and bad software can still be written quickly — more quickly than ever, in fact. The claim is narrower and more useful: the cost of walking into an unfamiliar, well-built system is falling fast, and you can deliberately build to take advantage of that.

What this makes possible

Put the three shifts together and a different model appears.

You no longer have to choose between software that fits and software you can afford. A system modelled on how your business actually works — your quoting rules, your production flow, your approval chain — is now within reach of a company with fifty employees, not only one with five thousand.

You no longer have to replace everything at once. The big-bang ERP implementation existed because the fixed costs were so high that it only made sense to do it all in one go. When building is fast, you can start with the single workflow that costs the most time or money, put working software in people's hands, measure it against the old way, and move to the next. Over time the pieces converge into one operational platform. Nobody had to bet the company on a go-live date.

You don't have to replace what is already good. Accounting, payroll, payments, email, identity — these are commodities, and the products are excellent. Keep them. The opportunity is the layer in between: the part of your operations that is specific to you, which is exactly the part no vendor will ever build, because you are the only customer for it.

And you can own the result in the full sense of the word. The code in your repository. The data in your database, in a schema you can read. The infrastructure in your accounts. The documentation in your hands. If the firm that built it disappears, gets too expensive, or simply stops being the right fit, another capable team can take over.

Why we build it this way

We build every anode system so that the client can leave us. People sometimes ask whether that is commercially reckless.

We think it is the opposite. A firm that keeps clients by making departure impossible has no ongoing reason to be good. A firm whose clients can walk at any time has to keep earning the relationship — by making the business measurably better, month after month. We would rather compete on that.

It also turns ownership from a line in a contract into something a client can feel. Owning your software should mean what owning anything else means: you can use it, change it, hand it to someone else, and keep it running without asking permission.

For thirty years businesses conformed to their software because the alternative was out of reach. It isn't anymore. Your business shouldn't have to fit your software. Software should fit your business — and belong to it.

---

If there is one workflow in your business that everyone quietly dreads, that is where we would start. Tell us about it.