Mobile ERP — 85 App Screens UI Kit
Most mobile UI kits give you a dozen screens and stop where the product gets difficult. This one goes the whole way: eighty-five screens covering every module a small business actually runs on, including the ones nobody draws — bank reconciliation, a Dr/Cr journal entry form, aged receivables, an audit trail, payroll — and the architecture document they were drawn against.
What you get
- 85 screens on one HTML canvas, grouped by module: auth and onboarding, home, sales and CRM, purchases, inventory, accounting and banking, project management and tickets, reporting, review, configuration and HR
- 2 themes — light and dark — every screen drawn from tokens rather than literal colours, so a third theme is one block of declarations
- 24 design tokens as
tokens.json,tokens.cssandtokens.dart— generated from the artboards, so they are the design rather than a description of it - Architecture Document, Markdown and Word — the domain model behind the screens, the five canonical accounting postings, the full API surface, the mobile specification, and seven decisions deliberately left open
- 11-page design system guide, PDF and Markdown: what each token is for, why tints and status colours are different jobs, and how to wire both up in CSS and in Flutter
- Prompt Library — 21 pages, 46 prompts for Claude Code: the first four read the architecture document and the canvas together and derive what the document does not cover, and the rest build the app module by module
- Opens offline with nothing installed — React, Plus Jakarta Sans and Bootstrap Icons are all bundled in
vendor/, so there is not one network call
Works with
- Any modern browser — the screens are an HTML page you open, not a file you import
- CSS custom properties, or Flutter via a
ThemeExtension— the guide shows both - Claude Code, for the prompt library; the screens, tokens, spec and guide need nothing
Not included
- A Figma library
- A product requirements document — the architecture document covers what the product is and what it must guarantee, not who it is for
- Component code for a framework
One licence, personal and client work, forever. No resale.
An ERP is not a big app. It is thirty small apps that have to agree with each other about what a customer is, and the thing that kills the build is never a screen — it is the third module discovering that the second one modelled tax differently. That is the problem this kit is shaped around.
Twenty-four tokens carry all eighty-five screens across both themes. Twenty colours, three gradients, one shadow. The smallness is the design decision the rest of the system rests on: at eighty-five screens you cannot hold the whole thing in your head, and the only thing standing between you and forty slightly different greys is a token file that people actually use.
Tints and status colours are separate, and that is the point
Six tints carry identity — the Sales chip is blue because Sales is blue, on every screen. Five status colours carry state: green is paid or posted, orange is due, pink is overdue, blue is in progress, teal is reconciled. They never cross over.
That single rule is worth more in business software than the rest of the system combined, because state is what people are actually scanning for. A user looking at two hundred invoices sees the shape of the problem before reading a word — right up until the day someone uses green for a category, and then a green pill means nothing.
The screens that most kits skip
A Dr/Cr journal entry form that will not save unbalanced. A chart of accounts as a tree. Bank reconciliation with suggested matches the user confirms rather than silent auto-matching. Aged receivable and payable. Trial balance, general ledger, cash flow, executive summary. An audit trail. A purchase order line with ordered, received and billed quantities — three numbers, not one. Item stock per location. Attendance, leave, payroll and an org chart.
These are the screens where a product either earns trust or quietly loses it, and they are drawn here at the same fidelity as the dashboard.
The screens come with the spec behind them
The Architecture Document is the reason several of these screens look the way they do. It names the ninety-odd entities, states the five canonical postings every document must produce, lists the whole API surface, 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 is trimmed to what a buyer of the screens needs. Repository layout, authentication mechanics and permission internals are left out on purpose: those are choices that belong to your build, and nothing in the screens depends on them.
What the Prompt Library actually does
It does not start at screen 01. The first four prompts read the architecture document and the canvas together and derive what the document does not cover: a screen map with the navigation edges and the endpoint behind each screen, a field-level domain model cited back to the screen each field appears on, and a client architecture for Flutter. Every place the two disagree gets flagged rather than quietly resolved.
The remaining forty-two prompts build the app in the order that surfaces the hard problems on day one — the multi-company leak test before the second table, the money-as-integer rule before the first total, the list surface extracted before the second list rather than after the fourth.
What is the placeholder name?
The kit ships under placeholders rather than a brand, so nothing has to be undone. "Corebook" is the product and "Northwind" the company; search and replace both with your own. They appear in the canvas title, the wordmark on screen 01, the sample email domain and the ticket prefix.
Is this Figma?
No, and there is no .fig in the download. The screens are a single HTML canvas you open in a browser at full fidelity, and the tokens are JSON, CSS and Dart. Everything is inspectable in dev tools or a text editor.
Do I have to build it in Flutter?
No. tokens.dart and the Prompt Library both assume Flutter, but tokens.json and tokens.css are framework-agnostic, and so are the screens, the guide and the architecture document.
Is the architecture document finished?
It is marked v1.0 Draft, awaiting sign-off, and its last section lists seven decisions still open — offline scope, per-entity conflict resolution, document numbering, multi-currency, period locking, attachment retention and time zones for attendance. That is what a real specification looks like at this stage, and the Prompt Library has a chapter for working through them deliberately rather than inheriting them.
Does it work offline?
Completely. The fonts, the icon set and the React runtime are bundled in vendor/. Open the file on a plane and it renders exactly as it does online — which is not true of most HTML kits, including the ones that say they are self-contained.
Reviews
Nothing here yet.
Questions & answers
No questions yet. If something about this product isn't clear, ask — we answer publicly so the next person finds it too.