Prefer an existing product when the process is standard
A product is attractive when the workflow is common, the required controls already exist and the organisation can adapt its process. Mature products may provide security updates, integrations, support and documentation that would be expensive to reproduce.
Test the real workflow during evaluation rather than scoring feature names. Confirm permissions, exports, data limits, audit history, language needs and how exceptions are handled. Configuration effort and staff workarounds belong in the purchase decision.
- Common process with limited differentiation
- Acceptable fit without extensive workarounds
- Required data export and account control
- Vendor support and change path are credible
Consider custom software when the workflow is distinctive
A custom application can be justified when the process is stable, materially important and poorly served by available products. It can express specific roles, records and decisions without forcing the business through unused product features.
Custom does not mean unlimited. The organisation accepts responsibility for prioritisation, testing, security, hosting and future changes. If no operational owner can make decisions, custom development will turn uncertainty into costly revisions.
- Distinct process with clear business importance
- Stable rules and accountable owner
- Integration or permission needs products cannot meet
- Commitment to maintenance and governance
Compare the full operating model
Use the same scenario in every option: create a record, assign it, request approval, handle an exception, report status, export data and remove a user's access. Record how much configuration, manual work and training each option requires.
Calculate costs over a defined period and state assumptions. Include licences, implementation, migration, integrations, internal administration, support, upgrades, change requests and exit. Avoid false precision where user numbers or scope are uncertain.
- Workflow fit and exception handling
- Permissions, audit and compliance needs
- Implementation and internal operating effort
- Data portability and exit route
Choose a reversible first step
Before contracting, validate the riskiest assumption. For a product, configure a realistic trial with representative users and data. For a build, prototype the critical screens and test whether the proposed records and decisions match actual work.
Document the decision, rejected alternatives, dependencies and a review point. A hybrid may be strongest: retain a system of record and build a focused interface or integration around the part that makes the organisation different.
- Highest-risk assumption to test
- Representative users and scenarios
- Decision owner and deadline
- Conditions that would change the choice
Frequently asked questions
Frequently asked questions
Is custom software always more expensive than a subscription?
Not necessarily, but comparisons must include implementation, internal administration, integrations, change and exit costs. Both options can become expensive when process fit is poor.
Should we copy our current spreadsheet exactly into an app?
No. Preserve the information and controls that matter, then redesign steps that exist only because the spreadsheet lacks roles, workflow or validation.
Can we buy a product now and build later?
Yes, if data can be exported and the implementation avoids unnecessary lock-in. Record what would trigger a later change before the immediate choice becomes permanent by default.