Build vs Buy Software: A Practical Framework

Build or buy? A decision framework that survives contact with reality2026-07-22 — 7 min readCustom software is usually the more expensive answer, and sometimes the only correct one. Here’s how to tell which situation you’re in before you commit.We’re a custom software shop, and most of the time we tell people to buy something. That’s not modesty, it’s arithmetic. A product with ten thousand customers has absorbed ten thousand customers’ worth of edge cases, and you get all of that for a subscription.But sometimes buying is the expensive answer, and the framework below is how we tell the difference.Start with one questionIs this process a source of competitive advantage, or is it overhead you wish you didn’t have to think about?Buy the overhead. Payroll, accounting, email, CRM, helpdesk. These are solved problems and your version won’t be better. Build the advantage: the thing you do differently from competitors, that customers notice, that you wouldn’t want a competitor to be able to buy off a shelf.Four situations where building wins

The gap is costing measurable money. If a product fits 60% of your workflow and the other 40% is three people re-keying data for ten hours a week, that’s roughly $40,000 a year in salary funding a permanent workaround.

Integration is the actual product. You’ve six systems that don’t talk. Nobody sells "your six systems, connected." That layer is inherently custom.

Vendor lock-in is a strategic risk. Your business depends on a tool whose pricing, roadmap or continued existence you don’t control.

The process IS the differentiator. If how you do the work is why customers choose you, off-the-shelf software will actively erode that by pushing you toward how everyone else works.

Four situations where buying wins

The problem is common. Invoicing is invoicing. Your accounts receivable isn’t special, however much it feels that way.

Compliance is part of the product. Payment processing and payroll tax carry regulatory burden that vendors absorb on your behalf. Taking that in-house is rarely worth it.

You need it next month. Custom takes time. A product takes an afternoon.

Nobody internally can own it. Custom software needs a decision-maker for its whole life, not just its build. Without that person it decays.

The cost comparison people get wrongMost build-vs-buy spreadsheets compare a one-off build cost against a monthly subscription, which flatters the build. The honest comparison includes:

Build: development, plus hosting, plus 15–20% of build cost annually in maintenance, plus the internal time to specify and test it, plus the risk that it takes longer than estimated.

Buy: subscription, plus per-seat growth as you hire, plus configuration and integration work, plus the cost of the workarounds where it doesn’t fit, plus switching cost if you ever leave.

Run both over five years, not one. The answer often reverses somewhere in year three, in whichever direction you didn’t expect.The middle path most people missBuild-or-buy is rarely binary. The best answer is often to buy the commodity parts and build only the thin layer that’s yours: a custom interface over a bought engine, or an integration layer between three products you keep.That approach keeps your maintenance surface small while still fitting how you work. It’s what we recommend more often than either extreme.A sanity check before you commitWhichever way you lean, ask: if this decision is wrong, how much does it cost to reverse? Buying is usually cheaper to undo than building. When the two options look close, pick the reversible one.More reading

What belongs in an MVP, and what founders keep putting in that shouldn’t

What a website costs in Calgary (and what drives the number)

Core Web Vitals, explained for people who don’t write code

Local SEO for Calgary businesses: what moves the needle

Why your most important business process is running on a spreadsheet