Build, Buy, or Integrate

Every product needs capabilities that are not its main point: authentication, payments, email delivery, search, analytics, error tracking. For each one there is a choice. Write it yourself, pay for a product that does it, or integrate a service through an API. Getting this right saves a lot of code you would otherwise maintain forever.

Build when it is genuinely yours

Build the thing when it is part of why customers pick you and when your particular way of doing it is the value. A logistics company probably builds its own routing. It should not build its own email sending. The test is whether a customer would notice, and care, if this part worked like everyone else’s. If not, you are maintaining undifferentiated code.

Buy when the problem is solved and boring

For well-trodden problems, someone sells a mature product that has already handled the edge cases you have not thought of. Payments, transactional email, error tracking, uptime monitoring. The cost is a subscription and some lock-in. The saving is every hour you would spend on compliance, deliverability, retries and the long tail of things that go wrong. For most teams this is the right default for anything outside the core.

Integrate when you need the capability but not the ownership

Sometimes you want a capability in your product but it makes no sense to run it: mapping, address lookup, currency conversion, document conversion. Wire in an API. Keep it behind an interface of your own so your code calls geocode(address) and does not know or care which provider answers. That way, when the provider raises prices or degrades, switching is a contained change rather than a rewrite.

Count the real cost of each

Building looks cheapest because the cost is spread out and invisible: it is the maintenance, the security patches, the person who becomes the only one who understands it. Buying has a clear price but adds dependence on a vendor’s roadmap and pricing. Integrating adds a network call that can fail and an API that can change under you. Put all three on the table with their ongoing costs, not just the upfront ones.

Revisit the decision

A choice that was right at ten customers can be wrong at ten thousand. The bought tool that was fine becomes a bottleneck, or the thing you built as a stopgap is now load-bearing and under-maintained. Once a year, look at the big build, buy and integrate calls and check they still hold.

The short version

Build what makes you different. Buy what is solved and dull. Integrate what you need but should not run. And keep anything external behind your own interface so the decision stays reversible.

Common questions

What is the strongest reason to build?

The capability is core to why customers choose you, and doing it your specific way is part of the value. If it is not that, buying or integrating is usually cheaper over the life of the product.

What is the hidden cost of buying?

Lock-in and the vendor’s roadmap. You inherit their priorities, their pricing changes, and the risk that they get acquired or shut the product.

How do we keep an integration from becoming a liability?

Put it behind your own interface so the rest of your code does not know which provider is behind it. Swapping providers then becomes a contained change.