Most businesses that ask us to build custom software are describing a problem a configured platform already solves. Some are not, and for them custom is the only honest answer. The difference is not about company size or budget. It is about whether your process is genuinely yours or whether it merely feels that way from the inside.
Build custom software when your business rules, roles or integration depth genuinely exceed what platforms model, and you have someone to maintain it. Buy off-the-shelf for anything standard: accounting, CRM, ecommerce, scheduling. Custom in those areas means paying several times more to rebuild a solved problem and inheriting the maintenance.
The question that settles most cases
Is the process you are describing a competitive advantage, or is it just how you happen to do something ordinary? Businesses consistently overestimate how unusual their operations are, because nobody has shown them how a platform would model the same thing.
If two competitors could run the same process on a configured platform without noticing a difference, buy. If the way you price, approve, route or fulfil is genuinely why customers choose you, that is worth building around.
When off-the-shelf wins, decisively
- Accounting, payroll, CRM, scheduling, ecommerce, support. Solved problems with mature products and someone else handling the security patches.
- Anything regulated that you are not expert in. Payroll compliance changes constantly and a vendor absorbing that is worth a great deal.
- Anything where the platform's ecosystem is the point. An integration marketplace you would otherwise rebuild one connector at a time.
The honest maths: a configured platform costs a subscription and some setup. Custom equivalents cost multiples and then keep costing, because dependencies need updating and somebody has to be accountable for that forever.
When custom genuinely wins
- Business rules no platform models. Pricing that depends on six variables, approval chains with real exceptions, dealer hierarchies where who may see whose numbers is the whole problem.
- Integration depth platforms cannot reach. When the answer is repeatedly no third party app does this, the platform has become the constraint rather than the solution.
- The software is the product. If you are selling it, you are building it, and this guide is not really about you.
- A spreadsheet is already running something critical. Frequently the strongest case, because the rules already exist and are already load-bearing. They simply live in a workbook that breaks when two people edit it.
The three situations where building is the expensive mistake
The rules are still being argued internally
If two people in the business disagree about how discounts work, software will not settle it. It will encode whichever version was in the room that day, and then charge you a change request to encode the other one. Settle it on paper first, because changing a document costs a meeting and changing a system costs a project.
Nobody will own it after launch
Custom software needs dependency updates, security patches and an accountable person. Without one it ages faster and more dangerously than a platform, because no vendor is publishing patches for your specific application. This is the failure we see most often, and it shows up in year two rather than year one.
It is being built to avoid a difficult conversation
Occasionally custom software is commissioned because changing how a team works is politically harder than building software around how they already work. That is an expensive way to avoid a meeting, and the resulting system usually encodes the dysfunction permanently.
The middle path most people miss
Configure a platform and build only the piece that is genuinely yours. A standard CRM with a custom quoting engine bolted on. A standard ecommerce platform with bespoke pricing rules behind it. You get the maintained foundation and the differentiated part, which is usually the right answer and rarely the one proposed.
Before anyone quotes a build
Insist on a discovery step that produces a written specification: rules, roles, data model, integrations and edge cases. You keep it regardless of who builds from it, which is what makes competing quotes genuinely comparable and what tells you whether the project is as unusual as it felt. We publish how we scope this on our custom software development page, including the cases where we recommend not building.
Frequently asked questions
When is custom software worth building?
When your business rules, roles or integration depth genuinely exceed what platforms model, and you have someone to maintain it afterwards. Pricing that depends on many variables, approval chains with real exceptions, and dealer hierarchies are common examples. Standard accounting, CRM or ecommerce is not.
Is custom software cheaper than off-the-shelf in the long run?
Rarely. A configured platform costs a subscription and setup, while custom costs multiples upfront and then keeps costing, because dependencies need updating and someone must be accountable forever. The exception is where the platform genuinely cannot do the job at all.
What is the biggest risk with custom software?
Having nobody to own it after launch. Custom software needs dependency updates, security patches and an accountable person, and without one it ages faster and more dangerously than a platform because no vendor publishes patches for your specific application.
Can we combine a platform with custom software?
Yes, and it is usually the right answer. Configure a maintained platform and build only the piece that is genuinely yours, such as a standard CRM with a custom quoting engine behind it. You get the maintained foundation and the differentiated part.
What should happen before anyone quotes a custom build?
A discovery step producing a written specification covering rules, roles, data model, integrations and edge cases. You keep that document regardless of who builds from it, which makes competing quotes comparable and frequently reveals whether the project is as unusual as it felt.