Introduction
If you've ever worked at a startup, you know the golden rule: pick one tech stack and stick with it. Having Flutter screens mixed with React Native and Kotlin is usually a recipe for disaster—a maintenance nightmare that makes every engineer cringe.
But what if I told you that companies like PhonePe, Paytm, and Gojek intentionally run multiple tech stacks in the same app? And they're not just surviving—they're thriving.
Here's why this "anti-pattern" becomes a superpower at massive scale, and why you probably shouldn't try it at your startup.
The Super App Problem
Imagine you're building PhonePe. You're not just building an app—you're building an ecosystem:
• UPI payments (millions of transactions per day) • Mutual funds investment platform • Insurance marketplace • Bill payments • Recharge services • Shopping features • Gold purchases • And 20 more services launching next quarter
You have 500+ engineers, organized into autonomous pods. Each pod owns a complete vertical—from backend to mobile to analytics. The UPI team has been perfecting their Kotlin implementation for years. The mutual funds team wants to move fast with React Native. The new insurance team believes Flutter is the future.
The question isn't "should we use multiple stacks?"—it's "how do we empower 15 independent teams to move at startup speed?"
The Modular Architecture Approach
Here's how these companies actually structure their apps:
- App Shell (Native Kotlin): Navigation framework, Authentication, Analytics layer, Design system
- Feature Pods (Independent Modules): UPI Pod → Native Kotlin (Performance critical), Mutual Funds → React Native (Fast iteration), Insurance → Flutter (Cross-platform reuse), Shopping → Native Kotlin (Deep integration), Bill Payments → React Native (Shared with web)
Each pod is essentially a mini-app that plugs into the main container. They communicate through well-defined interfaces but are otherwise independent.
Why This Works at Scale
Not all features are created equal. Understanding when and why to use different tech stacks is crucial for success at this scale.
1. Team Autonomy = Velocity
When you have 50 engineers working on mutual funds, they shouldn't be blocked by the UPI team's sprint planning. With their own tech stack:
• They deploy independently • They hire specialized talent • They experiment without affecting others • They own their entire feature lifecycle
Result: Features that would take 6 months in a monolithic architecture ship in 6 weeks.
2. Right Tool for the Right Job
Not all features are created equal:
- UPI transactions need maximum performance and security → Native Kotlin, battle-tested, zero compromise
- Experimental features need rapid prototyping → Flutter/React Native, iterate quickly, fail fast
- Content-heavy screens benefit from web technologies → React Native with web code sharing
Why force the insurance team to write native code when they could ship 3x faster with Flutter?
3. Acquisition Integration
Large companies acquire startups regularly. If PhonePe acquires a fintech startup built entirely in Flutter:
• Option A: Rewrite everything in Kotlin (6-12 months, high risk) • Option B: Integrate as a Flutter module (2-4 weeks, low risk)
The modular approach makes acquisitions seamless.
4. Failure Isolation
If the mutual funds module crashes, the UPI transactions continue working. In a monolithic app, one team's bug can bring down the entire application.
5. Specialized Hiring
Instead of requiring every engineer to know Kotlin, React Native, AND Flutter:
• UPI team hires expert Android developers • Mutual funds team hires React Native specialists • Platform team hires systems engineers
Everyone works in their area of expertise.
The Platform Team: The Secret Ingredient
Here's the crucial part most articles miss: this only works with a world-class platform team.
The platform team provides shared infrastructure, developer tools, and governance that make the multi-stack approach viable.
Developer Tools
- Module template generators
- Testing frameworks
- CI/CD pipelines for each tech stack
- Documentation and best practices
Governance
- Code review standards
- Security audits
- Performance benchmarks
- Architecture decision records
Without this team, you just have chaos.
Real-World Examples
Several major companies have successfully implemented multi-stack architectures:
- PhonePe / Paytm (India): Multiple verticals with independent teams. Started native, strategically adopted cross-platform for new features.
- Gojek (Southeast Asia): 20+ services in one app. Different services use different tech stacks based on team expertise and requirements.
- WeChat (China): Mini-programs architecture allows third-party developers to build features using their own preferred frameworks.
- Airbnb (Pre-2018): Used React Native for specific features while maintaining native core. Eventually moved back to native, but the experiment taught the industry valuable lessons about when hybrid makes sense.
Why This Will Destroy Your Startup
Now, here's the uncomfortable truth: If you're not at PhonePe's scale, this approach will sink you.
You Don't Have the Numbers
Multiple tech stacks require:
- 500+ engineers minimum to justify dedicated teams
- Platform team of 20-30 engineers just for infrastructure
- Dedicated DevOps for each tech stack
- Specialized recruiters for different skill sets
Your 15-person startup can't afford this.
The Technical Debt Trap
What starts as "just one Flutter screen" becomes:
- One screen needs navigation → Custom bridge code
- Navigation needs state management → More glue code
- State management needs data sharing → Complex architecture
- Now you have two codebases to maintain forever
At small scale, the coordination cost exceeds the benefit.
The Team Problem
With a small team:
• Every developer needs to know multiple stacks • Code reviews become inconsistent • No one is an expert in anything • Context switching destroys productivity
The Threshold Question
When does it make sense to adopt this approach?
Here's a framework:
✅ You're Ready If:
- 500+ mobile engineers across multiple teams
- Clear pod/vertical structure with independent ownership
- Dedicated platform/infrastructure team (20+ engineers)
- Proven ability to maintain large-scale systems
- Budget for increased app size and build complexity
- Strong engineering leadership and governance
❌ Stay Away If:
- Less than 100 engineers
- Single mobile team
- No dedicated platform team
- Struggling with current tech stack
- Tight budget or timeline constraints
- Still figuring out product-market fit
The Migration Path (If You're Growing)
If you're scaling up and considering this approach:
- Phase 1: Monolithic Native (0-50 engineers): Build everything in Kotlin/Swift. Stay focused.
- Phase 2: Strategic Hybrid (50-200 engineers): Add React Native or Flutter for specific, isolated features. Test the waters.
- Phase 3: Modular Architecture (200-500 engineers): Build platform team, establish module boundaries, create governance.
- Phase 4: Multi-Stack Ecosystem (500+ engineers): Different teams can choose appropriate tech stacks within guidelines.
Most companies should stop at Phase 2.
Key Takeaways
- Multiple tech stacks are a solution to organizational scale, not a technical preference
- It works for PhonePe because they have the infrastructure, team size, and governance to support it
- The platform team is the linchpin—without it, you just have technical debt
- For most companies, the coordination cost exceeds the benefit
- It's better to be excellent at one stack than mediocre at three
Conclusion
The next time someone tells you "PhonePe uses multiple tech stacks, why can't we?"—now you have the answer.
Yes, they do. And it works brilliantly for them because they have 500+ engineers, a dedicated platform team, clear module boundaries, and a decade of experience building at scale.
For your 20-person startup? Stick with Kotlin or Flutter. Master one stack. Move fast. Ship features.
The right architecture isn't the one that works for PhonePe—it's the one that works for you at your current scale.