Off-the-Shelf or Custom Software? A Decision Framework
When custom software, when a package?
If your process does not differ from common industry practice, and that difference produces no competitive advantage, a packaged product is the right choice. Custom software makes sense when the process genuinely differs, when you have reached the configuration limit of a package, or when the data and business rules must stay in a system you control. The decision is not a feature comparison but a joint assessment of four criteria.
Four decision criteria
- Process differentiation: is this workflow the same as your competitors'? If so, custom development simply reproduces a solved problem.
- Rate of change: does the rule change once a year or once a month? Frequently changing rules turn into repeated change requests and waiting time in a packaged product.
- Data ownership: where will the data live, in which format and within what time can it be exported?
- Handover risk: if the team that built the software changes, can another team take it over?
If fewer than two of the four point to custom software, configuring a package usually gives a lower total cost.
A hybrid model is often the right answer
The structure that works most often is a packaged product for standard areas such as accounting and inventory, custom development for the differentiating area ([dealer portal](/en/blog/b2b-dealer-portal-guide), [field application](/en/blog/field-sales-tracking-guide), production monitoring, customer portal), and an API contract between them. The critical point in this model is that contract: which record is authoritative in which system, which side wins on conflict, and which key is used for matching.
Write handover into the contract
The biggest risk in custom software is not technology but a knowledge monopoly. Ask for the source repository and access rights before the project ends, an installation document with working setup steps, the database schema and a field dictionary, environment variables with the list of third-party services and dependency versions — and require that a new developer actually sets up the environment from scratch once. That last item matters most: documentation is only proven correct by being followed.
Three measurements that keep technical debt visible
- Environment setup time: how long does a new developer need to run the project for the first time?
- Change lead time: how many days does a small business-rule change take from request to production?
- Rollback rate: what share of released changes is reverted because of defects?
If these three numbers are rising, the problem is architecture and test coverage, not team speed.
Frequently asked questions
Who should own the source code?
This is a contract clause, not a default. Ownership, right of use and third-party component licences should be written separately, and open-source licence types should be listed.
How is security verified in custom software?
Add an acceptance checklist covering authentication, authorisation, session management, input validation and logging. OWASP ASVS provides this as a ready framework and lets you scale the scope by choosing a level.
Can a small team maintain custom software?
Sustainability depends on automation more than team size. With automated tests, one-command setup and repeatable deployment a small team is enough; without them a large team is not.