FoodDay
Multi-Restaurant Ordering SaaS
FoodDay is a multi-tenant SaaS food ordering platform built on the "build once, sell to many" model. The product needed to serve multiple restaurant businesses simultaneously from a single codebase, with each client getting a branded experience, their own admin dashboard, and full feature parity across Web, PWA, Android, and iOS — all from a v1 launch.
Quick facts
- Client
- FoodDay
- Role
- Product Owner & PM
- Category
- SaaS · Food Tech
- Year
- 2019
- Duration
- 8 months build + 12 months iteration
4
Platforms shipped
30%
Adoption growth
Multi-tenant
SaaS architecture
v1 Day-1
Core features shipped
Background & context
The food delivery market was consolidating around large aggregators (Swiggy, Zomato) who charged high commissions. FoodDay's proposition was direct-to-restaurant ordering — a white-label platform that restaurants could own, without paying per-order commissions to aggregators. The business model required a highly efficient multi-tenant architecture and a product polished enough to compete with the aggregator apps that customers were already familiar with.
The challenge
What made this hard.
01
Four platforms, one codebase, one timeline
Delivering feature parity across Web app, PWA, Android, and iOS simultaneously is technically and organisationally complex. Different teams, different deployment pipelines, different testing requirements — all converging on a single go-live date with multiple restaurant clients waiting.
02
Multi-tenant architecture that could actually scale
A naive multi-tenant implementation — separate databases per client, manually provisioned — would not scale commercially. The architecture needed to support rapid client onboarding without engineering intervention, with tenant isolation at the data layer and configurable branding at the application layer.
03
Balancing multiple clients' competing feature requests
As Product Owner, I was simultaneously managing feature requests from multiple restaurant clients with different menus, workflows, and customer bases. Every customisation request needed to be evaluated against the platform roadmap — building for one client's specific needs risked fragmenting the codebase.
The approach
How we solved it.
Defined the multi-tenant architecture before writing a line of product code
The first sprint was entirely architecture: tenant data isolation model, configuration schema, branding system, and deployment pipeline. Getting this right upfront prevented the painful refactoring that multi-tenant platforms typically require when they outgrow their original single-tenant assumptions.
Shared component library as the foundation
React and React Native shared a component library that encapsulated all UI decisions. The web app, PWA, and mobile apps all drew from the same component pool — different platform containers, same UI logic. This eliminated the "drift" that typically occurs when four separate teams build the same feature four different ways.
Product canvas for every feature request
For every incoming client feature request, I applied a simple product canvas: Does this serve the majority of tenants? Is it configurable vs. custom? What is the implementation cost vs. commercial value? This framework kept the backlog focused on platform capabilities rather than bespoke builds.
Analytics-led post-launch iteration
After launch, I instrumented the platform with event tracking across all four channels and ran bi-weekly analytics reviews with each client. Feature prioritisation in the post-launch roadmap was driven entirely by usage data, not by the loudest client voice.
Impact & outcomes
What we delivered.
Full feature parity across Web, PWA, Android, and iOS at v1
All four platforms shipped simultaneously with identical feature sets — real-time order tracking, secure payments, restaurant admin dashboard, chatbot-based ordering, and loyalty features.
30% growth in platform user adoption post-launch
Analytics-led backlog refinement in the months after launch drove measurable user adoption growth across the platform. Features were added based on what users were actually doing, not what clients assumed they wanted.
Multi-tenant architecture enabled zero-engineering client onboarding
New restaurant clients could be onboarded — branded, configured, and live — without any engineering work. The commercial team could close a client and have them live within 48 hours.
Chatbot ordering feature drove higher average basket size
The conversational ordering flow, integrated directly into the platform, showed higher average basket size compared to the traditional menu-browse-checkout flow.
Tools & technologies
Lessons learned
What this taught me.
Multi-tenant SaaS architecture decisions made in week one compound for years. The investment in getting the data isolation and configuration model right before building any features paid back many times over.
As a product owner serving multiple clients, your job is to find the abstraction that serves everyone — not to build the specific thing each client is asking for. Most of the time, clients are describing a symptom, not prescribing the solution.
Analytics instrumentation is not a post-launch consideration. If you cannot measure whether a feature is being used, you cannot make good decisions about what to build next.
Next case study
Enterprise Conversational AI →