The brief
The client is a private organisation in an online roleplay community. Running it involves a lot of record-keeping: who ordered what, who has paid, what is in the shared stash, who owes the group for stock they have taken, and who is assigned to which production job.
The goal was a private operations system that gives leaders one reliable record and gives members a simple place to order, check their status and see what is assigned to them. All money in the system is fictional in-game currency. The platform keeps records only; it never handles real payments.
Discovery: mapping how the organisation actually works
We started with the workflows rather than the screens. Working from the owner’s requirements document, we traced each process from start to finish and wrote down the rules that could never be broken:
Two roles only. Super Admins run the organisation and members use it. Rank inside the group is shown on a profile but never changes what someone can do.
History never changes. When a member places an order, the item name and price are copied onto the order, so editing the catalogue later never rewrites past orders.
Stock moves, it is never overwritten. Every change to the stash is a movement with a reason, so any number can be traced back.
The server is the source of truth. Totals, prices and quantities are calculated on the server, never trusted from the browser.
Each workflow was written as a set of statuses before any interface work began. For example, an order moves from pending to processing to completed, and its payment moves separately from unpaid to payment submitted to paid. Agreeing these early meant the design and the database described the same thing.
Designing the system
The interface had to suit two very different users: leaders who live in tables all day, and members who drop in a few times a week. We designed a calm, dense admin workspace, using Untitled UI as the quality benchmark, with a sidebar, compact filter rows, full-width tables and clear status badges. Members get a much smaller set of screens built around their own orders, assignments and notifications.
We built the design system first: colour, spacing and type tokens, then hand-made components such as buttons, dialogs, tables, status badges, KPI cards, empty states and confirmation dialogs. Every list has an intentional empty state, every loading view has a skeleton, and dangerous actions always ask for confirmation. The product supports light and dark themes.
Building it
The system is a Next.js web application on Supabase (PostgreSQL). We designed the database before the dashboard. Any action that touches several records, such as approving a payment or drawing stock from the stash, runs as a single database function, so it either completes fully or not at all. Access rules are enforced in three places: the request layer, the server actions and row-level security in the database. Hiding a button in the interface is never the only protection.
We delivered the work in phases, each one usable before the next began:
Foundation: project setup, design tokens and the database schema with its access rules.
Accounts: username sign-in, admin-managed accounts and password resets, inactive-member lockout and rate-limited sign-in.
Catalogue and orders: a member order builder, then the admin workflow to verify payments, process, distribute and complete orders.
Company stash: stock, raw materials, tools and seized property, with a full movement history.
Operations: notifications, member management, activity and audit logs, and role-aware dashboards.
Organisation-specific modules: company cash, the supplier price book, monthly material submissions, relations with other groups, distribution of stock to members and production assignments.
Hardening: each dashboard loads in a single database round trip, totals are calculated in SQL, and list indexes and security reviews keep the system fast and safe.
Requirements changed as the organisation used the system. Production started as a piece-rate pay model and was later redesigned as an assignment board, where a job has a crew and each person is marked paid separately. Because the database had been structured around clear records and movements, the change could be made without disturbing existing history.
The final product
Leaders get one place to run the organisation:
An admin dashboard with key figures, a queue of items needing attention, recent activity, low stock and recent orders.
An order workflow with payment, processing and distribution tracked as separate steps, each recorded on a timeline.
The company stash, a cash ledger with reversals, a supplier price book, and stock distribution to members with each member's balance owed.
Production assignments with per-person payment status, monthly material submissions, and a relations board.
A live game-server monitor that shows who is online, through a small relay service.
An activity feed and an append-only audit log showing the before and after of every change.
Members get a focused view: browse the catalogue and place orders, mark an order as paid to a named admin, follow its progress, and see their own assignments, distributions and notifications. Members never see another member's data.
Illustrative ERP dashboard with sample data.
The same codebase can now run a second organisation. Each brand has its own name, colours, logo, database and deployment, and all brands receive updates from one main branch.
Quality and testing
Automated checks run on every change. They cover type checking, linting, unit tests and server-action tests. A database suite applies every migration to an in-memory PostgreSQL and checks the workflows, access rules and authorisation for each function. Browser tests cover key journeys end to end.
Building an operations tool for your own team or community? See our web application development and UI/UX and product design services.