Build vs buy: how to decide

Build versus buy is not a technology question. It is a question about which parts of your product are your actual differentiation, and which parts are a solved problem you would be reinventing badly. Answer that first, and whether to build in-house, buy off-the-shelf, or bring in a vendor mostly decides itself.

The three real options, and why two of them get confused

Every version of this decision reduces to three options, though the middle one wears a lot of disguises:

• Build. Custom software, written and owned by your own team.
• Buy. A mature, off-the-shelf product you configure rather than construct.
• Vendor, or outsource. Custom software again, built to your specification, just not by people on your payroll.

The confusion sits between buy and outsource. Both feel like "someone else builds it," but they are opposite trades. Buying gets you a solved problem with no engineering effort and someone else's roadmap. Outsourcing gets you exactly your own requirements, built by hands that are not on your payroll, with the ownership question below still wide open.

The one question that actually decides it

Before any spreadsheet of costs, ask one thing: is this your differentiation, or a solved problem?

• If it is not why a customer picks you, buying it is usually right. The category is mature, and someone has already spent years hardening the edge cases you would rediscover the hard way.
• If it is core to the product, and no off-the-shelf tool bends far enough to fit it, building is right, whether that means your own team or a vendor building it precisely to your spec.

When buying off-the-shelf is the right call

• The category is mature and boring: authentication, payments, email delivery, a CRM. Someone has already spent years on the edge cases.
• Time matters more than customisation. You need it running this quarter, not after a build cycle.
• The true total cost of buying, licence plus integration, is lower than the true cost of building and maintaining the equivalent forever.

When building in-house is the right call

I have made this call with real money on the table, not just in a workshop. At Yicom, development started outsourced to a dev shop. The first version of that decision was wrong: the shop built exactly what I specified and owned none of the judgment about whether it should be built that way. I pulled development in-house, went remote-first across a team hired across ASEAN, and the switch cut hiring costs by 70%. The lesson was not "never outsource." It was that a vendor with nobody senior directing it and checking its work is a riskier bet than it looks on the pitch deck.

If the reason you are asking this question is that a team you already have ships slowly, the fix is not always a rebuild. Start with an audit before deciding whether to build, buy, or replace anything. A team that ships slowly because of process, not architecture, does not need a build-versus-buy decision at all. It needs the process fixed.

The cost most people forget to price

Every version of this decision gets distorted by comparing the wrong numbers: a vendor's quote against an engineer's monthly salary, or a SaaS licence against a rough guess at build time. Neither comparison is honest. The real cost of buying includes integration, the data you do not fully control, and the switching cost the day the tool stops fitting. The real cost of building includes not just the first version, but every year of maintaining, patching, and re-architecting it as the product changes around it. The real cost of outsourcing includes the ongoing cost of someone senior checking the vendor's work, which is real labour even when it is not on an invoice.

Price all three honestly, over three years, not the first three months, and the sticker price stops being the deciding factor. It rarely is, once the full picture is on the table.

The trap in the middle: outsourcing without ownership

The riskiest version of this decision is not build or buy. It is outsourcing without anyone on your side owning the decision. An agency builds what you specify and has little incentive to tell you the specification is wrong. If you cannot name the person on your side checking what a vendor ships, you have not actually decided to outsource. You have decided to hope. That is the vendor-management work I do as part of the standing advisory seat, whichever of the three options a client ends up choosing.

How I run this decision with clients

The same way as any diagnostic. I look at what is actually core to the business, price the real total cost of each option rather than the sticker price, and give a written recommendation, not a slide deck built to justify a bigger engagement. Sometimes the honest answer is build, and I build it myself, hands on the keyboard. Often it is buy, or outsource with someone accountable watching it, and the job is to make sure that someone exists.

This tends to come up at two moments: a founder scoping a first product who does not want to over-build before the idea is proven, and an SME leader who has been burned once by a vendor and wants a second opinion before it happens again. Either way, the framework is the same three questions, answered honestly, before any money moves.