Designing 85 screens for a business ERP
A consumer app is one idea drawn thirty times. An ERP is thirty ideas that have to agree with each other about what a customer is — and the thing that breaks the build is never a screen. It is the third module discovering that the second one modelled tax differently.
This kit is eighty-five mobile screens covering sales, purchasing, inventory, accounting, project management, reporting, configuration and HR. Working at that size changes what a design system has to be for, and a few of the decisions are worth writing down.
Eighty-five screens, twenty-four tokens
At twenty screens you can hold the whole design in your head. At eighty-five you cannot, and the only thing standing between a product and forty slightly different shades of grey is a token file that people actually use.
So the whole colour and elevation system here is twenty-four tokens: twenty colours, three gradients, one shadow. Three surfaces, three text weights, one hairline, two brand colours, six tints, five status colours.
The smallness is the design decision the rest of it rests on. A set that fits on one page is a set that can be audited; a set of ninety is a set that gets ignored, and then every new screen quietly invents its own greys.
One elevation, in particular, is worth defending. There is no shadow-sm. If something needs to feel closer, it needs to be bigger, or on top, or somewhere else — an interface with one shadow cannot develop an accidental z-axis hierarchy that nobody designed.
Tints and status colours are not the same job
This is the distinction most likely to be lost during implementation, and in business software it is the one that matters most.
A tint is identity. The Sales chip is blue because Sales is blue, on every screen, forever. It says nothing about the state of anything.
A status colour is state. Green means paid, posted or reconciled. Orange means due or awaiting approval. Pink means overdue. Blue means in progress. Teal means verified. Their entire value is that someone can scan a list of two hundred invoices and see the shape of the problem without reading a word.
The failure begins innocently. Someone needs a colour for a new category, green is to hand and looks nice, and now green means both "paid" and "Inventory". A month later a green pill on a bill list tells the user nothing, and no sixth status colour will bring the meaning back.
The rule that protects it: a status colour never identifies a thing, and a tint never describes a state. In an ERP that single rule is worth more than the rest of the system combined, because state is what people are actually scanning for.
The screens nobody draws
Most mobile business kits stop at a dashboard, a list, a detail page and a form. The screens after that are where a product either earns trust or quietly loses it.
A journal entry form with debit and credit columns that will not save unbalanced. A chart of accounts as a tree with account codes ordered as strings, because they are codes and not numbers. Bank reconciliation where matching suggests and the user confirms — never a silent auto-match. A trial balance that balances.
These are drawn here at the same fidelity as the dashboard, and they are the reason the kit is eighty-five screens rather than thirty. They also make demands that reach past the UI: a credit card is not an account with a negative balance, and a purchase order line carries ordered, received and billed quantities — three numbers, not one. Getting that wrong is not a design fix later. It is a migration.
One list surface, eight lists
Invoices, bills, quotations, purchase orders, vendors, expenses, tickets and projects are all the same screen with different columns and filters. Eight lists, one surface.
Drawing them as eight separate artboards is honest — they do look different — but building them as eight widgets is how a codebase ends up with four subtly divergent list implementations and a bug that only appears on the fourth.
The kit's answer is that there is one list surface and everything else is a filter, and the accompanying prompt library turns that into a build instruction: extract the shared list before building the second one, not after the fourth. After the fourth it is a refactor with a business case attached, and it will lose to the next feature every time.
The same applies to the ten reports, which share a period selector, a comparison toggle, a body and an export action; and to the seven create forms, which share a scaffold with a sticky footer and an unsaved-changes guard.
Reports are where the design gets tested
A profit and loss statement is a hard mobile layout. Two columns of figures, a comparison period, nested subtotals and a total, all on a 390-point screen without horizontal scrolling.
What makes it work is the same thing that makes the rest work: figures in a tabular-figure typeface so columns align, one hairline token so the rules never disagree, and no decorative colour anywhere near a number. The only colour in a report is a status colour, and it means what it always means.
The audit trail deserves a mention too, because it is the screen that most reveals whether a system was designed or assembled. It shows who changed what and when, which means every mutation in the app has to record it — best done as a decorator around the repository rather than a call each feature has to remember. A trail whose completeness depends on developers remembering is not a trail.
Dark mode is not an inversion
Both themes are complete definitions of the same twenty-four names, and the dark one is not the light one flipped.
The page surface goes to a soft near-black while the screen background behind it drops further, so cards still sit above their ground rather than merging with it. The six tints stop being solid pastels and become translucent, so they work over any surface without needing a second set. The shadow gets both deeper and larger, because in dark a shadow is doing separation work that surfaces alone cannot do.
What does not change is the status colours. Green means paid at exactly the same wavelength in both themes, because status recognition is muscle memory and a user who switched theme did not agree to relearn it.
Building the second theme also found a real bug, which is the usual reward: an active dock chip drawn as white with primary-text colour on it, invisible the moment primary text became near-white. A literal white where a token belonged. Every design system has three of those, and the only reliable way to find them is to render every component in both themes at once and look.
Where the screens stop
A kit this size raises a question that a twelve-screen kit does not: what happens to everything the screens imply but do not state?
Half the answer ships with it. The architecture document these screens were drawn against names the ninety-odd entities, states the five canonical postings every document must produce, lists the API surface each screen sits on, and is blunt about the invariants — debits equal credits on every entry, a posted entry is immutable, stock on hand is derived from movements and never stored, payroll is read-only on the client. It also ends with seven decisions deliberately left unresolved, which is what a specification honestly looks like at this stage.
The other half cannot ship, because it only exists once you look at both together. A document that names an entity does not say which of its fields appear on which screen, or which screen leads to which, or where the two quietly disagree — and in eighty-five screens drawn by humans, three or four of them will.
So the kit's prompt library opens by having Claude read the document and the canvas side by side and derive the rest: a screen map with the navigation edges and the endpoint behind each screen, a field-level model cited back to the screen each field came from, and a client architecture for the app itself. Conflicts get flagged rather than quietly resolved. Finding those on the first afternoon costs an afternoon. Finding them in month two costs a migration.
What it comes down to
Eighty-five screens is not a bigger version of twenty. It is the point at which consistency stops being a matter of care and becomes a matter of structure — one list surface, one report shell, one form scaffold, twenty-four tokens, one rule about what a colour is allowed to mean.
None of that shows up in a screenshot. It shows up in month three, when someone adds the eighty-sixth screen and it takes an afternoon instead of a week.