The spreadsheet everyone is fighting
A small service business, an independent workshop to start with, runs its entire day inside one shared spreadsheet. Status, approvals, parts, rough pricing, all in cells anyone can overwrite and no one can audit. There is no role separation, no evidence trail, and no way for a customer to see or approve the work. The owner cannot tell what is stuck or what is unpaid. I have been building the thing that ends that spreadsheet.
One record, five surfaces

The product answers the question that repeats all day: where is this job, what is blocking it, what has been approved, and what proof do we have. One record is the truth; everything else attaches to it. Five roles each get a surface built for how they actually work: dense desktop dashboards for the owner and the platform admin, and mobile-first apps for the supervisor, the field worker, and the customer. India-first, and multilingual from the first version, because the floor and the customer do not share one language.
Trust as a design material

The spine is a lifecycle the server refuses to break. A job can only move through legal states, and every move writes an audit event. Money moves only through audited routines; invoices are gap-free and immutable once issued. And every AI draft, every piece of customer-facing evidence, passes a human-confirm gate before anyone outside the team sees it. The intelligence speeds a worker’s note-taking. It never makes a claim to a customer on its own. That gate is the product’s whole posture on trust.
Three directions, one decision
I mocked three visual directions before committing to one: a restrained, information-dense operations look, a bold high-contrast command centre, and a warmer, more literal treatment. I chose the restrained one, locked the design system at its first version, a semantic token layer with real light and dark and no literal colour in any component, then shipped the entire redesign into the live product without touching a single data path, route, or security rule. Afterward I audited my own redesign against production and wrote down, honestly, the cross-role flows it had skipped. Naming what you missed is the part most redesigns leave out.
One system, many industries
The most recent turn is the one I like most. The same product now speaks more than one trade. A vocabulary layer renames every operation per industry, a workshop’s job becomes a kitchen’s order or a builder’s project, a customer becomes a guest, a vehicle becomes a table, without forking the code and without touching the money math or the permissions underneath. You generalise by relabelling the surface, never by copying the spine. It is the clearest systems decision I have made in a while.
What it taught me
This is the difference between a prototype and a product: a prototype demos, a product refuses to do the wrong thing. Almost every hard decision here was about what the system would not allow, an illegal status change, an unconfirmed claim reaching a customer, a redesign quietly editing a security rule. Constraints, written down and enforced, are what let one person ship something a business can actually run on.
Interested?
This one is real and in use, and I am always up for talking about operations software for small business. If it is your world, write to me or reach me on the contact page.