We build custom software, so treat what follows with the appropriate scepticism. But we turn down bespoke projects fairly often, because for most businesses most of the time, buying is the better decision. It is cheaper, faster, already tested by thousands of other users, and someone else is responsible for maintaining it.
Start by assuming you should buy
An established product has absorbed years of edge cases you have not thought of yet. It has documentation, a support team, a community, and a roadmap funded by many customers rather than only you. Matching that from a standing start is expensive and mostly invisible: you pay for it in the year after launch, when the things nobody specified start to matter.
So the honest starting position is that you should buy, and the burden of proof sits with the case for building.
Four conditions that shift the answer
1. Your process is genuinely different, and the difference is the advantage
Not "we do it slightly differently". Most companies believe that and most are wrong. The test is whether the difference is why customers choose you. If your scheduling logic is the reason you can promise something competitors cannot, bending it to fit a standard product destroys the thing you were protecting.
2. Licence costs scale badly against your growth
Per-seat pricing is reasonable at twenty users and can be punishing at three hundred, particularly when most of those users need a fraction of the functionality. Model the licence cost over five years at your projected headcount, not at today's. If that number dwarfs a build, the arithmetic has changed.
3. The integration is the product
Sometimes the requirement is not a new system at all: it is making four existing systems behave as one. No vendor sells that, because the combination is specific to you. This is often the strongest case for custom work, and frequently the cheapest, because you are building connective tissue rather than replacing anything.
4. You are constrained in a way products do not accommodate
Data residency requirements, an isolated network, industry-specific compliance, or hardware that has to be driven directly. These are real, and they genuinely rule out most off-the-shelf options.
Costs both sides consistently forget
Buying is rarely just the subscription. Add configuration, data migration, integration work, training, and the ongoing cost of the workaround your team invents for the one thing the product will not do.
Building is rarely just the build. Add hosting, maintenance, security patching, the cost of changes as your process evolves, and the risk concentrated in whoever understands the codebase. That last one is why we insist on documentation and conventional structure: it is the difference between an asset and a liability.
The middle path people overlook
Buy the commodity parts and build only the differentiator. Use an established accounting package, an established CRM, an established email platform, and build the one system that encodes what makes you different, integrating it with the rest. This is usually cheaper than either extreme and it fails more gracefully, because a problem in one part does not take down everything.
A question worth asking any developer
Ask them to describe the circumstances in which they would tell you not to build. If they cannot answer specifically, they are selling rather than advising.
