Every growing company eventually hits the same fork in the road. Someone in a leadership meeting says, "None of the software out there does what we do — we should build our own." Someone else says, "We're not a software company." Both people are partly right, and the argument usually gets settled by whoever is more persuasive rather than by anything resembling analysis.
The reason the debate goes in circles is that it's framed too broadly. "Should we build custom software?" is unanswerable. "Which parts of our operation deserve custom software?" is a question you can actually work through in an afternoon.
Break the Business Into Parts First
Your operation is not one system. It's a stack of jobs: recording a sale, tracking inventory, invoicing, paying people, scheduling work, managing customer relationships, quoting, reporting. Some of those jobs are identical to what thousands of other companies do. A few of them are the reason customers choose you.
Invoicing is not your competitive advantage. Neither is payroll, general ledger, or expense approvals. These are solved problems with mature products behind them, and every hour your team spends reinventing them is an hour not spent on the thing you're actually good at.
But somewhere in your business there's a workflow that is genuinely yours — a way you price complex jobs, a routing logic that keeps your crews efficient, a quality process customers pay a premium for. That's where custom work earns its keep, because that's where off-the-shelf software forces you to change how you operate in order to fit the tool.
Three Tests Worth Running
For each major job in your business, ask three questions:
- Does a customer notice? If the process is invisible to customers and only affects internal bookkeeping, buy it. If your handling of it is part of why customers stay, consider building.
- How often does it change? Processes that shift every quarter as you learn are painful to hard-code. Processes that have been stable for years are safer candidates for custom work.
- Is there a mature market for it? Where dozens of credible vendors compete, buying is cheap and switching is possible. Where the only options are thin or abandoned, you may not have a real choice.
Run those three questions across your operation and the answer usually stops being philosophical. Most of the list says buy. A short list says build. That short list is where your engineering budget belongs.
Count the Real Costs on Both Sides
Buying looks cheaper than it is. The license is the smallest line item. The real cost is configuration, data migration, integration with everything else you run, and the months of adoption work it takes before people trust the new system. Companies that treat a software purchase as a purchase — rather than a project — are the ones who end up with expensive licenses and staff still working in spreadsheets.
Building looks cheaper than it is too, but the bill arrives later. Year one is exciting: the tool fits perfectly, the team loves it. Year two is when you discover that custom software is a permanent obligation. Someone has to patch dependencies, respond when it breaks on a Saturday, document how it works, and rebuild the parts that the original developer understood but never wrote down. If one person is the only one who can safely change it, you haven't built an asset — you've built a liability with a good user interface.
The Answer Is Usually Both
In practice, the strongest setups we see aren't purely bought or purely built. They're a mature platform handling the standard work, configured properly rather than bent into strange shapes, with targeted custom extensions covering the workflows that make the business distinctive.
This is why platforms with real extensibility matter. An ERP like Odoo can carry accounting, inventory, purchasing, and CRM as configured modules, while your genuinely unique process lives in a custom module alongside them — sharing the same data, the same permissions, the same reporting. You get the leverage of bought software and the fit of built software without maintaining two disconnected worlds.
The same logic drives how we approach a Business Hub: don't rebuild the tools your team already relies on. Build the thin layer that unifies them, so people work in one place and data stops living in five.
Decide Deliberately, Then Revisit
Write your buy-vs-build decisions down, including the reasoning. Businesses change. A workflow that was your edge three years ago may now be a commodity that a vendor handles better than your internal tool does. Revisit the list annually and be willing to retire custom code you were once proud of.
The goal was never to build software. It was to run a business that scales without depending on heroics. Buy the boring parts. Build the edge. Maintain the discipline to know which is which.
If you're weighing a custom build against a platform right now — or maintaining something homegrown that's become a burden — we'd be glad to talk it through with you.