Stuart
A modular platform that manages anything.
One core, a handful of replaceable packages, and an application that never has to be forked to fit the next customer.
- Composer packages
- 5 Composer packages
- admin modules
- 13 admin modules
- core edits to add one
- 0 core edits to add one
- Role
- Product, architecture, build
- Period
- 2026 — now
- Stack
- Laravel 12 Livewire 3 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. Building that twenty as a branch of the eighty means maintaining a fork per customer, and by the third one nobody dares upgrade anything. Stuart exists to make the twenty a package instead of a branch.
How it works
The core declares interfaces; the modules implement them; the host application decides which implementation to bind. Recipes name an ingredient through the inventory contract rather than through the inventory table, so swapping the whole stock package leaves recipes standing. 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, FIFO and FEFO picking, 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 package depends on the core and never on inventory, 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 ledger rather than beside it.
Billing that is part of the platform
Subscriptions through Laravel Cashier, invoices raised through Clark over the API — so the product bills its customers with the same compliance machinery 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. A tenant is a household or a company, not a mailing list.
Runs where it is put
Docker for development, a scripted release to a droplet for production — build locally, ship, migrate, swap the symlink. Rolling back is swapping it back.
A decision worth explaining
The recipe table carries no foreign key to items. It cannot: the table an item lives in belongs to whichever package satisfies the inventory contract, and the recipes package is not entitled to know its name. Giving up the database-level constraint is what buys the ability to replace a module without a migration — a trade made on purpose, and the reason this is a 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