Context
WebOustaou started in 2025 as a pure Supabase backend for one business: my parents' pizzeria, Darius Pizza, whose "back-office" was a set of Redis keys I edited by hand.
A year later it's a real multi-location management platform: a public marketing site, an authenticated admin workspace, and a forkable consumer-site template, sharing one Supabase schema and fifteen internal packages. The same problem the pizzeria had (fragmented tools, no source of truth, everything routed through a developer) is now solved for any independent restaurant, bakery, or salon that signs up.
What WebOustaou Is Today
The platform is a monorepo of three Next.js apps sharing a common package layer:
marketing(weboustaou.fr): the public site. Pricing, product pages, a public roadmap, a changelog, and a help center. Deliberately dependency-light: no Supabase, Stripe, or auth code can compile into it.admin(app.weboustaou.fr): the authenticated back-office where owners manage everything, from the menu and hours to closures, messages, the blog, QR codes, analytics, billing, and team access.site-template: a single-location, kitchen-sink consumer site meant to be forked per customer, so every restaurant or business gets a dedicated, fast, SEO-tuned public site built from the same production-tested foundation.
Underneath, one Supabase project (Postgres, hosted in Paris) models a three-level hierarchy: tenants → shops → websites, with row-level security enabled on every table by default. A customer account can own several physical shops, and a shop can expose more than one public website.
One Shared Platform, Not One Deployment per Restaurant
Owners with several locations manage them from a single login, switching context instead of juggling accounts. Team accounts let staff be invited with scoped access instead of sharing one password. Every table has been scoped by account through RLS since the schema's very first migration, long before there was any authentication to enforce it. That separation was never bolted on afterward, it's part of the foundation.
The Admin Workspace
Owners run the restaurant's digital presence from their phone or laptop:
- Menu, categories, products, ingredients, and allergens
- Opening hours, exceptional closures, and temporary messages
- A built-in blog: draft, translate, tag, schedule, and publish, with SEO metadata and JSON-LD
- "Happenings," for one-click event or pop-up promotion, with no-account interest capture
- Menu offers and featured-product highlights
- Trackable, re-pointable QR codes for print materials
- First-party, largely cookieless analytics
Every feature above shipped incrementally over about a year of changelog entries. See the roadmap article for the full timeline.
QR Codes and Attribution
Printed QR codes point to a short redirect (weboustaou.fr/q/{code}) instead of a fixed URL, so a code on a menu or a window sticker can be re-pointed without reprinting. Scans are logged with no PII and broken down by device and day. Recent work adds traffic-origin attribution, distinguishing QR scans, direct visits, and tracked links.
Billing, Security, and Compliance
Subscriptions run on Stripe (hosted Checkout and Customer Portal). They're mirrored into Supabase and kept in sync by webhook rather than treated as a live source of truth, so billing status stays queryable and RLS-protected like everything else. Pricing is flat and commission-free by design. No per-order cut, whatever the business eventually sells online.
Compliance is a first-class concern, not an afterthought: GDPR account deletion, a consent banner, opt-in analytics, per-field public-disclosure controls (an owner explicitly chooses to publish their address or phone number), and data hosted in the EU.
A Real Customer: Darius Pizza
Darius Pizza, my parents' pizzeria in Cavalaire-sur-Mer, was WebOustaou's first customer before WebOustaou was a product. Three years after moving off a Facebook page, it ranks #2 on Google for "Pizza Cavalaire" (up from 8th), gets roughly 3,800 visits a month (up from about 600), and scores 98/100 on mobile performance. The full story, including what's still mid-migration onto the newer platform, is in this case study.
Technical Architecture
- Framework: Next.js (App Router), 3 apps in one npm-workspaces monorepo
- Language: TypeScript throughout
- Backend & Auth: Supabase (Postgres, RLS-first, Auth with email + Google OAuth)
- 15 internal packages:
ui,i18n,shared,urls,tenant,auth,analytics,consent,consumer-data,consumer-query,docs-content,docs-reader,editor, and others, versioned and published to a private registry - Billing: Stripe (Checkout, Customer Portal, webhooks)
- Styling: Tailwind CSS, shadcn/ui
- Bot protection: Cloudflare Turnstile
- Hosting: Vercel, EU region
The architecture is deliberately split by compile boundary, not just by folder. The marketing app cannot pull in Stripe, Supabase, or QR code, and that's not just convention: an automated dependency test enforces it.
Where It Stands Today
WebOustaou reached v0.10.0-beta in July 2026, the point where, in the team's own words, "the core product is functionally complete." What remains before onboarding real customers beyond Darius is a focused polish pass. The next phase moves from finishing the platform to using it to build real customer sites, then to online ordering.
What This Project Represents
This is the clearest example in my portfolio of thinking like a systems architect applied to a product I own end to end. The schema and package structure were designed for multi-location management, security, and a five-phase roadmap from day one, not retrofitted once it started to hurt. See the second WebOustaou entry for what's designed next: ordering, kitchen displays, and beyond.
Takeaway
WebOustaou is what happens when you take the discipline of aeronautical systems engineering (traceability, RLS by default, additive-only schema migrations, a written rationale behind every non-trivial decision) and apply it to a small business's website. Nothing flashy about it, and that's the point. It just works, for a real business, every day.
