The short answer
Every custom system encodes the business as it was when it was built. The ones that stay useful separate the stable parts, which are coded, from the volatile parts, which are configured.
Get that line wrong and every price change, new product type or extra approval step becomes a development ticket, which is when people start going round the system.
What belongs in configuration
- Rates, thresholds and limits
- Lists of types, categories and statuses
- Approval rules and who approves what
- Email and document templates
- Rules that vary by customer or contract
- Anything you have already changed twice
The last point is the practical test. If something has been changed twice by a developer, it should be configuration by the third time.
Configuration needs governance
Making things editable creates a new risk: someone changes a rate and nobody knows why the numbers moved. Configuration needs the same discipline as code, in a lighter form.
- Record who changed what and when.
- Keep the previous value so it can be reversed.
- Require a second person for anything with financial effect.
- Validate inputs so a typo cannot create an impossible rule.
- Show the current configuration somewhere people can read it.
Leave room in the data model
| Rigid | Flexible |
|---|---|
| One address per customer | Several, with a type |
| One price per product | Price with a date range and a context |
| Status as a fixed list in code | Status as configurable data |
| One contact per account | Contacts with roles |
| Single currency assumed | Currency on the record |
The right column costs a little more at first and absorbs a great deal of later change. The left column is cheaper until the day it is not.
Review it deliberately
Once a year, ask whether the system still matches how the business works, which parts people work around, and what has been added that nobody uses.
That last one matters too. Features nobody uses still need maintaining, testing and upgrading. Removing them is real work with a real return.
Know when to stop extending
There is a point where a system has been stretched past its design and each change costs more than the last. Recognising that is better than continuing to add.
The signals are estimates rising for similar work, changes causing unrelated breakages, and developers describing parts as untouchable. That is a rebuild conversation, and having it deliberately beats drifting into it.