Build vs buy vs integrate: the decision that can save six months of development.

The most expensive feature is sometimes the one your team proudly built even though a mature product already solved 90% of the problem.

Not everything deserves your code

Engineering teams enjoy building. That is useful right up until the company spends four months rebuilding something standard that no customer will ever notice.

Authentication, payments, email delivery, analytics, file storage, video, maps, search and CRM all have mature products on the shelf. The answer is not automatically ‘buy.’ The question is whether owning that piece buys enough advantage to be worth what it costs over its whole life.

Ask whether it is part of your moat

Your moat is whatever makes customers choose you over the alternatives. If a capability sits at the centre of that, building it may make sense. A trading platform may need its own order-execution logic. A healthcare product may need a specialised clinical workflow. A marketplace may win on how well it matches buyers to sellers.

But customers rarely choose a product because the team wrote its own password reset emails.

Calculate lifetime cost, not initial build

Building creates ongoing work: security updates, edge cases, monitoring, support, compliance changes, documentation, migrations and maintenance by people who did not write version one.

Buying costs a subscription and makes you dependent on somebody else’s roadmap. Integrating means glue code to maintain and one more system that can fail at 2 a.m. Compare all three over years, not just against the first estimate.

Integration is often the real middle path

Many teams treat build and buy as opposites. In practice, the best answer is often to buy infrastructure and build the layer that makes it yours.

Use a payment provider, but own your pricing rules and the way payments are matched to invoices. Use a login provider, but own permissions and onboarding. Use someone else’s AI model, but own the workflow around it: what information it sees, how you check its answers and how it feels to use.

Know the lock-in you are accepting

Every outside platform makes it harder to leave later. That is not automatically bad. The question is whether the cost of leaving matches the value you get while you stay.

When switching is likely, or would be painful, keep the vendor behind a thin layer of your own code. Do not build a 12-layer abstraction around a service you are perfectly happy to use for the next five years just to feel architecturally pure.

Your customers do not award bonus points because you wrote your own email-delivery system.

Use a simple decision test

Then make the decision explicit. The worst outcome is accidentally building a platform because nobody paused to ask whether the company wanted to own one.

Spend custom engineering where customers notice

The goal is not to minimise code. It is to spend engineering attention where it creates value. Buy boring infrastructure when it is good enough. Integrate deliberately. Build the parts that make the product worth choosing.