Platform Strategy · 1→N
As Rebel Foods expanded its D2C footprint, every new storefront risked becoming another independent engineering project. Catalogue, cart, checkout, discounts, payments and tracking repeated across brands, but improvements in one stack did not compound across the portfolio.
I helped shape a modular, multi-tenant platform that standardized repeated commerce capabilities while preserving brand identity and merchandising flexibility. The platform supported approximately 2M MAUs and 450–500K monthly orders, enabled the Faasos app to launch in roughly one week, and became a major enabler of India’s D2C mix increasing from 8% to 21%.
I helped lead the product strategy, platform scope and phased adoption approach across brand, engineering, growth, operations and leadership teams.
8% → 21%
India D2C web and app mix
~2M
MAUs supported
~450–500K
Monthly orders
~1 week
Faasos app launch
Standardise what repeats. Preserve what differentiates.
01 · The Repeated Constraint
Every brand needed differentiation, but rebuilding the same commerce stack independently destroyed speed, consistency and leverage.
01
Repeated commerce capabilities rebuilt per brand
02
Improvements did not propagate across storefronts
03
Experiences, analytics and release cycles diverged
04
Launches and migrations became slower
05
Engineering effort was spent, not compounded
Decision Sequence
The constraint was not the number of features we lacked. It was that the same capabilities had to be rebuilt repeatedly.
02 · Strategic Choice
How do we standardise what repeats without flattening what differentiates?
Option 01
Continue brand-specific stacks
Advantage: Maximum local control and minimal immediate migration risk.
Why rejected: Repeated work, inconsistent foundations and slow rollout remained structural problems.
Option 02
Build one monolithic shared storefront
Advantage: Maximum standardisation and simpler shared ownership.
Why rejected: Brand differentiation became expensive and local exceptions risked turning the platform into a central bottleneck.
Option 03 · Chosen
Build a modular multi-tenant platform
Advantage: Shared commerce infrastructure with brand identity, merchandising and commercial configuration separated into configurable layers.
Risk: A platform only creates leverage if brands trust and adopt it.
Standardisation without autonomy would have created a different scaling problem.
03 · Platform Boundary
Brand teams were not resisting reuse of payments, checkout or tracking. They were resisting the loss of control over identity, merchandising and customer experience. Making that boundary explicit changed the adoption conversation.
Layer 01 — A · Shared Commerce Core
Layer 02 — B · Shared Operating Foundation
Layer 03 — C · Configurable Brand Layer
A modular model allowed shared capabilities to evolve once while keeping brand differentiation configuration-led rather than engineering-led.
04 · Prove Before Scaling
The Behrouz migration became the operational proof that the platform could support a meaningful brand without compromising revenue or customer experience.
A · Why Behrouz
Behrouz had meaningful D2C traffic, strong brand identity and enough scale to expose migration, conversion and performance risks.
B · Controlled rollout
C · Business + CX Guardrails
The rollout was governed by predefined business and CX thresholds rather than technical completion alone.
D · Proof of Leverage
~1 week
Faasos app launch
Once the shared components were stable, the Faasos app launched in roughly one week — evidence that platform reuse had converted into materially faster execution.
05 · Adoption
I did not try to win adoption through architecture arguments. The platform had to prove that reuse improved business outcomes without removing brand control.
Concern 01
Brand identity and roadmap control
Response
Separate shared infrastructure from configurable brand experience.
Concern 02
Revenue and conversion risk
Response
Use phased rollout, pre-agreed thresholds and progressive migration.
Concern 03
Cross-team ownership
Response
Create shared dashboards, common metrics and explicit migration accountability.
Concern 04
Delayed platform value
Response
Translate the platform into business outcomes — launch speed, reliability, customer ownership, first-party data and margin control.
Standardisation
Creates reuse and consistency.
Autonomy
Protects brand differentiation and local commercial control.
The platform had to create leverage without becoming a centralized bottleneck.
06 · Outcomes
Group A · Platform Leverage
~1 week
Faasos app launch
Group B · Scale Supported
~2M
MAUs supported
~450–500K
Monthly orders supported
Group C · Business Outcome Enabled
8% → 21%
India D2C web + app mix
Group D · Operating-Model Change
The D2C mix shift was a company-level outcome influenced by multiple product, growth, brand and operational initiatives. The platform was a major enabler, not the sole cause.
Before → After
Brand stacks
Feature development
Differentiation
Platform health
07 · Reflection
Platforms create leverage only when teams adopt them because business outcomes improve, not because the architecture is cleaner.
01 · What worked
Separating shared infrastructure from brand identity made the platform strategically useful without making brands feel interchangeable.
02 · What I would change
I would define the platform operating model earlier — decision rights, migration ownership, adoption metrics and a cross-team review cadence — rather than focusing first on architecture and delivery.
03 · What success should have included from day one
Platform success should have been measured through reuse, adoption, launch speed, reliability and incremental business leverage, not migration completion alone.
04 · What I took forward
Platform work compounds only when architecture, incentives and operating ownership reinforce one another.
I did not prioritise features. I prioritised the repeated constraint.
Next case study