Restaurant operations · Piloted 2026
0-1 in 7 days
Mise, an AI-native margin-intelligence workspace for restaurants
- Product Strategy
- AI-Native Development
- Synthetic User Research
- Design Systems
- Agentic UX
Overview
Mise consolidates POS, invoice, and recipe data to pinpoint losing dishes, explain causes, and offer fixes. I built it natively with AI from scratch, piloting in less than seven days, then rebuilt based on feedback.
The gap
Every restaurant margin tool shows what happened, but lacks guidance
I found lagging dashboards and outdated recipe calculators left restaurant operators reacting to food costs after the damage was done. AI-suggested price hikes do not draw on past data. Restaurant operators face tough questions alone, analyzing issues manually.
Existing platforms serve different roles: Toast IQ aids workflows, and FoodStorm handles ordering. Each excels in its area but lacks the full margin decision loop to decide, implement, measure, and learn. Mise fills this gap as an evidence layer beside the POS.
"The data was present but lacked decision guidance."
Built natively (with Claude)
I built Mise myself, directing architecture and decisions, with Claude writing the code.
A 7-day build required logic-first rules before screens. Then I worked like a PM with engineers: short prompts, review builds, redirects. The scope included problem framing, architecture, design system, product sections, and an AI agent. The real challenge was making decisions fast enough to keep the build moving.
My direction
I set the information architecture and decision-loop logic by defining explainable costing with target margin and evidence from the lens of a restaurant operator. I made sure every revenue plan requires human approval. I set file-first intake for trial without POS contract and AI agent's rule to cite sources or refuse.
Claude’s responsibility
The build included a React workspace with page scaffolding, component library, tokens (brand green, warm canvas, font usage), import pipeline, local persistence, Ask Plato drawer tools, server-side checks, and pilot deployment.
Stress-tested on a synthetic persona
Before a real user, I built a synthetic restaurant GM with the skills and duties of running a high-volume restaurant.
Modeled on a high-volume revenue manager rather than a typical operator, the synthetic persona prioritizes margin dollars over food-cost percentages.
The persona, in raw form
Powered by a custom skill file, the AI enforced strict revenue logic like break-even checks and category rules. That is what let it push back on the product the way a real operator would.
An excerpt of the skill file behind the synthetic GM.
Approving a plan, in the pilot
Evidence-backed suggestions stage plans off-POS, deferring tracking until real-world changes are confirmed by a user.
Pilot outcomes
- Trust broke on the words, not the math. A Fried Chicken Half price recommendation cited a cost trend the data did not show. To avoid AI hallucination, I added server data validation and a strict 'cite source or refuse' guardrail.
- Visible evidence was positive. Shrimp & Grits showed clear approval as shrimp cost trends were visible and measurable. Evidence and trend lines became mandatory for recommendations.
- Silent failures cost more time than the ritual. Settings failed silently, demo recipes mixed with live data, and approving decisions could erase cards. I added save confirmations, strict live/demo separation, and reliable records. Gaining trust through guardrails was challenging.
The leap: tool to teammate
Moving on from rigid MVP directives, the post-MVP version simplified the interface to empower user decisions.
Pilot feedback confirmed core value but exposed cluttered views, weak iPad layouts, and manual review tasks.
Post-MVP, I moved the build to Perplexity Computer orchestration and Cursor, redesigning interaction to 70% human and 30% agentic flow. Plato handles prep and flags, shifting the GM from manual execution to strategic AI collaboration.
| MVP | Post-MVP |
|---|---|
| GM reviews a static recommendation | GM works the decision with Plato, then approves it with a reason on record |
| Busy, bordered layout that broke on iPad; same chat and chips on every page | One next action per screen, calm surfaces, light and dark themes, works from desktop to 320 px |
| GM ticks a weekly checklist by hand | Plato prepares the weekly brief; the GM saves a snapshot only if they want one |
| Plato shown as a generic AI icon | Plato as a character with different emotion states |
The post-MVP version hasn't run its own pilot yet. It's built and tested against issues from the first pilot, ready for round two.
Overview
Before: I had dense cards, repeated counts, heavy borders.
After: I refined it to a single next action, with calm surfaces and source status in view.
Approving a plan
Before: I had a single-click approve dialog which needed more context.
After: I highlighted current vs proposed state comparison, weekly impact and evidence before approval.
iPad view with Plato
Before: I did not plan for iPad responsiveness in the MVP.
After: I accounted for Plato in the post-MVP with a dynamic content flow.
Plato demo
Product modules
It finds the risk before you do.
Mise automatically flags at-risk dishes against target margins, eliminating reports and spreadsheets entirely.
Two dishes at risk, the 68% target they are measured against, and the dishes themselves.
It shows its work
Every metric traces to raw costs, volume, and assumptions, letting operators trust data over blind faith.
Grilled Ribeye at 58.4% margin, 9.6 pts below target, and the open plan that follows from it.
It recommends. You decide.
Mise simulates margin and price impacts before execution, requiring recorded operator approval to go live.
The plan is modelled, and +$165.55 a week is visible before the operator approves it.
Plato, the AI agent
Plato had to feel like a teammate without ever acting like the boss.
Plato started as a line drawing beside an empty chat box. Moving past a generic chat box from the pilot phase, I gave Plato a memorable face that visually communicates its true operational state.
The character is my own mascot, a smiling plate, and it went through three versions before it worked in the product. I split the mascot into layered assets, using code to tie every expression directly to real-time system state.
Version 1 Static animation looked right but could not react to anything.
Version 2 Plate and eyes separated, so each part moves on its own.
Shipped Composed in code, so expressions follow what Plato is doing.
Design system
The system had to move at the speed of the product without losing its source of truth.
During the MVP I built the Figma library, called Mise DLS 0.1.0. The post-MVP changed almost every surface, so the real question was how to update the system without breaking what the pilot relied on, and without Figma and code drifting apart.
I audited Figma gaps and built code-first foundations: semantic dark/light tokens and unified focus states.
-
01 · Figma
Audit the baseline
- Mise DLS 0.1.0 library
- Read-only snapshot, nothing overwritten
- Gaps logged against the app
-
02 · Tokens
Rebuild the foundations
- Light and dark semantic colour
- Manrope, 13 px floor
- Focus border and halo
-
03 · Storybook
Components and docs
- Overview, anatomy, properties, states, accessibility
- Patterns from the shipped app
- Basil 48 and Plato layers
-
04 · Figma
Import and publish
- Plugin adds 0.2.0 pages beside 0.1.0
- Variables, styles, Basil vectors
- Reviewed, merged, published
- Release gate automated WCAG 2.2 AA checks on every story and app screen
- Archival 0.1.0 components kept as an archived MVP set
- Human sign-off keyboard, screen reader, zoom and reflow before publishing
Storybook became the working library. Each component page answers the same six questions: overview, anatomy, properties, states, accessibility and examples. Sourcing patterns directly from the production app kept design documentation grounded in shipped reality.
I imported v0.2.0 tokens into Figma without overwrites, archived legacy components, and published the library.
Mandatory WCAG 2.2 AA passes and code-first tokens established a single source of truth across design and code.
Results
A piloted loop, a rebuilt experience, and a product ready for its second restaurant.
6
Actions accepted in the pilot, with 3 validated against measured results
In 48 hrs
Built up post - MVP
762
Page cleared automated checks and theme combinations with zero WCAG 2.2 AA accessibility findings.
Real-file edge cases in the pilot led to verification guardrails that automatically withhold unsupported claims. The post-MVP version applied these lessons, shipped with Mise design system 0.2.0, and went live on Vercel.
Reflection
Building natively with AI changed what being the designer actually meant, day to day.
I stopped making handoff artifacts and started making decisions, as each decision quickly became working software. My design judgment became the ultimate filter for setting firm rules, iterating screens, and rejecting weak assets. It also taught me to plan around tool limits when deciding where to plan and execute. A read-only Figma connector and no branching meant designing the release path as carefully as the screens.
The synthetic pilot proved the loop works. An industry run could bring in more feedback.
Live POS feeds and operator memory will test whether grounded briefs shorten review times and drive higher approvals. And expanding brand design could strengthen the product exposure.