Stuart
A modular platform that manages anything.
The application is built around a single core, with packages carrying everything around it. Adding something for the next customer, or taking it away, stays easy.
A running demo of the real thing, open to anyone. It carries its own data, so anything you do in there stays well away from a real customer.
- apps — stock, recipes, purchasing, budget, invoicing
- 5apps stock, recipes, purchasing, budget, invoicing
- modules — in the admin
- 13modules in the admin
- changes — the core stays unchanged
- 0changes the core stays unchanged
- Role
- Product, architecture, build
- Period
- 2026 — now
- Stack
- Laravel Livewire Tailwind CSS MySQL Laravel Cashier Docker
The problem
Every business asks for the same eighty percent — accounts, roles, invites, permissions, a calendar, a dashboard — and then for a completely different twenty. Build that twenty as a separate version of the eighty and you maintain one copy per customer — and by the third, nobody dares improve anything, because every improvement has to be made three times and tested three times. Stuart exists to make that twenty a separate part you switch on or off, rather than a copy.
How it works
The core sets out what has to be possible; the parts fill in how. A recipe asks for an ingredient from stock without knowing which stock part sits underneath — so that part can be swapped out entirely while the recipes carry on working. It is deliberately demonstrated on something unglamorous and merciless — running a household, where the stock is real, the deadlines are dinner, and nobody accepts a workaround.
What is in it
Stock as a double-entry ledger
Every movement is balanced and has two sides, so nothing is ever created or destroyed — only moved. Lots, locations, oldest first or first-to-expire first, reservations, and a stock level that can always be explained rather than merely reported.
Recipes that know what they cost
Ingredients, steps, tools and timings, planned against what is actually on the shelf. The recipes depend on the core and never directly on stock, which is what makes both replaceable.
Purchases, suppliers and shopping
A receipt turns into stock, a shopping list turns into a purchase, and the planner turns next week into both. Every step lands in the books rather than beside them.
Billing that is part of the platform
Subscriptions through Stripe, invoices raised by Clark — so the product bills its own customers with precisely the rule-checking it sells.
Invite-only by design
Public registration is off, email is verified before it is trusted for login or sending, and roles and permissions are group-shaped. An account is a household or a company, not a mailing list.
Runs where it is put
One fixed command puts a new version live, in the same order every time and with no handwork. Going back to the previous one is just as quick, and is a step in the plan rather than an emergency.
The trade-off
The recipes hold no hard link to the stock items in the database. They cannot: those items belong to the stock part, and the recipes are not entitled to know anything about it. Giving up that link costs a piece of automatic checking, and it is exactly what makes it possible to replace a part without rebuilding the database — a trade made on purpose, and the reason this is one platform rather than four applications that rhyme.
Something like this on your list?
The projects differ, the way of working does not. Tell me what you are trying to solve.
Taking on new work