When a digital process changes, the discussion is often framed too simply: “Can we do it quickly with a setting, or does it need to be developed?” That question conceals a more important design decision. Every change introduces a business rule, an operational expectation, and a future maintenance cost. Solving everything with code slows adaptation; solving everything with configuration options can make the product unpredictable, difficult to audit, and fragile.
The right decision does not depend only on the initial effort. It depends on the stability of the rule, who needs to change it, the risk involved, and whether the change introduces a new capability. The goal is to let the process evolve without turning every exception into a permanent branch or hiding critical decisions in ambiguous administration screens.
The three alternatives and the boundary of each
The same request can be expressed as a fixed rule, a configuration, or custom development. These are different mechanisms and should have clear responsibilities.
Stable rule implemented in code
A rule in code is appropriate when it represents a structural product behavior: mandatory validations, security constraints, calculations with little variability, or decisions that must be the same for every case in a given context. It is also a good choice if changing it requires understanding technical dependencies or if an error would have serious consequences.
- Advantage: explicit behavior, versioned with the software and covered by automated tests.
- Risk: a minor operational adjustment requires deployment and can create dependency on the technical team.
- Diagnostic signal: the rule remains virtually unchanged for months, and there are few legitimate reasons for each unit to alter it.
Manageable configuration
Configuration is intended for anticipated process variations. For example, approval thresholds, notification recipients, operating calendars, enabled categories, or sequences of steps within an already designed framework. It is not a way to avoid design: it is a product capability that needs a data model, permissions, validations, and an understandable interface.
- Advantage: business or operations teams can respond to authorized changes without waiting for a development cycle.
- Risk: too many parameters create combinations that are impossible to understand or test.
- Diagnostic signal: the change is recurring, foreseeable, and within limits that the system can validate.
Development of a new capability
Custom development is necessary when the request changes the process model: it introduces participants, states, decisions, data, integrations, or exceptions that did not previously exist. Trying to fit it into a parameter often produces scattered conditional logic and a configuration interface that no one can govern.
- Advantage: it makes it possible to design a coherent, observable, and sustainable solution.
- Risk: treating a one-off need as a generic platform and overextending the scope.
- Diagnostic signal: supporting the change requires adding new fields, permissions, routing rules, or states.
The six questions for classifying a change
Before estimating tasks, product, business, and technology teams should answer the following questions in writing. The answers reduce decisions based only on urgency or on the apparent cost of the first implementation.
- How often does it change? If it may vary several times a year because of legitimate operational decisions, configuration deserves evaluation. If it is exceptional and will not recur, an explicit rule or a temporary solution with a removal date may be more appropriate.
- Was the variation anticipated in the design? Configuring should not mean accepting any behavior. There must be a bounded set of options and compatibility rules.
- Who owns the decision? If operations needs to change it, they need a safe experience and appropriate permissions. If it requires technical interpretation, it should remain in code.
- What is the impact of an error? The greater the financial, legal, security, or operational continuity impact, the greater the required control: validation, review, testing, and traceability.
- Does it affect the domain model? If a new entity, state, role, or relationship appears, this is not merely configuration; there is probably a capability to design.
- How will it be checked and reversed? If the effect cannot be previewed, the change recorded, and the setting rolled back, the configuration is not ready to be manageable.
Healthy configuration constrains decisions within a design; it does not transfer responsibility for designing the system to the user.
When to use code, configuration, or development
A stable rule in code is preferable when a request does not allow variations by unit, when it protects an essential condition, or when its validity depends on complex logic. For example, preventing a request from moving to approval without the required minimum data. Turning that condition into an editable checkbox can degrade process quality.
Configuration is appropriate for operational decisions that change within a known range. An approval flow may allow the amount above which a second review is required to be defined, provided that the system validates the value, identifies those responsible, and prevents the flow from being left without an approver. In that case, the product does not provide absolute freedom: it provides controlled variability.
Custom development should begin when the change alters the nature of the flow. If an organization needs parallel approvals, temporary delegation, rules based on attributes of several entities, and escalation upon expiry, it has probably moved beyond a threshold parameter. It is advisable to design a routing and decision capability, even if it is implemented incrementally.
Risks that reveal a poor decision
Over-parameterization is the most common risk. It is often recognizable because the screen contains technical names, contradictory options, implicit dependencies, and values that no one dares to change. The team ultimately needs a developer to interpret a configuration that business was supposedly managing.
The opposite problem is invisible exceptions in code. They arise when each customer, department, or special case adds an isolated condition. Over time, two rules produce different results for situations that appear equivalent, and no one can explain which one takes precedence. A clear warning sign is when incidents are resolved by asking “which condition is evaluated first” instead of consulting an understandable policy.
There is also a risk of duplicated logic. A threshold defined in an administration interface, repeated in an integration service, and reinterpreted in a report creates divergence. To prevent this, every decision must have a single source of truth, an owner, and a known place where it is evaluated.
How to design secure and governable configuration
Manageable configuration should be treated as part of the product, not as an editable table. First define which variations are valid and which are not. Then incorporate controls proportionate to the impact.
- Role-based permissions: separate who can view, propose, approve, and publish changes.
- Business validations: prevent invalid combinations before saving, rather than after the process has already failed.
- Auditable history: record what changed, who made the change, when it happened, and what the previous value was.
- Explicit scope: clearly indicate whether the rule applies to the entire organization, a unit, a request type, or a period.
- Scenario testing: allow representative cases to be checked before activating a high-impact modification.
- Rollback: provide a controlled way to restore a previous version without manually editing multiple values.
OWASP recommendations on authorization and input validation are particularly relevant when non-technical users manage rules that affect permissions, amounts, or decision routes. The interface should explain the effect of each change without exposing unnecessary technical details.
Example: the evolution of an approval flow
Imagine a flow in which every request above a defined amount requires approval from a responsible person. The requirement to enter an amount and the prohibition on approving one’s own request are stable rules: they should remain in code and be covered by tests.
The threshold amount and the responsible person can be configurable if they vary by operational unit and the system validates that an active responsible person always exists. The history should show which threshold was in effect when each request began, so that a later change does not rewrite the context of a decision already made.
If the organization later requests that two departments approve in parallel, that responsibility depend on category and region, and that delegation be available during absences, the team should stop. It is no longer reasonable to add checkboxes to the existing configuration. This is the time to define a routing rules capability, with its own priorities, conflicts, states, and observability.
A sustainable decision is not about always choosing the fastest alternative. It is about selecting the mechanism that preserves process clarity today and allows it to evolve tomorrow. Use code for invariants, configuration for anticipated variations, and development for model changes.