Somebody asks us this question roughly once a fortnight, usually already leaning one way and looking for permission. So here is the framework we actually use, which is less about features than about how weird your process is.
Start with how unusual your workflow really is
Buy the product when your process looks like everyone else’s process. Payroll, accounting, email, CRM for a normal sales pipeline. Thousands of companies do these the same way and somebody has already built a better version than you would commission.
Build when the process is the thing that makes you money. If your scheduling logic is why customers pick you, forcing it into a package that assumes a different shape will cost you the advantage you were protecting.
Most companies are ninety per cent normal and ten per cent strange. The trick is being honest about which ten per cent, because everybody believes their whole operation is unique and almost nobody is right.
The real cost of off the shelf is configuration
Licence fees are the visible part. Underneath sits implementation, data migration, training, and the ongoing tax of working around the two things the product will not do.
That last one compounds. A workaround becomes a habit, the habit becomes a job, and three years later somebody is employed part time to move data between two screens. We have found that exact arrangement in four companies.
The real cost of custom is the second year
Custom software is cheap to build and expensive to neglect. The build is a known number. What people forget is that in year two somebody has to update dependencies, fix the thing that broke when a browser changed, and add the feature that was obvious only after people started using it.
Budget fifteen to twenty per cent of the build cost annually for that, and if nobody quoting you mentions it, ask why.
A middle path that gets ignored
Buy the platform and build the strange ten per cent as an integration around it. Keep the accounting package, build the small tool that does the odd job, connect them.
This is what we end up recommending most often. It is less satisfying than either pure answer and it usually costs the least over five years.
Questions that settle it quickly
Would you be comfortable if a competitor used the identical system? If yes, buy it. Your advantage is not in there.
Has anyone actually run the trial with your real data, or only watched a demo? Demos are built to avoid the parts where your data is messy.
If the vendor doubled the price in three years, could you leave? If not, you are buying a relationship rather than a product, and that should change the price you are willing to pay.
Can you export everything, in a format somebody else could read? Ask for a sample export during the trial rather than a promise.
What we tell people who are stuck
Try the packaged option first, seriously, with your own data and for at least three weeks. Most of the time it works and you have saved a large amount of money.
When it does not work, you will know exactly which part failed, and that description is the specification for the small thing you build instead. It is a much better starting point than an idea about what you want.