Build vs buy for internal tools: a practical decision framework

Your team needs a tool: a job tracker, an approvals queue, a quoting screen, somewhere to log customer complaints. One person has found a SaaS product that covers most of it. Another says it'd take a developer a few weeks to build exactly what you want. Both sound reasonable, and the meeting goes in circles because nobody has agreed what the decision actually hinges on.

There's a fair amount of well-tested thinking on this, much of it from public-sector technology teams who have to justify the choice in writing. Here's a version of it you can run for a small business.

First question: does this tool make you different?#

Martin Fowler's short essay Utility vs Strategic Dichotomy is still the clearest starting point. He splits software into two buckets based on the business function underneath it, not on the technology. Payroll is his classic utility example: it has to work, but doing payroll in an unusual way won't win you a single customer. Strategic software supports something that sets you apart from competitors.

His advice follows directly. For a utility, "the obvious thing is to go with the package", and you should bend your process to fit the package rather than customise it heavily. For a strategic function, "you don't want the same software as your competitors."

Two details in that essay are easy to miss. Fowler says only a few projects are strategic, and he suggests forcing every system into one bucket or the other, tilted so the strategic bucket stays small. Most internal tools are utilities. Your leave-request form isn't a competitive advantage, however particular your team is about it.

The test is about how the work gets done, not how much it matters. Invoicing matters enormously. It's still usually a utility, because customers don't choose you for your invoicing workflow. A scheduling engine that lets a field-service business fit in two more jobs a day than its rivals might well be strategic.

Your requirements are probably less unique than they feel#

The UK Government Digital Service put this bluntly in a blog post on building versus buying: "Your project's needs are more likely to be common than unique." The same post warns that customisation "is not only expensive, but can make the product or service harder to maintain or update."

The official GOV.UK purchasing strategy guidance goes further: "Even small modifications to OTS software can remove most of the benefits of using it." Its recommendation is to configure off-the-shelf products through their settings and use them as intended, so the vendor still supports you when new versions ship.

This is where most buy decisions go wrong. A team buys a product, then pays a consultant to bolt on custom fields, scripts and workarounds until it behaves like the in-house tool they wanted in the first place. They now have the subscription cost and the maintenance burden. If the product only fits after heavy modification, that's a signal you're in build territory, or that the process itself needs simplifying.

A useful exercise is to write your requirements down and mark each one as either "we need this" or "we're used to this". The second list is usually longer, and a good off-the-shelf product often handles those needs in a different but perfectly workable way.

Count the cost over the tool's whole life#

Build estimates tend to cover the first version and stop. The GOV.UK guidance asks you to understand as much of the full cost of building or buying as possible, across the product's lifecycle: "building or buying, upgrading, continuous improvement planning and retirement."

Google's engineers make a similar point in the opening chapter of Software Engineering at Google: "Software engineering is programming integrated over time." The authors describe a project as sustainable if, for its expected life, you can keep reacting "to whatever valuable change comes along, for either technical or business reasons." They also note that over a decade or more, most of a program's dependencies will likely change.

For a small internal tool, that translates into concrete line items. Someone has to apply security patches to the framework and libraries, move the app when the hosting platform deprecates something, fix it when an upstream API changes, add the field the finance team asks for next year, and answer the question "why is it doing that?" long after the original developer has moved on. A bought product bundles most of that into the subscription. A built one puts it on your payroll or your contractor's invoice.

So compare like with like. Put the subscription cost for three to five years, plus setup and training, next to the build cost plus a realistic annual allowance for maintenance and hosting over the same period. If you can't estimate the maintenance side at all, treat that as a risk in its own right.

Check that you can own what you build#

The GDS post makes a point that applies to both paths: "you cannot outsource risk." Whether you build or buy, someone in your business has to understand the tool well enough to manage it, notice when it's failing, and make decisions about it.

For a build, that means asking who will maintain it. A tool written by one enthusiastic staff member, with no documentation, tests or second person who understands it, is a liability the day that person goes on leave. The same post notes that organisations with strong technical expertise are more likely to consider building. If you don't have that in-house, budget for an ongoing relationship with a developer or agency, not a one-off project.

For a buy, ownership means knowing where your data lives, who the admins are, what the integrations depend on, and how you'd get everything out. GOV.UK's guidance warns that customisations can restrict you from upgrading or removing a product in future, and it asks for contracts to be explicit about data ownership. Before you sign, test the export. If the only way to leave is a CSV of half your records, that changes the real price.

The options between build and buy#

It's rarely a clean binary. The GDS post describes mixed approaches, such as building some components yourself or hiring specialists to build for you. In practice, for small teams, the useful middle options look like this:

Reuse is worth checking before any of these. Australia's Digital Transformation Agency tells federal agencies to "Reuse whenever possible", citing the chance to reduce duplicated investment and lower build and run costs. For a business, the equivalent question is whether a tool you already pay for (your CRM, accounting package or project management system) can handle the job with a bit of configuration.

A decision framework you can run in an hour#

Get the people who'll use the tool and the person who'll pay for it in one room, and work through these questions in order.

1. Is the underlying business function a differentiator, or a utility? Force a single answer.
2. List the requirements, then split them into needs and habits. How many genuine needs does the best off-the-shelf option miss?
3. Could any of those gaps be closed by configuration or an integration, rather than modification?
4. What's the three-to-five-year cost of each option, including maintenance, hosting, training and the time of whoever looks after it?
5. Who will own it? Name a person, and a backup.
6. How would you leave? For a product, test the data export. For a build, check the code, documentation and hosting accounts are in the business's name.

If the function is a utility and a product covers your genuine needs with configuration, buy it and adapt your process. If it's strategic, nothing fits without heavy changes, and you can name who maintains it, build it. When the answers are mixed, buy for the commodity parts and build only the thin piece that's specific to you. That last pattern is how we usually approach client work at TheAILAB, because it keeps the custom code small enough to maintain.

Write the decision down and set a review date#

Fowler points out that functions can move between buckets over time, and products and prices change too. Record which option you chose, the main reasons, and the trigger that would make you revisit it: the vendor raising prices past a set amount, the tool needing a capability it can't provide, or the process becoming something customers notice. A one-page note like that turns the next build-vs-buy argument into a ten-minute check rather than another meeting that goes in circles.

Sources

1. Utility Vs Strategic Dichotomy — Martin Fowler (2010, updated 2016) (checked 2026-10-18)
2. To build or to buy - that's the technology question — Government Digital Service, GOV.UK Technology blog (Amina Omar, 3 February 2021) (checked 2026-10-18)
3. Define your purchasing strategy — GOV.UK (Technology Code of Practice guidance) (checked 2026-10-18)
4. What Is Software Engineering? (Software Engineering at Google, chapter 1) — Titus Winters, ed. Tom Manshreck (Google / O'Reilly, free online edition) (checked 2026-10-18)
5. Purpose of the Digital and ICT Reuse Policy — Digital Transformation Agency (Australian Government) (checked 2026-10-18)