A Kitchen Before a Codebase
I grew up in a family of butchers and pizza makers. From fifteen, I worked the line — kitchens, prep, the rhythm of service, and every frustration that comes with running a small food business. Years later, as a developer, I recognized those same frustrations from a different angle: the independent restaurateurs I knew had exactly three options for a digital presence — overpay an agency, wrestle with a generic website builder that fights the way a restaurant actually operates, or depend on someone else (often me) for every small update.
None of it was built for them. So I built what I wished had existed.
The First Version Wasn't a Product
WebOustaou didn't start as a SaaS platform. It started as a private backend for one business: Darius Pizza, my parents' pizzeria in Cavalaire-sur-Mer. Before that backend existed, their "back-office" was a set of keys in an Upstash Redis instance — no source of truth, no database, nothing my parents could touch themselves. When the menu changed or the hours shifted for the season, I edited JSON by hand.
That's not a criticism of an early hack — it's the honest starting point of most real products. The first working version of WebOustaou modeled exactly one tenant, in a pure Supabase schema, with no authentication and no admin UI at all. It solved one real, specific, embarrassing problem before it tried to solve a general one.
What Small Businesses Actually Deal With
Once that first version worked, the pattern became obvious — because it wasn't specific to pizza. Small businesses face the same handful of constraints, whatever they sell:
- Limited time and limited technical knowledge
- Multiple disconnected tools that don't talk to each other
- Weak defaults on security, authentication, and compliance
- Software priced and built for chains, not for one or two locations
Most restaurant software on the market solves this by either being too expensive, too complex, or by taking a commission on every order — which punishes a business for succeeding. None of it does right by an owner who just wants their menu correct, their hours accurate, and their site fast, without becoming a part-time IT administrator.
Building the Foundation First
The decision that shaped everything after was to solve the foundation layer before any business-specific feature: accounts, tenancy, security, internationalization, compliance. Multi-tenancy, row-level security on every table, and JSONB-based i18n were all designed into the schema from the very first migration — when there was exactly one customer and no authentication system to enforce any of it yet.
That looks like premature engineering until you understand the constraint I was actually working under: the schema is additive-only. Every future phase has to be absorbed by extending what exists, never by rewriting it. Retrofitting tenancy or security after the fact would mean a rewrite and a full security re-audit; a few extra columns and predicates on day one avoid that entirely. It's the same discipline I use professionally as a systems architect — decide the parts of the system that are expensive to change later, and get those right first, even when the first customer doesn't need them yet.
Where That Choice Led
A year on, that foundation now runs a real multi-tenant platform: an admin workspace, a public marketing site, and a forkable consumer-site template, serving restaurants beyond the one that started it — with online ordering, kitchen displays, and more designed to land on the same foundation without another rewrite. The full architecture is here, the roadmap is here, and Darius Pizza's own results are here.
Why It Still Matters to Me
Every product decision at WebOustaou passes through someone who has actually worked a kitchen line and actually watched a family business struggle with software that wasn't built for it. That's not a marketing line — it's the reason the project exists at all, and the reason I'd rather ship a smaller feature set that genuinely works for an independent restaurant than a large one that half-fits a chain's needs.
The mission is simple to state and hard to deliver: give every independent restaurant the same quality of digital tools as a chain, without the complexity, and without a cut of every order.