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 business's presence" to "run its operations day to day."
Everything below comes straight from the public roadmap at weboustaou.fr/roadmap, told here from an architecture angle.
Phase 3: The Ordering Core
The next phase, already unblocked by recent schema work, introduces orders, order_items, and order_item_modifications, plus a customization_rules table. It's built to capture product modifications (removing an ingredient, say) as structured data: which ingredient, and what it does to the price, stored as data rather than a free-text note. 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. That's a deliberate choice made long before ordering existed, specifically so this phase wouldn't require a data-model rewrite.
Phase 4: Kitchen Displays and 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 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), 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, and that's exactly the problem this phase is aimed at.
And the Backlog
Loyalty and rewards, inventory tracking, delivery-platform integrations, multi-currency support, and a menu-aware assistant are already identified but not yet phased. They're on the public roadmap under "considering."
Why Design This Far Ahead
This isn't roadmap theater, it's 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 needs a rewrite instead of an extension. Multi-location support, 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, later.
Status
Phase 3 is next up. 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, thinking about the phase after next while building the one in front of you.
