Three Things Can Happen to a System

The honest first answer is that nobody can tell you until they have looked, and that is not evasion. It is the shape of the question.

Build or buy gets asked at the wrong altitude. Asked about a business it has no answer, because a business is not one thing: it is a scheduling tool and an accounting package and a spreadsheet somebody built in 2019 and a shared mailbox doing a job nobody designed it for. Asked about any one of those, it answers almost immediately.

So the work is a sequence of small obvious decisions rather than one large intimidating one, and it starts as an inventory rather than a proposal. That also answers the fear sitting underneath every project of this kind, which is that everything familiar is about to be taken away and replaced with something that needs a training course.

Nothing gets thrown out to make room. Each system gets one of three fates.

When it does its job. That is the whole test, and it applies far more often than anybody selling software would like.

Your accounting package is probably fine. So is the industry system you bought because it does the one regulated thing your sector needs, and so is the ledger nobody enjoys but everybody trusts. Keeping them is not a compromise. It is the correct answer, and the new work connects to them rather than around them.

Nothing gets added to your licence bill for that, and nothing on your side has to change. If somebody proposes replacing a system that is doing its job, the burden of proof is on them and it is a heavy one.

We have done this in its purest form. A medical equipment business came to us after two previous development partners had customised their bought software so heavily that it could no longer take an upgrade. The third attempt changed nothing inside it at all, and that business is now on the current version and able to take the next one.

More than the change, forever, and that is the mechanism behind the previous section.

Every modification to a standard product has to be re-fitted every time the product moves underneath it. So you pay once to build the change and then indefinitely to keep it working, and the second cost is the one nobody budgets for because it arrives in instalments.

There is a version of this the large vendors argue themselves, and they are right about it: you should not modify the core, because that is what lets standard software keep working through upgrades. The part they leave out is the assumption that the core has to be theirs. Keep the ordinary parts ordinary. Put everything unusual in code that belongs to you.

Which is a slightly awkward position to hold, because it means agreeing with the incumbent’s best point and disagreeing only about who owns the middle.

When it is not doing the job, which is a different situation from one you are tempted to customise, and the two get confused constantly because both start with somebody complaining about software.

They are opposite decisions. Customising a working system is how you pay forever. Replacing a failing one is how you stop paying. If the thing genuinely is not doing what it needs to, do not put money into bending it.

What usually replaces it is open source, and the reason is not price. The thing being replaced is almost always something ordinary, like scheduling or tickets or documents or chat, and ordinary is exactly what a large, actively maintained open source project is good at. Twenty is a genuinely good customer list. Plane handles projects with real depth. Mattermost is proper team communication. These are chosen on merit and running one is not a saving you are settling for.

It gets priced the same way each time: a server, a once-off fee to install it, and a monthly fee to keep it running.

Some of them, and being able to say which is what makes the rest of this believable.

Mail is the clearest case and it settles more than mail. Every business needs email, documents, spreadsheets and meetings. There are self-hosted options for the documents half, and going that way leaves your email in the wild, which is the one part nobody should be improvising: deliverability, sender reputation, authentication, recovery, and the plain fact that everything the business does eventually arrives through it.

Take mail from Google or Microsoft and the rest comes with it. Documents, spreadsheets, meetings, one login, one place a leaver’s access gets switched off. So that is what we tell people to do, and we will say it in a meeting where we are visibly not selling it.

We will never propose self-hosting your mail. It is the one place where this whole way of thinking, followed consistently, produces a worse business. We pay for two further subscriptions in our own business on the same reasoning: somebody else being responsible is the point, not a compromise.

By what happens if it goes away, and by whether any customer would notice how you do it.

If a system disappeared tomorrow and the business would grind but nothing about why customers choose you would change, it is ordinary. Keep it or replace it, and spend nothing thinking about it again. If it disappeared and the thing you are best at went with it, you have found the third one.

Most businesses get the split backwards, and expensively. The money goes into customising the ordinary, where it buys nothing and is paid for forever, while the part that actually wins work sits in a spreadsheet because nobody ever thought of it as software.

The third fate is the expensive one, and the next chapter is about why it is worth it. The standalone essay on the same subject comes at it from the other end, if you would rather read about the split than about the sequence.