Buy vs build

The short answer

Buy when the process is standard and your version of it is not a competitive advantage. Build when the process is the advantage, when no product fits without changing how you work in ways that cost more than the software, or when the integration between products is itself the product.

Side by side

Buy — almost always — when

• It is accounting, payroll, email, HR, helpdesk ticketing, storage or a general-purpose CRM. These are solved problems and your version will be worse.
• A product covers 80% of the workflow and the missing 20% is preference rather than requirement.
• The process is regulated in a standard way and the vendor already carries the certifications.
• You have no appetite to own software for the next five years — because that is the real commitment, not the first release.

Build when

• The workflow is the business: how you price, triage, assign, review or decide is why customers choose you.
• Every product you have trialled requires changing the process in a way the people doing it will not accept — so adoption fails and you pay for shelfware.
• The real work is the joins: three systems that must agree, with rules that no single vendor owns.
• Per-seat licensing punishes you exactly where you are growing.
• You need data to stay in a specific jurisdiction, or a model never to see certain fields.

The third option most people skip

Between buying and building sits configure and connect: keep the products you already own, and build only the thin layer that makes them behave like one system — routing, rules, a shared view, an approval step, a report nobody can currently produce. It is the cheapest option in the table and the most frequently overlooked, because it is not exciting for either the vendor or the developer. It is often the right answer for two or three years, after which the picture is clearer and a build is a smaller bet.

Costing it honestly

Compare five years, not one, and put both columns on the same terms:

• Buy: subscription at today’s headcount, plus realistic growth, plus implementation, plus integration work, plus the modules you will need later, plus the annual increase.
• Build: delivery, plus hosting, plus maintenance and dependency upgrades, plus support, plus the changes the business will ask for — assume a meaningful fraction of the build cost every year.

Any build case that shows zero ongoing cost after launch is wrong. Software that is not maintained becomes a liability faster than most boards expect, and the maintenance line is precisely what separates an honest proposal from an optimistic one.

Does AI change the answer?

It changes one column. Work that used to require either a rigid product or a large team — reading documents, classifying enquiries, drafting responses, extracting structured data — is now buildable at a scale that was not viable a few years ago. That widens the band where building beats buying, particularly for workflows that were never standard enough for a product to exist. It does not make maintenance free, and it does not make a bespoke general ledger a good idea.

Next step

Bring the workflow, the products you have already tried, and what went wrong with them. That conversation usually settles it in under an hour, and sometimes ends with us telling you to buy something. Start there. See also: AI sprint vs full build and specialist studio vs staff augmentation.