Build or buy: deciding when custom software is worth it
Buy anything that is not your differentiator. Build the thing your business is actually good at. The difficulty is that most teams misidentify which is which.
Key takeaways
- Buy everything that is not the reason customers choose you; build only the genuine differentiator.
- Ask whether a customer would notice if the system were replaced with an ordinary equivalent.
- Build costs include indefinite maintenance, key-person risk, opportunity cost and your own compliance liability.
- The winning pattern is buying the platform and building a thin layer of genuinely original logic on top.
Buy software for everything that is not the reason customers choose you. Build the part that is. Accounting, email, payroll, support ticketing and document storage are solved problems where a product will beat anything you build. The workflow that makes your business distinctive is where custom software returns its cost, because no vendor has built it and none will.
The test that resolves most cases
Ask whether a customer would notice if this system were replaced with an ordinary off-the-shelf equivalent. If they would not, buy it. If your competitive position genuinely rests on doing this differently, and you can say specifically how, building is defensible. Teams commonly answer this optimistically about internal processes that are unusual mainly because nobody has questioned them.
The costs people leave out of build
- Maintenance forever. Software you build is software you maintain. Budget a meaningful annual percentage of the build cost indefinitely, not for a couple of years.
- The bus factor. If one person understands it, you have created an operational risk that grows quietly until they leave.
- Opportunity cost. Time spent building a system that already exists commercially is time not spent on the thing customers pay for.
- Compliance and security. A bought product carries certifications and a vendor with an obligation. A built one carries your liability.
The costs people leave out of buy
Per-seat pricing that grows faster than your headcount budget. Integration work, which is frequently larger than the licence. Data lock-in, where extracting your own records is difficult by design. And process distortion, where the team gradually reshapes how it works to fit the tool, which is fine for commodity processes and expensive for the ones that mattered.
The middle path that usually wins
Buy the platform and build the thin layer on top. Use a commercial database, authentication provider, payment gateway and email service, then write only the logic that is genuinely yours. Most successful custom software is ten per cent original code and ninety per cent well-chosen components, and teams that reverse that ratio spend their budget rebuilding solved problems.
The decision to revisit
Both directions expire. A bought tool that no longer fits, or whose pricing has outgrown its value, should be replaced. A built system that has become a commodity, where good products now exist that did not when you started, should be retired in favour of one. Review the significant systems annually and be willing to reverse a decision that was correct three years ago.
Most successful custom software is ten per cent original code and ninety per cent well-chosen components.