Build, buy or compose: deciding what your team should actually write

01The only question that matters first

Does this capability differentiate you competitively? Not whether it is important - authentication is important and does not differentiate anyone. The question is whether a customer would choose you over a competitor because of how this specific thing works.

If the answer is no, the default should be buy or compose, and building requires a specific justification. If the answer is yes, build it, own it properly and resist the temptation to outsource the thing that makes you distinctive. Most organisations get this exactly backwards - they buy their core and build their commodity.

02The real cost of building

Initial construction is typically 30-40% of the ten-year cost of a system. The rest is maintenance, security patching, dependency upgrades, incident response, and the ongoing cost of the knowledge required to keep it running.

That maintenance load is also the thing that consumes senior engineering attention, which is your scarcest resource. A team maintaining six undifferentiated internal systems has meaningfully less capacity for product work than its headcount suggests, and the deficit is invisible on any org chart.

03When buying is genuinely wrong

The build case is not always weak, and the standard objections to buying are sometimes correct. Buying is the wrong answer in a few specific situations that are worth naming clearly, because 'just buy it' is as lazy a default as 'just build it'.

• The capability is your differentiator - then building is the whole point.
• Per-unit pricing that scales with your growth curve into something untenable.
• Data residency or compliance constraints no vendor satisfies.
• A genuinely unusual requirement that every vendor would need to customise heavily.
• The vendor market is immature and consolidating, making lock-in risky.

04Compose: the option teams skip

Between build and buy sits composition - assembling a capability from managed services and writing only the glue and the parts specific to you. This is usually the correct answer for infrastructure-adjacent capability, and it is under-considered because it feels like neither a proper build nor a clean purchase.

Authentication is the clearest example. Building identity from scratch is months of work with real security risk. Buying a monolithic identity product may not fit. Composing on top of a managed identity service, with your own thin layer for domain-specific authorisation logic, gets you both fit and speed.

• Identity: managed authentication plus your own authorisation model.
• Billing: a payments and subscription provider plus your own entitlement logic.
• Search: a managed search service plus your own relevance tuning.
• Data: managed warehouse plus your own transformation layer.

05A decision checklist

Run this before any significant build decision. It takes an hour and regularly prevents six months of work.

• Would a customer switch to us because of how this works? If no, do not build it.
• What is the ten-year cost, not the build cost?
• What does vendor pricing look like at 10x scale?
• Can we compose this from managed services and write only the differentiating part?
• If we build it, who maintains it in three years - and is that person budgeted?
• What happens if the vendor is acquired or shuts down, and how hard is exit?