Skip to content

Strategy

A decision framework for technology leaders drowning in tools that each solve 70% of a problem.

Published
7 May 2026
Reading time
5 min
Topic
Strategy

Every growing company arrives at the same room: fourteen SaaS subscriptions, four of which overlap, two that one team depends on and nobody else has heard of, and a renewal in six weeks. The question on the table is always framed as buy or build. It is the wrong pair of options.

The third option is the cheapest

A surprising share of internal tooling exists to support a process that no longer needs to exist. Before evaluating vendors, we look for the reports nobody reads, the approval steps that have never once resulted in a rejection, and the data being carefully synchronised between two systems that could be one.

Deleting a process is the only option with a negative cost of ownership. It is also the one nobody is incentivised to propose, which is often why an outsider is useful.

When buying is right

  • The problem is genuinely generic — payroll, email, identity, payments. If your solution to it would be indistinguishable from everyone else's, it is not a place to spend engineering.
  • The compliance burden is high and specialised. Buying transfers a category of risk you would otherwise have to staff for.
  • You need it working this quarter and the differentiation is elsewhere.

When building is right

  • The process is the business. If how you do it is why customers choose you, do not outsource its shape to a vendor's roadmap.
  • Integration cost approaches build cost. Once you are writing significant glue, versioning it and maintaining it through the vendor's upgrades, you are already building — with less control.
  • The data has compounding value. Systems that accumulate proprietary decision history get more valuable over time. That asset should not sit in someone else's schema.

The honest arithmetic

Build estimates are usually wrong because they price the first version. Price the third year: maintenance, on-call, the migration when a dependency is deprecated, the engineer who has to learn it after the author leaves. Buy estimates are usually wrong because they price the licence and not the integration, the data extraction, or the day you want to leave.

Ask what it costs to reverse the decision. The option that is cheaper to undo deserves a lower burden of proof.

AI has genuinely shifted this line. Work that was previously too bespoke to justify custom software — reading unstructured documents, classifying messy input, drafting from context — is now buildable in weeks. A category of problem that was permanently in the buy column is worth re-examining.

Next insight

Designing for uncertainty

Start a project

A first conversation is a conversation, not a pitch. Bring the problem in whatever shape it is currently in — we will tell you honestly whether we are the right people for it.

Typical first engagement
2–3 weeks
Working model
Embedded, in your tools
Reporting
Weekly demo, monthly review
Handover
Documented, always