Build or buy? A checklist for mid-sized companies

Build or buy used to be an easy call for a mid-sized company. Buying was faster and cheaper, building was for banks and airlines. Two things have changed that.

Building got faster. In a controlled experiment, developers using a coding assistant completed a task about 55% faster (Peng et al., in an arXiv review). And buying has a hidden cost that is now well documented: software that doesn't fit gets used by half.

What buying costs that the price doesn't show

• 78% of IT leaders had unexpected charges on usage-based SaaS in the past year. 61% cut projects because SaaS prices rose (Zylo, 2026).
• A box built for an average business forces workarounds. The spreadsheet next to the CRM is a workaround. So is the director who reschedules every lesson personally.

What building costs that the quote doesn't show

• Operations and support take 60 to 80% of the lifetime cost of software (arXiv, 2026). The build is the smaller part.
• Requirements errors found in production cost 100 to 1,000 times more to fix than those found at the start (NASA, 2010).
• Inaccurate requirements were the main cause of failure in 37% of projects (PMI).

So building only pays if someone does the research first and keeps supporting the system after.

What the research says about companies that build

Companies with strong in-house software capability grew revenue four to five times faster than those in the bottom quartile, with 20% higher operating margins (McKinsey Developer Velocity). Companies with their own integrated platform grew 12.4 points above their industry average; those with fragmented systems grew 12.8 points below (MIT CISR, 2025).

Both are correlations. Companies that build their systems grow faster. That doesn't prove they grow faster because they build. It does suggest that the systems a company depends on most are worth owning.

Twelve questions

Answer them for the process you want to fix, not for the company as a whole.

Is the process standard?

1. Would a competitor run this process the same way?
2. Do the vendor's demo screens match what your team actually does?
3. Can you describe the process without "except when"?

Is it what makes you different? 4. Do customers choose you partly because of how you do this? 5. Does the process hold rules your competitors don't know? 6. Would copying it be hard for a competitor?

Can you keep it running? 7. Will the people who build it also support it? 8. Will you own the code and the data, with documentation? 9. Can business users change fields, rules and texts without a developer?

Can you limit the risk? 10. Can a pilot run on real work in days, before the full commitment? 11. Is the first useful version small enough to ship in weeks? 12. Is there a clear exit if it doesn't work?

Mostly yes to 1–3: buy. Mostly yes to 4–6: build, as long as 7–12 are yes too. If 7–12 are no, neither building nor buying will go well. Fix that first.

How we handle 7–12

We run a pilot on real work in days. The system follows in weeks. After that, there are two ways to pay: a subscription that starts after launch and includes support, or a build price where the code is yours. In both cases the data is yours, and we hand over the code and documentation on request. Business users can change fields, rules and prompts without calling us.

For the panel maker in Quoted by hand. Then not., that meant three weeks to production on the client's own server. The ERP stayed.

Related: CPQ software or a quoting system built around your rules? · Buying software without a six-month risk