Build vs Buy: How to Make the Decision (and Not Regret It)

Build when the capability is part of what makes your business different and no product fits how you need to work. Buy when the problem is common, the product fits most of your needs, and you can live with its limits. Most of the time the honest answer is somewhere in between: buy the commodity parts, build the thin layer that is specific to you, and integrate the two.

The decision usually goes wrong for a simpler reason, though. Teams compare the price of a product against the cost of building a first version, and ignore everything that happens after.

Start with the problem, not the options

Before comparing anything, write down in a few sentences what problem you’re solving and what “solved” looks like. It sounds obvious. In practice, “should we build or buy a CRM?” often turns out to mean “our sales team can’t see which customers have open support tickets”, which might need neither.

There are really four options, not two:

• Build something new.
• Buy a product and adapt how you work to it.
• Integrate what you already have so the systems share data.
• Change the process so the problem goes away, or gets small enough not to matter.

The last two get skipped far too often.

Questions that decide it

Is this part of what makes you different?

If a capability is core to how you compete, like your pricing logic, your credit decisioning, or the workflow your customers pay you for, owning it usually pays off. If it’s something every company needs, like payroll, email, or accounting, someone has already built it better than you will.

How well does the product actually fit?

Not the demo, the fit. Walk through your three most important real workflows in the product, with your data. Note every place you’d need a workaround. A product that fits 80% of what you need can be a great choice. A product that fits 80% on paper and needs custom work for everything that matters is a build project with a subscription attached.

Who owns the data?

Check whether you can get all of your data out, in a usable format, without asking permission. Ask how the product’s data model maps to yours. This is the question people regret not asking when they later try to leave; I wrote about what that migration looks like.

What does it cost over years, not months?

For buying, include licences as you grow, implementation and configuration, integration work, training, and the price of the workarounds.

For building, include the first version, and then the part people forget: maintenance, hosting, security updates, on-call, documentation, and the people who need to stay around who understand it. Software you build is software you own forever.

Can your team maintain what you build?

A system designed around one person’s skills is a risk, not an asset. If the team that will run it doesn’t have the skills today, that belongs in the cost.

How reversible is the decision?

Some choices are easy to walk back and deserve a quick decision. A core platform or data model isn’t one of them. The harder a decision is to reverse, the more time it deserves up front.

When building usually wins

• The capability is a real differentiator.
• No product fits your core workflows without heavy customisation.
• You need control over the data model, performance, or compliance in ways products don’t allow.
• You have, or will hire, a team to own it long term.

When buying usually wins

• The problem is common and well served by mature products.
• Speed matters more than a perfect fit.
• You don’t want to own the maintenance and security of this capability.
• The product’s limits are ones you can genuinely live with.

Write the decision down

Whatever you choose, record it: the problem, the options you considered, why you picked one, and what would make you revisit it. Six months later, when someone asks “why didn’t we just build this?”, you’ll have an answer that isn’t memory. My decision record tool is a quick way to do that.

Build vs buy is one of the most common questions I help with as a solution architect. If you’re stuck on one, here’s how I work.