The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.
A team asks for custom software because staff keep entering the same customer data into three systems. The duplication is real, but its cause might be unclear ownership, incompatible rules or an integration gap. Paying to code the current workaround into a new platform could make it harder to change later. Decide which part of the workflow genuinely needs bespoke behavior before commissioning a build.
Separate difference from disorder
Map one transaction from start to finish. Which steps are unique to your business and valuable to customers? Which are standard recordkeeping, approvals or notifications? Which exist only because two teams disagree about the source of truth? Custom software can support a distinctive operating model, but it cannot resolve a disputed policy unless someone makes the decision.
Follow the situation
- Agree the true business rule
- Test configuration and integration options
- Build only the justified specialized gap
- No maintenance owner → unresolved build dependency
Test the three practical routes
Compare improving the process and existing tools, buying or configuring a product, and building a custom component. Use the same scenarios for all three, including an exception and a future change. Examine integration, data portability, security, implementation time, ongoing fees and internal support. A platform that covers 80 percent of the journey may still be poor if the missing 20 percent is the business’s differentiator or critical control.
Calculate ownership beyond launch
A custom build entails hosting, monitoring, access management, testing, incident response, documentation and upgrades. A purchased product entails vendor dependency, subscription changes and configuration limits. Neither option is free of maintenance. Ask who will own the product after the agency or vendor finishes and how a new employee will learn the rules.
Compare the next moves
- Configure: Test whether existing tools meet the actual rule.
- Integrate: Connect systems where the gap is a handoff.
- Build: Own custom logic where its value warrants upkeep.
Make a staged decision
Write the smallest decision statement: “We need to reduce duplicate entry in these two handoffs while preserving this approval rule.” Prototype a process change or integration before committing to a platform rebuild. Set a measurable outcome and exit criteria for the trial. If bespoke development remains justified, build around the stable business rule and retain a route to export data and change suppliers.
The next decision
Run one real case through each option, including the exception, and compare the cost of operating it after launch.
Source note: GOV.UK Service Manual, mapping the whole problem. The scenario and proposed allocation, where applicable, are illustrative; the linked source supports the underlying method or regulatory context.
Sources & scope
Related primary reading is provided below. The decision framework and fictional examples are Parikh Advisory’s analysis; these references do not establish that the illustrated events occurred.