Every ERP project we run is ordered the same way: schema first, API second, UI third. The customer signs off the data model — in plain English, not in diagrams — before any screen is built. This sounds bureaucratic and is, in fact, the cheapest engineering rule we follow.
What "schema first" actually means
It does not mean drawing entity-relationship diagrams. ER diagrams are a notation; they are not understanding.
It means writing the data model in prose the customer can read. A typical schema document, two pages, looks like:
A Customer has a name, a billing address, a GST number, a credit limit and a default payment term. A Customer can have many Sales Orders. A Sales Order has a header (date, customer, dimension codes, total) and many Sales Order Lines. Each Line refers to one Item, has a quantity and a unit price, and may have a discount …
Then we ask the customer's finance lead, operations lead and IT lead to read it and tell us where it's wrong.
It is always wrong. The credit limit is not at the customer level; it's at the customer-and-region level, because Tamil Nadu sales are handled by a different team and use different limits. The discount is not on the line; it's on the customer for some product categories and on the line for others. Dimensions are mandatory for projects but optional for retail.
The first two weeks of an ERP project are this conversation. We resist showing UI mockups, because mockups bias the conversation toward what the screens look like, not toward what the underlying truth is.
Why UI third
UI changes are cheap. Schema changes are expensive.
If we agree on a customer credit limit at the customer level, build the UI, then learn three months in that the limit is actually per region — every downstream report, every API consumer, every integration breaks. The data model is upstream of everything; the further downstream a change is, the cheaper it is.
The principle is older than software: get the model right, then the rest follows.
The order in practice
We run six phases on every ERP project — Discovery, Design, Build, Migrate, Go-live, Hypercare. The schema work lives mostly in Design, after Discovery has surfaced enough business reality to model it.
Within Design, the order is:
- Entities and their attributes — what nouns exist; what each noun has
- Cardinalities — what relationships connect entities; one-to-many or many-to-many; mandatory or optional
- Constraints — what's unique, what's nullable, what's foreign-keyed, what's CHECKed
- Indexes — which queries we expect to run hot, which require composite indexes
- API surface — what operations the front-end needs; this is when we start sketching endpoints
- UI — only after 1-5 are signed off in writing
The sign-off is by named people, not by committee. The CFO signs off the finance entities. The operations head signs off the inventory and order entities. The CTO or external IT lead signs off the integration boundaries.
When we break our own rule
We've broken it twice in ten years, both times under schedule pressure, both times we paid for it.
The first time we built a manufacturing module's UI before the bill-of-materials model was firm. Two months in, the customer realised that their BoMs were not strict hierarchies — there were shared components across product variants that needed to be costed once but consumed many times. We rebuilt the data layer; the UI rework took six weeks.
The second time we built a hotel front-desk POS before formalising the rate-plan structure. The customer ran corporate rates, OTA rates, walk-in rates, group rates and a long tail of seasonal exceptions. We'd modelled this as a single rate per room-type per night. It turned out to be a four-dimensional matrix. The rework cost three weeks.
In both cases the time we "saved" by starting the UI early was negative.
A subtle point: the data model is a contract with the future
Five years from now, the customer will want to migrate to a new system. The new system will read the old database. If the old schema is well-modelled, migration is mechanical. If it's denormalised and assumption-laden, migration is a forensic exercise.
We are routinely on the receiving end of this. When we migrate a customer off a 12-year-old custom application, the cost of the migration is almost entirely a function of how well the original team modelled the data. A clean schema migrates in two weeks; a tangled one takes three months.
Doing the work now is doing a favour to the team that will pick this up after we're gone.
The discipline scales
This is not just an ERP thing. We apply the same rule to SaaS products. The CognitiveIQ schema document — 22 tables, ~470 lines of SQL — was reviewed and signed off in plain English before any Drizzle code was written. The Marketing OS schema went through three rewrites in Design and zero in Build.
It feels slow at the start. It is faster overall, every time. The hours spent reading a prose schema document over chai with the finance team are the highest-leverage hours of the project. We've never regretted them. We've regretted skipping them, twice.