TL;DR
- Context: CTO at a seed-stage startup navigating multiple GTM pivots under tight runway
- Problem: Platform choices tied to early assumptions broke as GTM strategy evolved
- Intervention: Reframed “mobile rewrite” as a capability problem and reused the web stack
- Impact: Shipped iOS and Android in ~4 weeks while reusing ~90% of existing code
Intro
This work was done as part of my full-time role as CTO during a period of rapid go-to-market experimentation. Over ~12 months, the company underwent two major pivots: first in GTM motion, and then across platforms. Each pivot invalidated prior platform assumptions, creating a real risk of repeated rewrites consuming runway.
Problem
- Early platform decisions encoded GTM assumptions that later became invalid
- Web-first architecture broke core loops once the product shifted to end users
- Native capabilities (push, auth, real-time engagement) became non-negotiable
- A full mobile rewrite would have repeated a previous 6-month setback
Intervention
- Reframed the question from “How do we rebuild the app?” to “What native capabilities do we actually need?”
- Treated mobile as a delivery shell, not a separate product
- Selected a runtime that maximized reuse of the existing web stack
- Validated all major risks with a rapid proof-of-concept before committing
Impact
- iOS and Android apps shipped to production in ~4 weeks
- ~90% of the web codebase reused with minimal native surface area
- Feature updates could ship instantly without app store resubmission
- Platform risk reduced without another long rewrite cycle
Why This Matters
Platform migrations are rarely technical failures, rather delayed corrections to earlier product assumptions. The ability to reframe platform strategy around capabilities instead of frameworks can preserve both velocity and runway when GTM is still in flux.
Technical Deep Dive (Optional)
This section expands on platform decisions, validation steps, and quantitative outcomes for readers who want technical depth.
View technical deep dive
Pivot Timeline
Phase 1: App → Web
- Initial GTM focused on creators
- Users resisted installing another app for content consumption
- Moved to web to unlock SEO and discoverability
- Total cost of transition: ~6 months (see separate case on stack reset)
Phase 2: Web → App
- GTM shifted toward end users and engagement loops
- Core mechanics required:
- Reliable push notifications
- Real-time interaction
- Faster return sessions
- Web constraints became a growth limiter
Capability-First Reframe
Instead of rebuilding a native app from scratch, requirements were distilled to:
- Push notifications (reliable, native)
- Native authentication (Google / Apple)
- Video playback and payments
- Fast update and iteration cycle
Anything beyond these was treated as optional.
Platform Choice: Capacitor
Why Capacitor
- ~90% reuse of existing Next.js codebase
- Native API access via plugins
- Web-first development model
- Remote updates without app store resubmission
Rejected Alternatives
- React Native rewrite (high duplication, long lead time)
- Fully native apps (maximum control, unacceptable cost)
Risk Validation (8-Hour PoC)
Before committing, all major failure modes were validated in ~1 day:
- Authentication: native plugins
- Push notifications: native plugins
- Video playback: plugin-based
- Payments: integrated successfully
- JS bridge limitations on iOS: required a custom plugin
This reduced unknowns before execution.
Execution & Delivery
Timeline
- Sprint 1 (2 weeks): Core app functionality
- Sprint 2 (2 weeks): Hardening, QA, store readiness
Quantitative Outcomes
- Code reuse: ~90%
- Native code: <10% of total codebase
- Average TTFI: ~2s
- Update latency: 2–3 days → near-instant via remote pushes
Final Platform Characteristics
- Single web-first codebase driving web, iOS, and Android
- Native capabilities layered only where required
- Update speed decoupled from app store review cycles
- Platform optionality preserved for future GTM shifts
Key Lessons
- Platform decisions encode GTM assumptions — premature lock-in compounds cost
- Native UX ≠ native UI — most startups need capabilities, not custom views
- Optionality preserves runway — reuse beats rewrites under uncertainty
- Fast validation beats confident assumptions — PoCs prevent expensive mistakes
Platform migrations completed during the seed stage under active GTM iteration.