“We need a custom app” is a conclusion, not a discovery finding. A tailored product may be right when existing services cannot support a real user need or important operational constraint—but custom software also creates ongoing design, security, and support work. This guide helps you evaluate the trade.
Understand the whole user problem
Talk to users and observe the current task, including workarounds and handoffs. Identify who is affected, what outcome they need, and which parts are constrained by policy, data, or other services. Do not define the problem as a feature request until you know why the feature matters. GOV.UK purchasing strategy.
Map the service around the software: people, processes, support, content, and external dependencies. A custom interface does not solve a broken upstream process.
Compare buy, configure, integrate, and build
Evaluate existing products and platforms against essential needs, accessibility, data residency or control, integration, portability, and total cost. Include subscription, implementation, migration, support, security updates, and eventual replacement—not only first-year license or build estimates.
Record gaps that matter to users and gaps that are merely preferences. A configurable product may be sufficient; a custom layer can be justified when it closes a material gap without creating disproportionate maintenance burden.
Prototype the riskiest assumptions
Use discovery and an alpha prototype to test uncertain needs, technical feasibility, and integration boundaries before committing to a full release. Test with representative users and include assistive technology and accessibility considerations early. See also GOV.UK user research in alpha.
Define security requirements proportionate to data and action. Use a verification framework such as OWASP ASVS to turn broad security expectations into testable controls.
Count the long-term ownership
Name who funds hosting, maintenance, support, accessibility, incident response, and product decisions after launch. Identify skills and service levels needed. If no one can own the system after the initial project, a custom build may create a stranded product.
Proceed when evidence shows the service needs a capability existing options cannot responsibly provide and the organization can operate it.
What would you do?
What gap would an off-the-shelf tool need to have before you would justify owning custom software? Share your experience in the comments.
Have a related project in mind? Talk with Acorn.
Share your perspective