How do we decide without months of analysis?

One question: if a competitor bought the same product tomorrow, would you have lost anything? If no, buy. If yes, that is what you should build, and only that. A four-week discovery answers it with evidence rather than opinion.

Can we start by buying and build later?

Yes, and it is often the right sequence. Buying reveals what your process actually needs, which makes a later build much better scoped. The one thing to protect is your data — make sure you can get it out before you put it in.

Build or buy: the question worth answering before either

Most build-versus-buy arguments are really a disagreement about how unusual the business is. Settle that first and the answer usually follows.

How we engage

The short answer

Buy when the capability is a commodity you consume rather than something customers notice — payroll, email, accounting. Build when the process is how you compete, when no product fits without changing how you work, or when the integration between products is the actual problem. Most organisations should buy more than they do and build fewer, larger things.

Build against Buy.

	Build	Buy
Time to value	Months. Phased, but months.	Weeks, if the fit is genuine.
Fit	Exact, and it stays exact as you change.	Good on day one; drifts as your process evolves.
Ongoing cost	Hosting and maintenance you control.	Per-seat, and it rises with headcount and with renewals.
Differentiation	Possible. This is the only reason to build.	None. Your competitors can buy the same thing.
Who fixes it	You, or whoever you contract.	The vendor, on their roadmap.
Failure mode	Over-scoped, under-adopted.	Death by workaround and shadow spreadsheets.

Compare over the lifespan, not the first year. Build front-loads cost and flattens; buy starts cheap and compounds with headcount, renewals and the integration work nobody budgets for.

When each is the right answer.

Each line below is a condition, not a preference. The matrix above scores the same choice on every axis a buyer weighs.

Choose build when

The workflow is the product — customers or regulators notice how you do it, not just that you do it.
You have already bought twice and worked around both.
The value is in joining systems nobody sells as one product.
The lifespan is long enough for build cost to beat a decade of per-seat licences.

Choose buy when

It is a commodity: payroll, email, accounting, helpdesk, CRM for a standard sales motion.
You need it this quarter and a good-enough fit unblocks real work now.
Nobody internally will own the roadmap after launch.
The total seat count is small enough that licences never approach build cost.

Follow-ups

The most common choice and the most commonly regretted. Light configuration is fine. Heavy customisation gives you the cost of building without the ownership, and every vendor upgrade becomes a re-testing exercise. If you find yourself planning significant customisation, you have already decided to build — the question is whether you are building on someone else's foundation by choice.

Other comparisons

In writing

Discovery ends in a recommendation, including the one to buy.

Where a packaged product covers the need, that is what the document says. The artefacts are yours either way, and they are written to be buildable by anyone.

Get the recommendation Send a brief instead

No sales deck
An engineer on the call, not an account manager
NDA before you share anything