Two branch managers ask for the same thing in different words: "Can approvals over 2 million shillings need a second sign-off?" One branch wants it at 2 million. The other wants it at 5 million, and wants the regional manager copied in, not the finance director. Both are reasonable requests. Neither is, by itself, a reason to write new code.
This is the moment every ERP project reaches sooner or later: a requirement lands on the table, and someone has to decide whether it is a setting, an integration, or genuinely custom development. Get that decision right, and the system stays fast to change, easy to upgrade, and cheap to support. Get it wrong — treat every request as a coding job — and the "flexible" system you bought becomes a maintenance liability within eighteen months.
Kraal Code, Chwezi's ERP platform, is built configurable and multi-tenant precisely so that most of what an organisation needs — approval thresholds, roles, report layouts, currency and location rules — is a setting, not a software project. This article sets out how we decide, with our clients, when configuration is enough and when development is the right call.
Ask What Difference Is Commercially Necessary
Start with the two branches and their approval thresholds. Before estimating anything, ask one question: does this difference reflect a genuine commercial or regulatory distinction between the branches, or is it simply "how we've always done it here"?
A different threshold because one branch handles higher transaction volumes, or operates under a different regulatory ceiling, is a commercial difference worth preserving. A different threshold because a manager prefers a certain style of oversight is a process habit — and process habits are exactly what an ERP implementation should be an opportunity to align, not a reason to fork the system into two versions that drift apart over time.
This is the filter that comes before any technical classification: is the difference worth keeping? Only once that answer is yes do we move to how to support it.
Four Categories, in Plain Language
Every requirement we receive gets sorted into one of four categories:
- Settings. A value, rule, or threshold that changes behaviour without touching code — an approval limit, a tax rate, a report filter, a user role. This is what Kraal Code's configuration layer exists for, and it covers the large majority of day-to-day requests.
- Extensions. A new field, a new report, or a new document template that sits alongside the standard system without altering its core logic. Low risk, contained cost, upgrade-safe.
- Integrations. A connection to another system — a payment gateway, a government tax portal, a banking API. The complexity here lives in the connection and its data mapping, not in the ERP core itself.
- Core changes. A genuine change to how the system's underlying logic works — a new approval workflow structure, a new type of transaction the platform doesn't currently model. This is where real development effort belongs.
Most requests are settings. Some are extensions. A smaller number are integrations. Genuine core changes are, and should be, rare — and every one should be a deliberate decision, not a default response to "the system doesn't do X yet."
Document the Rule Before You Estimate the Work
Before any requirement gets an estimate — whether the answer turns out to be "change a setting this afternoon" or "scope a development task" — write it down in a form that survives contact with a developer, a tester, and an auditor eighteen months from now:
- The rule. Stated as a business rule, not a screen description: "Purchases above 2,000,000 UGX require regional manager approval," not "add a second approval button."
- The actor. Who triggers it, and who approves or acts on it.
- The exception. What happens when the standard rule doesn't apply — an emergency purchase, a delegated authority during leave, a one-off waiver.
- The acceptance example. One concrete, worked example with real-shaped numbers (redacted if needed) that a tester can use to confirm the rule behaves as specified.
A requirement written this way is unambiguous to configure, test, and audit. A requirement written as "make it more flexible" is unambiguous to nobody, and it is where scope creep quietly begins.
Compare the Full Cost, Not Just the First Estimate
The build estimate is the smallest number in this decision. Before committing to custom development, compare it against:
- Future upgrades. Configuration and standard extensions move forward with every platform update. Core changes to underlying logic need to be re-tested, and sometimes re-built, against each new release.
- Test effort. A setting change needs a quick regression check. A core change needs a full test cycle against every workflow it touches.
- Support responsibility. Who fixes it in year three, when the person who wrote it has moved on? Standard configuration is supported as part of the platform. Bespoke code is supported by whoever agrees, in writing, to own it.
- Data portability. Does the change keep your data in a standard, exportable structure, or does it introduce a bespoke data shape that only this custom module understands?
Weighed against these four factors, a "quick customisation" that looked cheaper than reworking a process often turns out to be the more expensive path over three years — not because the initial development was overpriced, but because nobody priced in what happens after go-live.
Two Worked Examples
Configuration is sufficient: A distribution company wants purchase approvals routed differently for stock items versus office supplies, with different thresholds for each category. This is a role, a category flag, and an approval rule — all standard configuration within Kraal Code's procurement and approvals modules. No development required.
Development is genuinely needed: A logistics company needs to split a single customer invoice across three cost centres based on delivery weight ratios calculated from data the ERP doesn't currently capture at the line-item level. That is a new calculation logic and a new data structure — a real core change, scoped and estimated as one.
The difference between these two isn't complexity of request — both sound complicated when a manager first describes them. The difference is whether the standard system's rules and data model already have a place for the requirement, or whether the platform genuinely needs to be taught something new.
Record the Decision — and Revisit It
Every configuration-versus-development decision should be written down: what was requested, which category it fell into, why, and who signed off. This record does two things. It stops the same argument happening again eighteen months later when someone forgets why a threshold is set the way it is. And it gives you a clear trigger for revisiting the decision — when policy changes, when the organisation crosses a size threshold, or when a workaround built for one branch is quietly being copied by three others.
Where Kraal Code Fits
Kraal Code is built configurable across financial control, procurement, inventory, payroll, sales, assets, and approvals — precisely so that the categorisation above resolves in favour of configuration far more often than development. Where a genuine core change or integration is needed, Chwezi's custom software team scopes it as a defined, estimated piece of work, with support responsibility agreed before it is built — not assumed afterwards.
If your team is weighing a difficult requirement right now, bring it to a Kraal Code conversation and ask us to classify it: configuration, integration, or development. That classification, done honestly before any code is written, is the single highest-leverage step in the whole decision.
| Requirement | Standard fit | Alternative | Custom work | Future owner | Acceptance evidence |
|---|---|---|---|---|---|
| e.g. Branch approval threshold | Yes / No | ? | ? | ? | ? |
Frequently Asked Questions
How do I know if a request is "just a setting" or something bigger?
Write the rule down using four elements: the rule, the actor, the exception, and an acceptance example. If the exceptions multiply as you write them out, that is usually a sign the request needs a proper development scope rather than a quick configuration change.
Does every custom feature increase long-term cost?
Not automatically, but every custom feature adds a support obligation that someone must own, in writing, from day one. Features scoped and estimated with that obligation in mind rarely become liabilities. Features added informally, without an owner, usually do.
Can configuration handle differences between branches or regions?
Often, yes. Kraal Code's configuration layer supports role-based approvals, multi-currency processing, and location-specific rules as standard settings. Genuine differences in regulation or scale are usually still configuration; differences that are just habit are worth aligning instead of preserving in code.
What happens if we build something custom and later want to move to standard configuration?
This is why data portability matters at the decision stage. A custom feature built on top of the standard data model can usually be retired in favour of configuration later. One built on a bespoke data structure is much harder to unwind.
Continue with Is Your Organisation Ready for an ERP Implementation? for the readiness questions that come before this one.
