Context
WebOustaou reached its v0.10.0-beta milestone in July 2026 — the point where the back-office core (menu, hours, blog, happenings, QR, analytics, billing) is functionally complete. This entry is about what comes after: the phases already designed, several partly laid into the schema, that move WebOustaou from "manage your restaurant's presence" to "run your restaurant's operations."
Nothing below is speculation for the sake of a pitch deck — it's the same roadmap published at weboustaou.fr/roadmap, reframed here as an architecture story.
Phase 3 — Ordering Core
The next phase, already unblocked by recent schema work, introduces orders, order_items, and order_item_modifications, plus a customization_rules table designed around what I call the "Margherita rule": remove an ingredient (say, cheese) and the price and modification are captured structurally, not as free text. Orders follow a simple lifecycle — cart → placed → preparing → ready → completed / cancelled — with no payment processing yet at this stage.
Ingredients and allergens are already first-class reference tables today, not embedded text in a product description — a deliberate choice made long before ordering existed, specifically so this phase wouldn't require a data-model rewrite.
Phase 4 — Kitchen Display System & Self-Serve Tablets
This is the one worth teasing: a Kitchen Display System (KDS). Orders land on per-station displays (a pizza station, a drinks station) over Supabase Realtime, auto-refreshing as tickets move through the kitchen. stations and station_displays tables model the physical kitchen; a tablets device-registration table backs kiosk-mode self-serve ordering on the floor.
The public roadmap already lists it as "in development": "Kitchen display, order management and planning unified on the platform across every ordering channel," with automatic ticket routing to the right station as a considered follow-up.
The groundwork is older than the feature: a recent architectural decision (ADR-023) re-parented menu, hours, and closures from the public website to the physical shop specifically so that orders — and eventually the KDS — can query kitchen state directly by shop, with no indirection through which public site happened to take the order. A shops.kds_enabled column already exists in the schema as a placeholder for this phase.
Phase 5 — Web Ordering
Customer-facing ordering: separate customer accounts, cart persistence, Stripe Connect payments (the restaurant gets paid directly, WebOustaou takes a platform fee — not a per-order commission model), order notifications by email and SMS, and re-ordering from history.
Phase 6 — An AI Phone Agent
The most exploratory phase: a Twilio Voice integration where an LLM takes phone orders using the same function-calling access to the ordering API a human staff member would use, backed by phone_calls and call_turns transcript tables, a confirmation SMS with a magic link, and a human fallback for anything the agent can't resolve. For a restaurant, the phone never stops ringing during service — this is aimed squarely at that problem.
And the Backlog
Loyalty and rewards, inventory tracking, delivery-platform integrations, multi-currency support, and a menu-aware assistant are tracked but not yet phased — visible on the public roadmap under "considering."
Why Design This Far Ahead
This is less about roadmap theater and more about a systems-engineering habit: the additive-migrations-only constraint that governs WebOustaou's schema means every future phase has to be imagined before the current one ships, or the schema will need a rewrite instead of an extension. Multi-tenancy, RLS, and JSONB-based i18n were all built in from the first migration for the same reason — not because Phase 0 needed them for one pizzeria, but because Phase 4 and Phase 6 would.
Status
Phase 3 is next. Nothing here is promised on a date — the public roadmap tags each item shipped, in-dev, or considering, and KDS currently sits at in-dev. I'll keep this entry and the roadmap blog article updated as phases land.
Takeaway
The most interesting architectural decisions in WebOustaou are the ones nobody notices yet — the schema columns and package boundaries that exist for a feature that hasn't shipped. That's the systems-architect instinct: design for the phase after next, build for the one in front of you.
