How to choose an ERP that survives a decade
A module list describes what a system does today; the decade is decided by five choices made on day one that cannot be retrofitted — and that you verify from a terminal, not a slide.
- Published
- Author
- Konis Software
An ERP evaluation almost always starts with the wrong instrument: a spreadsheet where every row is a feature, every column a vendor, every cell a checkmark. It is the wrong instrument because it measures what is easy to equalise. At a high enough level of abstraction every serious system ticks every box — keeps stock, calculates VAT, handles customers — so the choice collapses to price and to the impression left by a demo. Neither predicts the next ten years.
A decade is decided by what the list leaves out. The module a company will need in year three — a ledger a new law introduces, a costing dimension a new owner demands, an integration with a system that does not yet exist — cannot be ticked today because it has not been designed. Whether that module can later be added without migrating data or rewriting the core is settled by the architecture beneath every checkmark. The list does not show it, and the demo hides it.
The thesis here is plain: you are not buying a module list, you are buying an architecture. A module is added when it is needed; five architectural decisions are made on day one and cannot afterwards be retrofitted without a migration, a rewrite, or a quiet lie that it was done. Those five — an open API beneath every screen, customisation outside the core, isolation in the database, provenance as part of the record, and rules with a validity interval — can be checked, but not from a slide. They are checked from a terminal, from the database schema, and from one uncomfortable question to the vendor.
A module is added; an architecture is inherited
On a feature list everything converges to yes. Every vendor will confirm they have an API, that the system customises, that it is secure, that it uses AI. The words are identical; what stands behind them differs by an order of magnitude, and that difference stays invisible until you force it out. One line is worth drawing through every item of the evaluation: is this something added (another report, another field, another module) or something inherited from day one (the shape of a record, the place of isolation, the way the system extends)? The first you buy when you need it. The second you either have at the start or pay for through a migration once it is too late.
Five decisions that cannot be retrofitted
Cannot be retrofitted is not a phrase for effect. It means adding the thing later requires one of three: migrating all existing data into a new shape, rewriting a core other customers have already received, or deciding not to and papering over the gap with manual work. The five decisions below are load-bearing walls, not paint on them. Each comes with a way to check it that a vendor cannot fake.
1. API-first: the screen is just one client
API-first does not mean a system merely exposes an API. It means every action in the system is available first through a documented interface, and the screen is only one of its clients — the same path taken by an integration, by automation, and by a future module that does not yet exist. When the API is a later addition, it covers part of the surface, bypasses business rules that live in the screen, and lags behind every new feature. A decade of integrations — with the bank, with the tax portal, with a webshop, with a customer's system yet to arrive — rides on exactly that boundary. If the screen can do something the API cannot, in ten years you will be doing it by hand.
2. Clean core: customising without forking the core
Every company wants something of its own — a field, a rule, a report, an approval flow. The question is not whether the system allows it but where that customisation lives. In a clean-core approach, extensions sit outside the core at defined extension points, and the core stays identical for every customer and takes upgrades without pain. When customisation is done by forking — editing the core or adding a column to a system table — you get a private version that must be merged by hand with every vendor patch. You pay for that merge forever, and upgrades slip or get skipped. The company that customised the most ends up on the oldest version.
3. Isolation in the database (RLS), not in the application
In a multitenant system many customers share one database, so the question is where the boundary between them is enforced. If the application keeps it — by promising every query carries a tenant filter — then one forgotten clause in one query leaks another customer's data, and it surfaces only once it is too late. Database-level isolation (row-level security) moves the boundary to where the application cannot bypass it: the database returns only rows of the tenant whose context is set, and nothing beyond it. That is a decision about the schema and the policies on tables; it cannot be added later without touching every query ever written. The same mechanism draws a second boundary customers rarely ask about — who on the vendor's side can see your data, and what trace remains when they do.
4. AI-native core: provenance and draft are fields, not a button
AI-native is the easiest claim to fake, because it collapses into a button or a chat panel bolted on the side. The real difference is whether the core knows its own provenance. Every record carries who created it — a person, a deterministic rule, or an accepted proposal — written at creation and immutable. What AI carries is a draft a person confirms, not an entry that posts itself. Without that field and that draft state, automation can be neither measured nor audited, and an AI that posts without confirmation is a risk that surfaces at the audit. Provenance and draft are decisions about the data model; adding them afterwards means re-labelling everything already entered — which nobody does, so it gets invented instead.
5. Time-effective rules: a parameter has a validity interval
Legal parameters change — the VAT rate, contribution bases, the minimum wage. The question is whether a parameter has a validity interval or is a single current value in a lookup table, overwritten on change. If it is overwritten, the past is lost: after the change, a document from a closed period can no longer prove which rate it carried, and a backdated posting takes today's value instead of the one in force then. Serbia's VAT rate was 18% from 2005, then 20% from October 2012 — these are public facts, and the system must know which applied on which date, not only which applies today. A versioned parameter with a validity range, and a version reference frozen on the posted line, cannot be added later; they are built in before the first line is posted.
How to check it from a terminal, not a slide
All five decisions have a check a slide cannot fake, because it asks not for an assertion but for an artifact: an API response, a row in the schema, the behaviour of the database, a document from a closed period. The check is not run on the vendor's happy path but on your awkward case, and it takes about as long as one call or one question whose answer must not be a presentation.
| Decision | A check a slide cannot fake | Red flag |
|---|---|---|
| API-first | Reproduce from the terminal what the UI does with a click: create a document, post it, read it back — with no screen. | The API covers part of the surface, calls private routes an integration cannot reach, or is a separate product. |
| Clean core | Diff two customers' cores — they must be identical; any difference may live only in extensions and configuration. | A promise to customise it for you means a private branch; each next patch is a merge you pay for and an upgrade you postpone. |
| Isolation (RLS) | Connect as the application role with no tenant context and run a query — it must return zero rows. | The tenant filter lives in application queries, not the database; or the only answer is that each customer gets their own database. |
| AI-native core | Look at the schema: is there a provenance field on the line, and can a record made by a rule be separated from one made by a person? | AI is a side chat with no link to the record; a proposal posts with no draft state; there is no provenance field. |
| Time-effective rules | Change a rate's effective date and reopen an old document — it must show the rate that was in force then. | The rate is a single current value overwritten on change; a backdated document takes today's rate. |
A module list describes what a system does today; the architecture describes what it will be able to do when the rules change. The first is checked on a demo, the second from a terminal — and only the second lasts a decade.
Questions for the vendor
Good questions ask not for reassurance but for an artifact: not whether an API exists, but a request to send the specification. An answer that arrives as a slide is itself a finding. The questions below cover the five decisions and two more boundaries rarely asked about that cost a decade — ownership of the data and the vendor's own access:
- Send the API specification. What share of the actions available from the screen can I perform without the screen?
- When your next version ships, what happens to fields and rules added for us? Show an upgrade of a customer who customised the system.
- Where is isolation between customers enforced — in the database or in application queries? Show the policy, not a diagram.
- Does a line carry who created it — a person or a rule — written at creation and immutable?
- Does an AI proposal post itself, or is it a draft a person confirms?
- When the VAT rate changes, how do I prove from the system which rate applied to a document from a closed period?
- How do I export all of my data without your assistance — which format, which interface? What stays with you when I leave?
- Who on your side can see my data, under what condition, and what trace remains when they do?
How NG One approaches it
NG One is built around these five decisions as load-bearing walls, precisely because they are the ones it could not add later. Beneath every screen sits a documented API that integration and automation travel on; customisations live outside the core, so the core stays the same for everyone and takes upgrades; isolation between customers is enforced in the database through row-level security, the same mechanism that draws the boundary toward platform staff; provenance is a field on the record — manual, rule, or accepted draft — and what AI carries stays a proposal until a person confirms it; legal parameters have a validity interval, and the version reference is frozen on the posted line. Each of these claims has a counterpart in code, in a migration, or in the API — not in a slide — because it is the same test this piece asks of every vendor.