Product Journey · 0→1 to Growth System
Rebel controlled kitchens, brands and fulfilment, but more than 90% of revenue depended on aggregators that controlled customer demand. I helped build EatSure as a first-party demand engine, then evolved it from a 0→1 launch into a reusable growth system across discovery, experimentation and activation.
The platform grew to ₹16 Cr+ in monthly revenue, 4.5–5 lakh monthly orders and 45+ cities. More importantly, the work created reusable capabilities across migration, experimentation, personalisation and activation.
₹16 Cr+
Monthly revenue
4.5–5L
Monthly orders
45+
Cities
400+
Kitchens supported
Act I
Build direct demand
Act II
Build experimentation capability
Act III
Own activation end to end
Why EatSure Existed
More than 90% of revenue flowed through Swiggy and Zomato. Rebel had supply-side control but lacked a first-party demand layer.
Controlled Supply
The Gap
No direct demand
Aggregator Dependence
90%+
of revenue via Swiggy & Zomato
EatSure closes the loop
First-party demand layer connecting controlled supply to the customer
Strategic Choice
The challenge was not building an app. It was creating direct customer demand without disrupting existing revenue or breaking multi-brand fulfilment.
Option 01
Improve individual brand websites
Preserved fragmented demand and duplicated customer experiences.
Option 02
Build another aggregator-like marketplace
Required competing on breadth, discounts, logistics density and habit where incumbents already had structural advantages.
Option 03 · Chosen
Build a brand-first multi-brand D2C platform
Connected Rebel's unique assets — kitchens, brands, fulfilment and first-party data — into one multi-brand customer proposition.
Act I
I did not build another food-delivery app. I helped Rebel build an independent demand engine.
A · Migration Wedge
The Faasos app already had approximately 250K active downloads. Approximately 50K power users formed the initial migration wedge. Phased migration reduced acquisition risk, protected revenue, preserved trust, and let us learn from high-intent users.
Faasos → EatSure migration
Existing asset
Faasos app
~250K active downloads
Wedge
~50K power users
Phased rollout
Destination
EatSure
Multi-brand platform
B · Product Proposition
EatSure was designed as one multi-brand customer destination rather than a collection of brand storefronts — combining brand choice, coordinated fulfilment and a first-party customer relationship.
01
One destination
A single app where customers could order across all Rebel brands.
02
Multi-brand basket
One order combining meals from different brands in one delivery.
03
First-party relationship
Direct customer data, loyalty and experience — no aggregator in between.
C · Operational Complexity
Multi-brand ordering required coordinating preparation times, batching, packaging, inventory availability and delivery inside one customer experience.
D · Scale and Validation
The combined launch, migration and scale work contributed to the outcomes below. Not every outcome was caused by one feature.
Monthly revenue
App launch time
App rating
In hindsight, I would have separated migration safety, proposition validation and growth into clearer workstreams earlier, with distinct ownership, instrumentation and decision cadences.
Act II
The storefront was not constrained by ideas. It was constrained by the ability to test them.
A · The Architectural Shift
The EatSure homepage had become a growth bottleneck. Hypotheses accumulated faster than the team could test them because every meaningful change required engineering, QA and a coordinated release.
Before · Static artifact
Hardcoded homepage
Monolithic page build
Engineering release per test
Bespoke analytics per experiment
After · Composable platform
Composable API-driven modules
Configurable experiments
Shared instrumentation
Guardrails on every test
The homepage became an output of the system, not a hand-coded artifact.
B · Sequencing
Personalisation was layered on top of a working discovery system, not used to mask broken discovery.
C · Reliability Guardrails
As experimentation and personalisation added complexity, performance and fallback behaviour became conversion constraints.
Constraint
Decision
Trade-off
Outcome
Personalisation adds latency
Graceful degradation
Default experience on failure
Storefront stays transactional
Slow pages cost conversions
Performance budgets
Complexity capped per surface
Fast under load
Experiments can block orders
Never block a transaction
Revenue protection over test purity
Revenue protected during iteration
D · Outcome
It was the ability to improve the storefront continuously without rebuilding it for every hypothesis.
Home → Product Add · ~1 year
Act III
Activation is not onboarding. It is removing friction in the order it blocks progress.
A · Map the Complete Funnel
Different teams were improving app launch, onboarding, permissions and homepage entry independently. The constraint was fragmented funnel ownership and unclear sequencing.
Before · Fragmented
App launch team optimizes launch
Onboarding team optimizes screens
Permissions team optimizes grants
Gains leak at the next step
After · End-to-end ownership
Map the whole funnel
Sequence friction by leverage
Shared hierarchy across teams
Gains compound
B · Prioritise Friction by Leverage
Hard friction was solved first because downstream behaviour could not be measured reliably when users could not enter the experience.
Solve top to bottom
Hard friction
Friction that stops a user from progressing at all.
Cognitive friction
Friction that makes a user unsure what to do next.
Trust friction
Friction where a user is willing but not confident.
Experience friction
Friction in the flow itself — refined once the first three are stable.
C · Representative Interventions
The work focused on launch reliability, onboarding compression, permission fallbacks and serviceability expansion protected by guardrails.
Onboarding
5 screens → 3 screens
The removed screens asked for commitment before the product had established enough value.
Permissions
Fallback paths instead of hard gates
A denied permission no longer ended the activation journey. Users could continue through a fallback and grant access later.
D · Outcome
App Launch → Homepage improved over approximately 18 months. Onboarding and permission interventions are shown separately as interventions, not business outcomes.
App Launch → Homepage · ~18 months
Leadership Across the Journey
Growth, Engineering, Design, Analytics, Operations, Brand and Business teams had to move around shared outcomes and sequencing rather than direct authority.
01
Align around one causal metric system
Connect input metrics, funnel conversion and business outcomes so teams do not optimise local steps independently.
02
Prioritise dependencies before features
Solve upstream constraints — migration safety, experimentation architecture and launch reliability — before scaling downstream optimisation.
03
Protect the existing business while building the new one
Use phased migration, fallbacks, performance budgets and operational guardrails to reduce revenue and customer-risk exposure.
04
Translate foundational work into business language
Explain why architecture, instrumentation and reliability investments unlock revenue, speed and customer experience.
System Impact
An executive recap of the durable business, product and operating-model outcomes.
Business
Product system
Operating model
What I Took Forward
I started by solving a launch problem. I left with a broader understanding of how growth compounds through systems — migration foundations, experimentation infrastructure and end-to-end funnel ownership.
What worked
Sequencing the work around the highest dependency created more leverage than pursuing isolated feature wins.
What I would change
I would separate migration safety, proposition validation and growth into clearer workstreams earlier, with independent instrumentation and decision cadences.
What it prepared me to lead next
The experience prepared me to lead broader product systems where customer experience, platform architecture, operations and growth must move together.
Next case study