Choosing between custom software and an off-the-shelf product starts with understanding the work. A familiar tool can be a good choice when it supports the process with little compromise. Custom development becomes worth investigating when a distinctive, important workflow repeatedly breaks across the available options.
There is also a third option: keep the standard product and build the connection or small application it is missing. Compare all three before committing to a full replacement.
Describe one working day before writing a feature list
Take a real task from arrival to completion. For a maintenance business, that might mean receiving a request, checking the service contract, assigning a technician, collecting evidence, and preparing an invoice. Note which person acts, which information they need, and what happens when a visit must be rescheduled.
Now identify the non-negotiable rules. Perhaps a technician must work offline, a customer has several sites, or the invoice needs approval from a different department. These are stronger evaluation criteria than a long list of features copied from product websites.
Separate genuine business constraints from habits. A spreadsheet column that nobody uses is not a requirement simply because it exists today. Ask what would go wrong if each proposed feature were missing.
Compare three credible options
Use the same workflow to assess each approach:
| Approach | A useful situation | What to examine closely |
|---|---|---|
| Standard product | The core workflow matches a common business need | Plan limits, configuration, data export and team adoption |
| Product plus integration | The main system works, but information gets stuck between tools | API access, error recovery and ownership of each record |
| Custom application | An important workflow needs behaviour available products cannot reasonably provide | Delivery scope, maintenance, security and a clear product owner |
For the maintenance example, a standard scheduling system may already handle visits well. A small customer portal could provide the missing approval step. Replacing scheduling, invoicing, and customer records at once would add decisions that the original problem did not require.
This is consistent with the UK Government’s purchasing guidance, which considers buying, building, and combined approaches against user needs and the capability to manage the result. The relevant question for a business is whether it can operate and improve the chosen solution after launch.
Compare the full cost of keeping it useful
Choose a common planning period, such as three years, and write down the assumptions. Include licenses, implementation, migration, training, integrations, hosting, support, and expected changes. Add the internal time needed from the people who understand the process.
For subscription software, test what happens when users or usage increase. For custom software, budget for dependencies, security updates, backups, and ongoing development. For an integration, account for changes at either end of the connection.
Do not present a spreadsheet estimate as a promised saving. Use a reasonable range and identify which assumption changes the decision most. If the answer depends on doubling sales, evaluate what happens if sales stay flat.
Test the exit before signing
Ask to export a small, representative dataset. Check whether relationships, attachments, history, and identifiers remain usable outside the product. A CSV containing customer names may be inadequate if the business also needs linked orders and service records.
Ask who controls the source code, hosting account, documentation, and administrative access for a custom build. Record the handover arrangement. Government Digital Service guidance on open standards explains their role in interoperability and reducing dependence on one supplier. In practice, test the actual export and integration rather than relying on a compatibility claim.
Run a narrow trial with difficult examples
Choose a small set of real scenarios, with permission to use the data or with anonymised copies. Include a normal job, a cancellation, a duplicate, an incomplete request, and a permissions edge case. Ask the people who will use the system to complete them.
Measure completion time, manual workarounds, and unanswered questions. A polished demonstration cannot tell you how the system behaves when a customer changes their mind halfway through a job.
If your biggest problem is moving information between existing tools, start with the first business automation guide. If several essential rules still cannot be supported, define a small custom release around those rules.
Write the decision in one page: problem, options tested, expected cost range, unresolved risks, and owner. That gives the team a useful basis for choosing software and a record to revisit when the business changes.