Food and drink
Supplier ordering for a restaurant group
A group of four restaurants orders from twelve suppliers. Each kitchen builds tomorrow's order from a price list, the order goes to the supplier by email, and deliveries are checked in against what was ordered. Head office sees food cost per restaurant per week.
Automatically generated draft
Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.
Section 01 · What has to work
Head office must be able to see accurate, aggregated food costs per restaurant from checked-in supplier deliveries.
Section 03 · Screens
Every screen, and what it is for.
- ›Order Creation — Kitchen staff builds tomorrow's order from a supplier's price list; adding an item is instant.
- ›Delivery Check-in — Kitchen staff confirms received goods against a placed order; marking an item received is instant.
- ›Order History — Kitchen staff views their restaurant's past orders; opening an order's detail view is instant.
- ›Cost Dashboard — Head office reviews food cost per restaurant per week; filtering by week is instant.
- ›Price List Management — Head office manages supplier items and prices; saving a price change is instant.
Anything not on this list is not in version one. That is what keeps a fixed price fixed.
Section 04 · The data model
What it stores, and who can read a row.
PurchaseOrder
id uuid, restaurant_id uuid, supplier_id uuid, status enum('draft', 'placed', 'receiving', 'completed', 'cancelled'), delivery_date date, created_at timestamptz
Access · Kitchen staff read/write for own restaurant. Head office reads all.
OrderLineItem
id uuid, purchase_order_id uuid, pricelist_item_id uuid, price_at_order numeric(10,2), quantity_ordered numeric(10,2), quantity_received numeric(10,2)
Access · Kitchen staff read/write for own restaurant. Head office reads all.
PricelistItem
id uuid, supplier_id uuid, name text, unit text, price numeric(10,2), is_active boolean
Access · Head office read/writes all. Kitchen staff read all active items.
Supplier
id uuid, name text, contact_email text
Access · All authenticated users can read all suppliers.
Restaurant
id uuid, name text, head_chef_id uuid
Access · All authenticated users can read all restaurants.
Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.
Section 05 · States
draft → placed → receiving → completed | cancelled
Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.
Section 06 · Where this breaks
What bites products like this one.
Kitchen connectivity is unreliable, causing data loss during order creation or check-in.
The application must support offline operation, queueing changes to sync when a connection is re-established.
An order is marked 'placed' but the supplier's email system rejects or quarantines it.
Use a transactional email service with delivery/bounce tracking and alert on send failures.
Supplier invoice price differs from the price list at time of order, skewing cost data.
During check-in, allow kitchen staff to override the price and flag the variance for head office review.
Section 08 · Deliberately left out
What version one does not do.
- ×Direct API integration for sending orders and syncing price lists with suppliers. — It is complex and depends on 12 different third parties; defer until the internal workflow is proven.
- ×Inventory tracking or depletion logic based on items ordered. — This introduces significant state management; focus first on the core procurement and cost-reporting loop.
This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.
Still open
What we would ask before quoting.
- Who is responsible for updating the price lists from twelve suppliers, and how are those updates received today?
- When a delivery is short, over, or contains a substitute item, what is the exact process for resolving it?
- Are kitchen staff assigned to one restaurant, or do they need to access orders for multiple locations?
Half of this already exists
Doc Intake
The paperwork half of this is a solved problem: documents read on arrival, validated against your rules, and a person asked only about what does not add up.
It is one of our pre-built products: the code is handed over to you, adapted to your own wording and rules, and the rest of the specification above is built on top of it rather than from scratch.
Your product, not this one
Get this written for what you are actually building.
Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.
Next step
Find out if your idea fits in 10 working days.
Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.