Build vs buy: how to decide before you spend the budget

Almost every software decision is really this one: build it, buy it, or configure something that already exists. Get it right and you spend money where it creates advantage. Get it wrong and you either reinvent a commodity or bend your business around a tool that doesn't fit.

Start with the real question

It isn't “can we build this?” — you almost always can. It's “is this a source of competitive advantage, or is it plumbing?” Build the parts of your operation that make you different. Buy the parts every business needs and no customer will ever thank you for.

A scoring framework

Score build, buy and configure against each of the following. Weight them for your situation — a regulated business weighs risk and control heavily; an early-stage startup weighs time-to-value.

Total cost of ownership

Not the sticker price. For buy: licences or per-seat fees that grow with you, implementation, integration, and the cost of working around gaps. For build: the project, plus 15–25% of that per year in maintenance, plus the opportunity cost of the team not building something else.

Fit

How much of what you need does each option cover out of the box? Be honest about the 20% that doesn't fit — that's where projects die. A product at 70% fit that you can extend often beats one at 90% fit that you can't.

Time to value

Buying is usually live in weeks. Configuring a platform is weeks to a few months. Building is months. If the need is urgent, that gap alone can decide it — you can buy now and build later.

Risk

Buy risk: the vendor raises prices, gets acquired, sunsets the product, or can't move fast enough for you. Build risk: it costs more and takes longer than planned, and the knowledge lives in a few people's heads. Name the specific risks; don't hand-wave them.

Control and data

Building means you own the roadmap, the data model and the integrations. Buying means you live within someone else's. If a capability needs to change often as your business learns, control has real value. If it's stable and standard, control is overhead.

Integration

Whatever you choose has to talk to the rest of your stack. A bought tool with a good API can beat a built one with none. A built system integrates on your terms, but you own every connector.

When build usually wins

• The capability is how you differentiate — the thing customers choose you for.
• Your process genuinely doesn't match how any product on the market works, and that difference matters.
• You need to change it frequently as you learn.
• The data is too sensitive or too core to sit in a third party.

When buy usually wins

• It's a solved problem — payroll, helpdesk, CRM, email, analytics, authentication.
• Speed matters more than a perfect fit.
• You don't have the team to maintain it for years.
• A mature product exists, with a healthy vendor and a real API.

The option people skip: configure and extend

Most modern platforms sit between build and buy — you configure workflows, fields and rules, and add a small custom layer for the parts that are genuinely yours. You get most of the speed of buying and most of the fit of building. It's often the right answer, and it's the one that gets left off the list.

Common mistakes

• Underestimating maintenance. The build cost is the deposit; the annual maintenance is the mortgage.
• Building undifferentiated features because “we can”.
• Comparing sticker price to project price instead of total cost of ownership over three years.
• Ignoring the 20% that doesn't fit until it's a live problem.
• Treating it as permanent. Buy now; build the differentiated piece when it's proven.