Build, buy or partner: write the reasons down

Every company has a system nobody can explain. It was chosen five years ago by someone who has since left, it costs more each renewal, and the only reason anyone gives for keeping it is that changing it sounds painful. The original decision may well have been right. Nobody can tell, because nobody wrote down why it was made.

In 2011 Michael Nygard proposed a simple fix for this in software teams: record each significant decision in a short document, with its context and consequences. The idea spread well beyond software; the UK Government Digital Service, for one, recommends the same format. It works just as well for the build, buy or partner choices that executives make, and it takes about an hour.

Four options, not two

The question usually gets framed as build versus buy. There are at least two more options, and they are often the right ones.

Build when the system is how you compete, and nothing on the market does it your way.
Buy when the work is common to every company like yours. Scheduling, payroll and analytics rarely set anyone apart.
Partner when a vendor already owns most of the problem and you need to extend it. Adding a module to your existing ERP is often cheaper than a new system beside it.
Keep what you have, when it works and the cost of change is higher than the gain. This is a real decision, and it deserves a review date like the others.

A short rule covers most cases: buy what is common, build what is yours.

The one-page record

Here is the template we use. Copy it into whatever your team already writes in.

Decision:      What we chose, in one sentence.
Date and owner: Who decided, and who owns the system now.

Context:       The problem, the numbers behind it, and the deadline.

Options:       Build, buy, partner, keep. One line each on
               why it was in or out.

Why this one:  Cost over three years, including people and upkeep.
               Time until real users rely on it.
               Who owns the data, and how we would get it out.

What would change our mind:
               The signal that says this was wrong.

Review date:   When we look at this again, even if nothing broke.

The two lines that matter most are the last two. "What would change our mind" turns a hunch into something you can check. The review date makes sure someone actually checks it.

Mistakes we see often

The most common one is comparing a vendor's licence fee with the cost of building, while leaving out who maintains the built version for the next five years. Building is rarely a one-off cost.

The second is deciding on the strength of a demo. Demos show the happy path. Ask to see the export, the admin screens and the audit log, and ask what leaving would involve.

The third is forgetting the exit. Every system should have an owner and an exit plan from the day it is chosen. If nobody can say how you would leave, the decision is not finished yet.

An illustrative example

Take a field-service company deciding what to do about five systems at once. On our management consulting page, the capability map shows one way it can come out. Buy and configure a proven dispatch product, because scheduling is not where the company differs. Build the offline field app, because technicians working with no signal is the edge. Partner with the ERP vendor on billing, since the vendor already owns that data. Keep the parts system until volume doubles.

Each of those choices fits on one page, with its reasons and a date to revisit it. Two years later, when someone asks why the field app was built in-house, the answer is already written.

Start with the next decision

Pick the next system you are about to sign for, build or renew, and fill in the template before the meeting rather than after it. If you want a second view on the options, technology strategy is part of our management consulting work.