# Should you build software or improve what you already have? Improve existing tools when they can support the work. Buy when a standard product fits. Integrate when good tools need to share information. Build custom software when essential requirements remain unmet and you can maintain the result. ## 1. Describe one complete piece of work “We need a dashboard” names a possible solution. It does not explain which decision is difficult today. Choose a real task, such as turning an accepted quote into scheduled work. Record where it begins, the people involved, the information they need and what counts as finished. Follow an ordinary example and one awkward exception. If a quote changes after approval, who updates the schedule? If a customer has two records, which one is used? Exceptions expose requirements that a list of desired features can miss. Avoid sharing customer data unnecessarily when you collect examples. ## 2. Separate process gaps from software gaps Ask whether the work is difficult because the tool cannot support it or because people have no agreed way to use the tool. A missing approval owner will remain missing inside a new application. An unused reporting feature may already answer the question that prompted a proposed dashboard. Write down the smallest change that could address each gap. That might be a clearer responsibility, a different configuration, a connection between tools or a new interface. Keep these options open until you have checked them against real work. - Improve the current setup when the capability exists but the process or configuration needs attention. - Buy an existing product when its standard workflow fits your important requirements. - Integrate tools when each works well but information does not move reliably between them. - Build when important requirements remain unmet and you can support the resulting system. ## 3. Compare the whole commitment Put the options beside the same set of requirements. Include permissions, exports, reporting, data quality and the awkward exception you identified. Mark each requirement as essential, useful or optional. A long feature list should not outweigh one essential capability that is missing. Then compare the cost of adoption and ownership. An existing product can require migration, training and paid connectors. A custom application requires maintenance, hosting and someone responsible for failures. Include the effort of operating workarounds, but label estimates as estimates rather than presenting guessed savings as a business case. ## 4. Test the riskiest assumption first Choose a small trial that could change the decision. If integration access is uncertain, check that the required information can be read and updated. If usability is uncertain, walk through a prototype with the people who do the task. If an existing product looks suitable, use representative records rather than relying on a vendor demonstration. Set a clear exit condition. For example: a coordinator can find an approved request, assign it and recognise an incomplete record without a separate spreadsheet. This is an illustrative acceptance check, not a universal success measure. Include failure and recovery, not only the smooth path. ## 5. Decide what happens after the first release Before choosing, name the person who will own the process and the person or partner who will maintain the technology. Agree how access is removed, how important data can be exported and what happens if the supplier or developer changes. Write a short decision record: the need, options considered, evidence from the trial, unresolved risks and the next commitment. A sensible first decision may be to improve one existing workflow and revisit custom software later. If you need help, bring that record and a few representative examples; a finished technical specification is not necessary. ## A decision record keeps the work honest Record the problem in the language of the people doing the work, the evidence you reviewed, the options you ruled in or out and the next test. This gives a future developer or supplier the reasoning behind the scope instead of only a feature list. Review the record when conditions change. A new volume of work, a different approval rule or a platform limitation can change the right answer. Good software decisions stay understandable after the original meeting has ended. ## Worked example: a quote-to-job handover Consider an illustrative service business that records quotes in a CRM and schedules work in a shared spreadsheet. Staff copy accepted quotes into the schedule. The initial request is for a new operations application, but the decision depends on why the handover fails. If the CRM already supports the required scheduling and permissions, trial that feature first. If a scheduling product handles ordinary jobs well, check whether it can receive approved quote details through a supported connection. A custom application becomes a candidate when essential rules, such as several linked visits with separate approvals, cannot be represented reliably in either tool. Use the same cases to compare each option: an ordinary job, a changed quote, a cancelled job and a duplicate customer. Ask a coordinator to complete them without developer help. Record where they need a workaround and whether the resulting information is correct. This tests operating fit before committing to a build; it does not establish a savings figure. ## Questions to take into a supplier conversation Ask for the assumptions behind the proposed scope, not just the feature list. An answer that depends on a supplier API or clean historical data should say so. Keep responsibilities for licences, migration, testing and future maintenance visible in the comparison. - Which essential requirements can you demonstrate using our representative examples? - What happens when a connection fails or someone repeats an action? - Can we export our data in a usable form, including relationships between records? - Who owns the accounts and code, and what documentation will we receive? - What would make you recommend a smaller scope or an existing product instead? Canonical: https://aykaai.in/insights/custom-software-or-existing-tools Published: 2026-10-01 Updated: 2026-10-02 Author: [AyKa](https://aykaai.in/about) ## Sources and further reading - [GOV.UK Service Manual: choosing technology](https://www.gov.uk/service-manual/technology/choosing-technology-an-introduction): Guidance on understanding needs, considering existing technology and planning ownership; written for public services, with useful decision principles for business teams.