Bespoke systems
When does bespoke software make sense for a growing business?
Build when a recurring, important part of your work cannot be served sensibly by a product or a small connection between products. Do not build merely because the current process is untidy.
Published 25 September 2026
A growing firm has a reliable accounting product, but approvals take place in private email before a transaction reaches it.
Replacing the accounting product would move a stable core. A focused approval workflow, with a clear record and an integration to the existing product, may address the actual gap. Test the awkward approvals before committing.
Software becomes painful when work falls between systems: an approval happens by email, a customer status is retyped or a specialist decision has no place to be recorded. A custom application can solve such problems. It can also turn a fixable process into a permanent software obligation.
Use a product for work that is not distinctive
Accounting, scheduling, email and basic customer records are usually better served by maintained products. Test whether configuration can support the important cases. A product may require the business to change a familiar habit; that is acceptable if the habit does not protect a meaningful difference.
Do not mistake an impressive feature list for fit. Test the case that causes the most work, the exception that carries the most risk and the information that must move between teams.
Build around a material difference
A tailored layer earns its place when the same consequential work repeatedly escapes standard tools: a distinctive approval, a complex hand-off, a client experience that depends on several systems, or information that must be assembled and checked before a decision.
That layer might be a small internal workflow or integration rather than a replacement platform. Specify which existing systems remain authoritative and what the custom component is allowed to change.
Buy the operating life, not just the first release
Someone must maintain access, security, integrations, data quality and the rules embedded in custom software. Ask who owns each responsibility, how errors are corrected and whether another team could maintain the system if the original builder leaves.
Before commissioning anything, follow one ordinary case and one difficult case from start to finish. The right answer may be to simplify the process, configure a product, connect two systems or build. The evidence should choose; enthusiasm for bespoke work should not.