Bespoke systems · JNAGA perspective
When should you configure a product rather than customise it?
A product can often be shaped to fit, but every departure from its normal path creates something the business must understand and maintain.
Published 25 September 2026
Ask why the difference exists
A requested feature may express a genuine service need, or it may preserve an old workaround. Observe the work and separate the outcome from the current interface. If the product's ordinary configuration can serve the outcome, it is often easier to support and update.
This does not mean forcing people into a poor fit. A distinctive rule or handover may be central to the business. The question is whether that difference is important enough to justify its continuing care.
Consider change over the product's life
Configuration usually works within the vendor's supported options. Custom code or deeply altered behaviour may need testing each time the product changes. Ask who will maintain it, how it will be documented and what happens if the vendor's direction changes.
A small extension outside the core product can sometimes be clearer than reshaping the product itself. Compare that option with a process change and with a focused bespoke layer.
Test the difficult case
Use a representative case that previously required a workaround. If a configured product handles it well, avoid unnecessary custom work. If it fails, document the exact failure and design the narrowest change that makes the important work reliable.
Imagine a team wants a custom screen because its current spreadsheet has twelve columns. In the new product, six of those fields are no longer needed and four exist elsewhere.
Try a configured view that supports the actual decision before reproducing the spreadsheet. Customise only the remaining difference if it materially affects the work and the business can own the change.