Build It or Buy It

Start from buying. Most of what companies want here is something several vendors already sell, and those vendors have spent years on the awkward parts nobody thinks about at the start. Build only when what you need is genuinely specific to your business, and be strict about what specific means.

We build software for a living. Telling you to buy costs us work, and it is still the right advice more often than not. The projects that go badly are usually the ones where somebody rebuilt a commodity because building felt more serious than buying.

The decision is not permanent either. Buying now and replacing it in three years is a perfectly healthy outcome, provided you can get your data back out. Whether you can leave matters more than most of the feature comparison people spend their time on.

Specific means a vendor could not sell the same thing to your competitor without changing it substantially. That is the test. It usually shows up in one of a few places: a process you run differently from everyone else in your industry and win because of, data nobody else holds, or a workflow crossing systems in a combination only you have.

Watch out for the industry claim. Almost every company believes its sector is unusual, and almost every sector has vendors serving it well. Being in an unusual industry is a different thing from having an unusual process, and the vendor probably knows your industry better than you know their product.

The strongest case for building is a dataset only you hold. If you have years of records nobody else has, and the value comes from a system that reads them, no vendor can package that for you. Most of the work in that case is about your data rather than about the model, and that part cannot be bought at any price.

The second strongest case is when the capability is how you compete. If customers choose you partly because of this specific thing, owning it is worth the cost and the trouble. If it is a cost centre you would rather not think about, buy it and spend your attention elsewhere.

A shared support inbox with automatic answers is a crowded product category, ours included. So is meeting transcription. So is search across internal documents. So is pulling fields out of invoices. If your requirement fits one of those descriptions, you are choosing between products rather than deciding whether to build.

The usual objection is integration. Our systems are unusual, so nothing will fit. Sometimes true, and worth testing rather than assuming, because products in these categories have spent years on connectors and the cost of one integration sits far below the cost of a build.

The second objection is control of the data, which is a real concern with a cheaper answer than building. Business terms, retention settings and a written list of what may not go in handle most of it. Building your own system does not remove that risk. It moves the risk to a system with fewer people looking after it than the vendor has.

The prototype is not the cost. A capable engineer can produce something impressive in a fortnight, and that fortnight is what everybody remembers when the budget gets set. Everything after it is the actual price.

You need an evaluation set and somebody to maintain it. Monitoring, so you hear about a regression before your customers do. Somebody on call when it breaks at an inconvenient hour. Updates when a provider retires a version. Content and prompt maintenance as the business changes around it. Security review. Access control. All of that is permanent and none of it is interesting.

Then the key person risk, which is severe with this kind of system. They often end up understood by the one engineer who enjoyed building it. When that person leaves you own something nobody can safely change, and this is more common than anybody admits in public. Ask who the second person is before you start, and get a real name.

Assume the running will outlast and outweigh the building. Plan on the basis that the build is a deposit rather than the price, and check whether the business case still works on that footing.

Buying carries its own consequences. You are accepting somebody else's roadmap. Features you need may arrive late or never. Features you did not ask for will arrive anyway and change how your staff work. If your requirement is unusual within their customer base, you will sit at the back of the queue permanently and nobody will tell you that.

Pricing tends to grow. Models based on seats grow as you hire. Models based on usage grow as adoption succeeds, which is a strange thing to be punished for. Read what happens at the next tier and what happens at renewal, and ask directly what the price has done for existing customers over the last few renewals.

Then the exit. Before signing, find out how you get your data out, in what format, and how long it takes. Ask specifically about the parts that are not obviously data: the configuration, the routing rules, the knowledge base you built inside their product, the conversation history. Vendors rarely refuse to answer this. They are rarely asked.

There is a sensible middle, and it is where most of our own work lands. Buy the plumbing and build the thin layer that is specific to you. Use a hosted model rather than running one yourself. Use established components for retrieval rather than writing your own. Then build the part that encodes how your business actually works.

That thin layer is usually small, and it holds the value. The rules deciding which customer gets which answer. The join between two of your systems that nobody else has to make. The check that catches a particular expensive mistake in your industry. Days of work rather than months, sitting on top of components you did not write and do not maintain.

Keep the boundary clean so the parts underneath can be swapped. Providers change, prices change, and something better appears regularly. A system where the model sits behind an interface you control can move in an afternoon. One where provider specific details are threaded through the whole codebase cannot, and you find that out at the worst possible moment.

Three questions settle most cases. Would you still want to own and maintain this in three years. Does what you would build depend on data or a process nobody else has. Could a competitor buy something equivalent tomorrow. Two noes and a yes to the last one points at buying, and the argument is usually over there.

Then ask who would run it. Everybody enjoys answering who would build it. Running it is the harder question. Who is on call. Who owns the evaluation set. Who reads a sample of the output every month. If those names are unavailable or already fully committed, you are not in a position to build, whatever the strategic argument says.

And run a small slice of the build before committing to the whole thing. Two weeks of real work against your real data teaches you more about the difficulty than any amount of estimating, and it produces the evaluation set you would need for a proper vendor comparison anyway.

A team wanting automatic answers on a support inbox, with an ordinary help centre and no unusual compliance position, should buy. The category is mature, the products cost far less than a build, and the difficult parts have already been solved by people who had to solve them for everybody else first.

A team wanting search across internal documents that nearly all staff are allowed to read should also buy. Where the permissions are complicated and specific to how your company is structured, the answer starts to shift, because that is exactly the part vendors handle generically and you need handled precisely.

A team sitting on years of their own operational records, wanting something that reads those records and supports a decision only they make, should build the thin layer and buy everything underneath it. That is the case where owning it pays for itself, and it is rarer than the number of companies who believe they are in it.