Vice Kitchen
Designing an internal operations platform to replace paper systems in a working restaurant kitchen.
Overview
I designed it. I built it. I also run the kitchen it's deployed in.
Vice Kitchen is a mobile-first internal operations platform built for the kitchen teams at Vice Pizza & Wings across three Dublin locations: Merrion, Phibsboro, and Dundrum. The app replaces paper binders, WhatsApp messages, and tribal knowledge with a single PWA accessible on any staff phone or tablet.
I designed and built this tool myself, working from inside the kitchen as the person who both manages the operation and understands the daily friction firsthand. That proximity to the problem shaped every decision.
The problem
The gap between how things should be done and how they actually were
Recipes existed in someone's head or in a folder nobody opened. SOPs were written once and never consulted. New staff had no reliable way to self-serve information during a shift without interrupting a senior chef.
The challenge was building something that held up under real kitchen conditions: fast-moving, loud, hands often wet. Simple enough to grab mid-service, and accurate enough that managers could actually trust what was in it.
Who I designed for
A kitchen chef who needs the answer in under five seconds
Marta Kowalski
Kitchen Chef / Line Cook · Dublin, Ireland
Mid-level chef working across multiple stations at a busy pizza and wings kitchen. Technically confident but new to this specific menu. Needs fast, reliable access to recipe specs and prep quantities during service, without interrupting the head chef or digging through paperwork. Every interaction has to work with one hand, in poor lighting.
Process
Research & Problem Definition
- Mapped the real friction points experienced during kitchen shifts: inconsistent prep quantities across locations, no single source of truth for recipes, and new staff struggling to onboard without constant supervision.
- Identified that existing solutions (paper binders, shared Google Docs, WhatsApp) broke down at the point of use: inaccessible, out of date, or too slow to navigate during a live service.
- Established hard constraints before any UI work began: must run as a PWA on existing kitchen hardware, load instantly, and be navigable with one hand and gloved fingers.
Architecture & Design System
- Designed a static data architecture: all recipes, prep items, and SOPs stored as TypeScript arrays, eliminating load times and backend dependencies. The kitchen has no tolerance for a spinner.
- Built a brand-aligned design system: Barlow Condensed typography, warm off-white and Vice orange palette, strict rules distinguishing layout utilities from brand colour. Every decision made to ensure visual consistency across contributors.
- Structured navigation around the five real tasks a kitchen team performs during a shift: checking prep, searching for a recipe, consulting the menu, running hygiene checks, and accessing training materials.
Feature Development & Iteration
- Built and iterated core features in working sessions: recipe detail pages with full SOP-style layouts, a Dough Production SOP with batch size selector and step photography, a prep board with persistent localStorage state, and a search indexing recipes, menu items, prep items, and SOPs simultaneously.
- Solved location-specific complexity (Dundrum uses larger batch sizes due to a bigger mixer) by building a branch-aware batch system rather than duplicating recipes or maintaining separate content.
- Established a scalable SOP pattern: recipe-linked SOPs surface behind a "View Full SOP" button, while operational SOPs (opening, closing, hygiene) live in the Training tab. Architecture stays clean as content grows.
Deployment & Staff Rollout
- Deployed as a PWA, installable directly on kitchen phones and tablets without an app store. Getting staff onto the platform required one shared link, not an IT request.
- Introduced the tool gradually by location and role, using real shift usage to surface gaps in content and UI clarity instead of running a formal testing phase disconnected from actual kitchen conditions.
- The rollout is ongoing. New SOPs, recipes, and prep items are added as content is validated with head chefs at each location. The app grows with the operation.
The app — screen by screen
Login
PIN-based auth for kitchen speed
Prep Board
Daily prep list with persistent state
Menu
Full menu with cook times by item type
Search
Recipes, ingredients, SOPs — all indexed
Training
Modules with tracked progress per staff
Hygiene
HACCP, chemicals, and cleaning rules
Calculators
Weight-based ratio scaling for toppings
Dough SOP
Step-by-step with cleanliness callouts
Outcomes
Recipe and prep systems replaced with a single mobile platform accessible to all kitchen staff across three locations.
Reduced dependency on senior chefs as a source of knowledge: staff can self-serve recipe specs, allergen information, and prep quantities in seconds.
Built to support new SOPs, recipes, and locations without structural changes to the codebase. The architecture grows with the operation.
Key learnings
Designing for a kitchen means designing for interruption. Every interaction has to be completable in under five seconds, with one hand, in poor lighting. That constraint shapes every UI decision more than any design principle.
Being inside the operation is the biggest design advantage. The gap between what a kitchen needs and what a product person assumes it needs is enormous. Only closable by spending time on the floor.
A static, fast, boring architecture is the right architecture for this context. The instinct to reach for a CMS or database is strong, but the kitchen doesn't need real-time sync. It needs reliability and speed, which a static TypeScript data layer delivers perfectly.