Custom software is worth considering when an important business process cannot be handled well by the tools already available. That does not mean every unusual spreadsheet deserves its own application. Sometimes the best investment is configuring an existing product, connecting two systems, or simplifying a process before writing any code.
The useful question is not whether custom software is better than off-the-shelf software in general. It is which approach will support your actual work at an acceptable cost, with manageable risks and somebody responsible for keeping it running. A good decision compares the whole working system, including the people, data, integrations, and support it needs.
Compare four approaches, not just two
Business software rarely fits neatly into a choice between a sealed product and an application built from scratch. Consider these options before commissioning a replacement:
| Approach | When to investigate it | What to verify |
|---|---|---|
| Buy | An established product already handles the essential workflow | Actual task fit, pricing limits, data export, and support |
| Configure | The product can support the process through settings, fields, rules, or extensions | Configuration limits and what happens during upgrades |
| Connect | Existing systems work well individually, but staff repeat work between them | API access, data ownership, synchronization, and failure handling |
| Build | A valuable workflow needs behavior the available options cannot reasonably provide | Scope, delivery evidence, maintenance capacity, and handover |
A hybrid can be the right answer. For example, a business might keep its accounting platform and build a small operations portal around a specialized approval process. That avoids recreating a system that already works while addressing the part that causes trouble. It also creates an integration that somebody must maintain.
Find the expensive friction in the current process
Start with a recent real job, order, or customer request. Follow it from arrival to completion. Record where people retype information, wait for approval, search through messages, or correct mismatched records. Include the exceptions: cancelled jobs, partial deliveries, missing documents, and requests that arrive twice.
Suppose a small equipment service company uses scheduling software, accounting software, and a shared spreadsheet for inspection approvals. Scheduling and invoicing work well. The recurring problem is that supervisors cannot see which inspections are waiting, and staff manually copy an approval into two places.
Replacing everything would be a large response to a more specific problem. The first investigation should be whether existing tools can represent the approval and share its status. If they cannot, a focused approval application may be a better candidate than a complete business management system. This is a hypothetical example, not a promised result or a claim about a particular product.
Separate essential behavior from preferences
- Essential: An authorized supervisor can approve an inspection, and the decision is associated with the correct job.
- Essential: A failed synchronization is visible and can be retried without creating duplicate records.
- Useful: Supervisors can filter the queue by location or due date.
- Preference: The approval screen resembles the existing spreadsheet.
This distinction prevents a familiar screen layout from becoming the reason for an expensive custom build. It also gives suppliers something concrete to demonstrate. A product either supports the required task under the agreed conditions or needs a documented workaround.
Compare total operating cost over the same period
A subscription price and a development estimate are different pieces of a budget. Choose a planning period, such as three years, and compare complete scenarios over that same period. Include the following wherever they apply:
- Discovery, configuration, development, and implementation assistance.
- Data cleanup, migration, reconciliation, and staff training.
- Subscriptions, user tiers, usage charges, hosting, and third-party services.
- Integrations and changes required when either connected system changes.
- Support, security updates, backups, recovery testing, and ongoing improvements.
- Staff time spent on workarounds, and the cost of an eventual transition.
Ask what each estimate excludes. Does the quoted subscription include the API access you need? Does the development estimate include importing old records? Who pays for a new report, a changed business rule, or support outside normal hours? Use written assumptions so a lower price does not quietly represent a smaller solution.
GOV.UK's technology selection guidance emphasizes total cost of ownership, existing systems, and the ability to adapt. Although written for public services, those evaluation principles are useful for a smaller business too. Treat estimates as scenarios to investigate, not a guarantee that either buying or building will be cheaper.
Prove the integration before trusting the demo
A feature list that says "integrates with your system" leaves important questions unanswered. Which records can move, in which direction, and how quickly? Can an integration create an invoice but not update its status? Does access require another subscription tier? Who resolves a conflict when two people change the same information?
For the inspection example, test a small complete flow: select a job, record an approval, transfer the result, and confirm it appears against the right record. Then interrupt the connection and retry it. Inspect the result in both systems. A successful demonstration of the normal path is useful, but it does not establish how the integration behaves when something goes wrong.
Agree on a source of truth for each important type of information. Customer details may belong in one system while inspection decisions belong in another. Avoid making every system equally authoritative unless you have a clear method for resolving disagreements. Keep a manual recovery path for the business tasks that cannot simply wait.
Ask who will own the work after launch
With a purchased product, ask about support channels, response expectations, release notices, and end-of-service arrangements. With a custom application, ask who will monitor it, fix defects, update dependencies, and help the next developer understand it. Either option can leave a business dependent on knowledge held by one supplier or employee.
For commissioned work, make source access, permitted use, third-party components, hosting accounts, documentation, and handover deliverables explicit in the project agreement. Do not assume that paying for development automatically gives you every right or account you may need. A practical handover should include enough information for an appropriately skilled replacement maintainer to build, deploy, and operate the application.
Make the exit test concrete
Ask to see an export of representative records, including attachments and the relationships between them. A CSV of customer names is not a complete exit if job history, documents, and approval records remain inaccessible. Check the format, completeness, effort, and any charges involved in moving the data.
GOV.UK's guidance on managing technical lock-in treats portability as a tradeoff to evaluate, rather than something every service can eliminate. Its advice to assess switching costs and data formats is relevant when choosing hosted software. Custom software also has dependencies, including its hosting services, frameworks, integrations, and available maintainers.
Evaluate security and usability in either option
Neither a custom build nor a familiar vendor name is sufficient evidence of security. Ask about access permissions, account removal, data protection, backups, incident handling, and vulnerability updates. Request evidence appropriate to the information and operations the application will handle.
NIST's Secure Software Development Framework provides a vocabulary for discussing secure development with suppliers. Use it to make the conversation more specific: how are changes reviewed, how are vulnerabilities addressed, and who is responsible after release? A claim that security is included should lead to clear practices and responsibilities.
Have the intended users complete realistic tasks before committing to a rollout. Include keyboard use, enlarged text, understandable validation messages, and relevant assistive technology. W3C's accessibility evaluation guidance explains why automated tools need knowledgeable human evaluation. A polished demonstration is not a substitute for people successfully doing their work.
Make a small, evidence-based decision
Prepare a short brief describing the current process, the essential tasks, the systems involved, and the consequences of failure. Ask each candidate approach to demonstrate the same representative workflow. Record what worked, what needed a workaround, what remains uncertain, and who would own the unresolved work.
- Can an existing product handle the essential task with reasonable configuration?
- Could a focused integration remove the main source of repeated work?
- If a custom build is needed, what is the smallest complete workflow worth releasing?
- Are the full costs, support responsibilities, and handover expectations understood?
- What evidence would justify expanding the solution after its first release?
For a build that survives that comparison, the software development life cycle provides a practical framework for requirements, testing, release, and maintenance. If the main issue is repeated handoffs, explore workflow automation before replacing a working application. Bring the process and its awkward exceptions to the discussion; that is where a useful software brief begins.