Built for the way your kitchen runs.
9 systems. One platform. Each feature designed around scheduled-production food, not retrofitted from a restaurant POS.
Why MISE AN PLACE exists
Restaurant POS systems weren't built for what you do.
Most software in food assumes orders happen now — someone walks up, taps a phone, gets food. Bakeries, caterers, meal-prep, roasters, CSAs don't work that way. You take orders today for tomorrow. There's a cutoff. There's a bake list. There's a route. There's a moment everything has to be ready.
MISE AN PLACE is the operating system for that kind of business. Every feature on this page exists because spreadsheets and POS workarounds break the moment you scale past a one-person shop.
The problem
Orders live in 5 places
DMs, emails, voicemails, an Etsy inbox, a Shopify cart. You spend the morning consolidating before you can bake.
The fix
One canonical order list
Storefront, cart, account portal, and dashboard all read from the same data. Your morning starts at the production sheet, not in your inbox.
The benefit
Hours back, errors gone
The platform handles every step that used to live in spreadsheets, group chats, and your inbox — so the right thing is always the easy thing.
How you'll use it
A day in your kitchen, with MISE AN PLACE.
You don't have to think about features individually. They fire in the right order, on their own. Here's what the platform does for a typical bakery on a typical Wednesday.
6:30 AM
You walk in. The sheet is waiting.
Production sheet shows 47 sourdoughs, 23 croissants, 8 cakes — aggregated from last night's orders. Print, stick on the wall, start mixing.
9:00 AM
Customers add to cart all morning.
Storefront takes orders for tomorrow. Apple Pay one-tap checkout. Customers see live cutoff timer. AI assistant fields the 'is the croissant vegan?' questions while you bake.
12:00 PM
Cutoff fires. The day locks.
Vercel cron flips every submitted order to locked. Stripe captures payment. Refund window closes. Tomorrow's bake list is now final, no surprises.
2:00 PM
Driver pulls the packing route.
One-click route, sorted by zone, by street. Optional Onfleet hand-off so customers get live tracking texts. Mark each delivered as you go.
8:00 PM
You close the laptop.
Today's orders are reconciled. Stripe payouts in your bank in two days. Tomorrow's sheet rebuilds itself overnight. You don't have to babysit a spreadsheet.
A real storefront, not a templated landing page.
Every tenant gets a full e-commerce site at their own domain — heirspears.com, not somemiseplatform.com/heirspears. Custom theme, your photography, your copy. Your customers never know the platform exists.
Custom domain
Map your own domain, SSL provisioned automatically. Vercel handles the certificates.
Tenant-controlled theme
Pick colors, fonts, logo, hero copy from your dashboard — changes go live in seconds.
Storefront pages out of the box
Home, menu, product detail, about, delivery info, FAQ, blog, catering quote, customer accounts.
Feature
Branded storefront
Your brand. Your domain. Your storefront.
- Custom domain. Map your own domain, SSL provisioned automatically. Vercel handles the certificates.
- Tenant-controlled theme. Pick colors, fonts, logo, hero copy from your dashboard — changes go live in seconds.
- Storefront pages out of the box. Home, menu, product detail, about, delivery info, FAQ, blog, catering quote, customer accounts.
- Built for SEO. Server-rendered, JSON-LD structured data, sitemap, robots.txt, Open Graph cards. Google indexes you fast.
Bakery use case
Scenario: Heir's Pears wants to migrate from Shopify to a system that actually understands their bake schedule.
Outcome: Their existing customers visit heirspears.com as before. Behind the scenes, every order now respects the noon cutoff.
Cutoff is the heartbeat of scheduled-production food.
Most restaurant POS systems assume orders happen now. Scheduled-production food doesn't work that way. You take orders today for tomorrow. At your cutoff time, the day locks. We built the entire system around that practice.
Daily cutoff time, per tenant
Set noon for next-day delivery, or 4pm Wednesday for Saturday catering. Per-day cutoff times supported.
Automatic lock at cutoff
Vercel cron + Inngest run every 15 minutes. When your cutoff passes, every submitted order moves to locked.
Payment captured on lock
Stripe authorizes at checkout, captures on lock. No refund-if-customer-cancels-after-cutoff drama.
Feature
Cutoff-driven workflow
Set your cutoff. The rest happens.
- Daily cutoff time, per tenant. Set noon for next-day delivery, or 4pm Wednesday for Saturday catering. Per-day cutoff times supported.
- Automatic lock at cutoff. Vercel cron + Inngest run every 15 minutes. When your cutoff passes, every submitted order moves to locked.
- Payment captured on lock. Stripe authorizes at checkout, captures on lock. No refund-if-customer-cancels-after-cutoff drama.
- Production sheet on the other side. Kitchen wakes up to a single page: every item to make, sorted by category, with quantity totals.
Meal-prep use case
Scenario: Lunchbox Co. takes Tuesday-through-Saturday meal-prep orders that ship Sunday. Cutoff is Saturday 6pm.
Outcome: Sunday morning, the kitchen has a single sheet listing every meal. Production starts. No spreadsheet, no group chat.
The two reports your kitchen actually needs.
Cooking and delivering require different views of the same data. The kitchen wants 'how many of each thing'. The driver wants 'what goes to whom'. We generate both — every day, automatically.
Production sheet — by item
Every item ordered for a given day, summed. 47 sourdoughs, 23 croissants, 8 cakes. Print and stick to the wall.
Packing sheet — by customer
Each customer's order on its own line, sorted by zone for the route. Includes notes, allergens, special instructions.
Print and PDF
One-click print-optimized layout. PDF download for digital teams.
Feature
Production & packing
From order list to bake list, automatically.
- Production sheet — by item. Every item ordered for a given day, summed. 47 sourdoughs, 23 croissants, 8 cakes. Print and stick to the wall.
- Packing sheet — by customer. Each customer's order on its own line, sorted by zone for the route. Includes notes, allergens, special instructions.
- Print and PDF. One-click print-optimized layout. PDF download for digital teams.
- Daily and date-range views. Look at tomorrow, the next three days, or this whole week.
Catering use case
Scenario: 20 corporate lunches across Vancouver this Friday.
Outcome: Production sheet: total of 240 sandwiches by type. Packing sheet: 20 deliveries grouped by neighborhood, in route order.
We never touch your money.
MISE AN PLACE doesn't take a cut of your sales. Stripe charges its standard processing fee at the moment of charge; everything else goes straight to your bank. No platform-held escrow, no waiting periods, no opaque payouts.
Standard Stripe Connect
You own the account. You see your dashboard, your payouts, your tax forms.
No application fee on transactions
We earn from your monthly subscription, not from your sales. Stripe takes its 2.9% + $0.30 (cards) and the rest is yours.
Apple Pay, Google Pay, cards, ACH
Whatever Stripe supports, you support.
Feature
Stripe Connect
Your money flows directly to you.
- Standard Stripe Connect. You own the account. You see your dashboard, your payouts, your tax forms.
- No application fee on transactions. We earn from your monthly subscription, not from your sales. Stripe takes its 2.9% + $0.30 (cards) and the rest is yours.
- Apple Pay, Google Pay, cards, ACH. Whatever Stripe supports, you support.
- Refunds and disputes. Full refund flow built in. Disputes handled in your Stripe dashboard.
All use case
Scenario: A customer pays $50 for a bakery order on the operator's storefront.
Outcome: On that $50 charge, Stripe takes ~$1.75 in processing (2.9% + $0.30) and MISE AN PLACE takes $0.00. The remaining $48.25 lands in the operator's bank account in 2 business days.
Geography-aware delivery without the spreadsheet.
Define zones by postal-code prefix. Charge different fees for different distances. Set per-zone minimums so you don't drive to Burnaby for a $12 order. Cap zones at a daily delivery count so your driver isn't doing 60 stops.
Postal-prefix zones
First three characters of the postal code define a zone. V6A, V6B, V6C → Downtown. V5K → Hastings. Etc.
Per-zone fees and minimums
Base delivery fee, optional fuel surcharge, optional minimum order amount.
Quote-only zones
Customers in distant zones can request a quote instead of placing an instant order.
Feature
Delivery zones
Where you go, what it costs, who can order.
- Postal-prefix zones. First three characters of the postal code define a zone. V6A, V6B, V6C → Downtown. V5K → Hastings. Etc.
- Per-zone fees and minimums. Base delivery fee, optional fuel surcharge, optional minimum order amount.
- Quote-only zones. Customers in distant zones can request a quote instead of placing an instant order.
- Pickup locations. Skip delivery entirely — customers pick up at addresses you specify.
Bakery use case
Scenario: Vancouver bakery delivers within 8km, charges by zone.
Outcome: Downtown: $8 fee, $30 min. North Van: $14 fee, $50 min. Anything past Surrey: quote-only.
An AI that knows your business — and only your business.
Customer-facing chat trained on your products, ingredients, allergens, delivery zones, FAQ, and policies. It answers in your voice. It refuses off-topic questions and prompt-injection attempts. It never invents facts.
Topic-locked
If a customer asks about politics, sports, weather, or other restaurants — the bot politely declines.
Trained on your content
Pulls from your product descriptions, FAQ, delivery zones, hours. Re-indexes on demand.
Refuses prompt injection
Built-in classifier blocks 'ignore previous instructions' attacks before they reach the model.
Feature
AI assistant
A chef who knows your menu by heart.
- Topic-locked. If a customer asks about politics, sports, weather, or other restaurants — the bot politely declines.
- Trained on your content. Pulls from your product descriptions, FAQ, delivery zones, hours. Re-indexes on demand.
- Refuses prompt injection. Built-in classifier blocks 'ignore previous instructions' attacks before they reach the model.
- Streaming responses. Server-sent events stream tokens to the chat widget so customers see the answer building.
Bakery use case
Scenario: Customer asks: 'Are the croissants vegan?'
Outcome: Bot replies based on the product's dietary_tags and ingredients fields. Cites the product name. Links to the product page.
Five roles. Reasonable defaults. Full audit trail.
Owners run the business. Managers run operations. Employees do the cooking. Drivers do the delivering. Customers buy. Each role sees a different dashboard.
Owner
Full access. Financials, staff, billing, settings, audit log.
Manager
Catalog, customers, refunds (under threshold), notes, calendar, reports. No access to financials or staff invitations.
Employee
Today's deliveries, tomorrow's production, order search, mark-delivered, mark-ready.
Feature
Roles for your team
Everyone sees what they should, nothing more.
- Owner. Full access. Financials, staff, billing, settings, audit log.
- Manager. Catalog, customers, refunds (under threshold), notes, calendar, reports. No access to financials or staff invitations.
- Employee. Today's deliveries, tomorrow's production, order search, mark-delivered, mark-ready.
- Account admin. B2B-only role. Place orders for their company, see their company's invoices.
Bakery use case
Scenario: Mo (owner), Tanya (manager), Kevin (driver). Tanya should be able to refund up to $100 without Mo's approval. Kevin should never see financials.
Outcome: Mo configures the threshold once. Tanya processes refunds same-day. Kevin sees only the day's deliveries.
Programmatic access to your tenant data.
Read your orders, products, customers via REST. Receive webhooks on every state change. Build whatever you need on top.
REST API
GET /api/v1/orders, /api/v1/products. Bearer auth. JSON responses. Rate-limited at 600 req/min per key.
Outbound webhooks
Configure URLs to receive HMAC-signed JSON payloads on order.locked, order.delivered, quote.sent, etc.
Exponential backoff retries
Failed webhooks retry at 1m, 5m, 15m, 1h, 6h. Max 5 attempts before pending → failed.
Feature
API + webhooks
Connect MISE AN PLACE to everything else.
- REST API. GET /api/v1/orders, /api/v1/products. Bearer auth. JSON responses. Rate-limited at 600 req/min per key.
- Outbound webhooks. Configure URLs to receive HMAC-signed JSON payloads on order.locked, order.delivered, quote.sent, etc.
- Exponential backoff retries. Failed webhooks retry at 1m, 5m, 15m, 1h, 6h. Max 5 attempts before pending → failed.
- Per-key scopes. Keys can read orders, products, customers — independently. No global admin keys exposed.
All use case
Scenario: Tenant uses Xero for accounting and wants daily order data pulled in.
Outcome: Xero integration polls /api/v1/orders?since=yesterday and reconciles. No manual export.
Security at the database level, not the app level.
MISE AN PLACE is a single-database multi-tenant platform. Tenants share infrastructure but their data is isolated by Postgres Row-Level Security policies. There's no application-level if-statement that could be bypassed by a bug. Postgres itself enforces tenancy.
Row-Level Security on every table
Every table has tenant_id and a policy: WHERE tenant_id = auth.tenant_id(). Postgres enforces it.
JWT-bound tenant resolution
Tenant comes from the user's auth context, not the request. Forging a tenant_id is impossible from the client.
Append-only audit log
Trigger prevents updates to audit rows. Reviewers can trust what they see.
Feature
Multi-tenant by design
Your data never leaks. Ever.
- Row-Level Security on every table. Every table has tenant_id and a policy: WHERE tenant_id = auth.tenant_id(). Postgres enforces it.
- JWT-bound tenant resolution. Tenant comes from the user's auth context, not the request. Forging a tenant_id is impossible from the client.
- Append-only audit log. Trigger prevents updates to audit rows. Reviewers can trust what they see.
- Encrypted at rest. Supabase manages disk encryption. Backups encrypted. Point-in-time recovery available.
All use case
Scenario: Imagine a future bug where a server action queries the wrong tenant by mistake.
Outcome: Postgres rejects the query because the RLS policy doesn't match. The bug is caught at the database boundary, not customer trust.
Ready to get your kitchen in its place?
14-day free trial. No card. Live in under 30 minutes.