TAKES
What should our mobile strategy be?
Every stack is right for some company, at some stage.
EVERYONE'S RIGHT
Every answer
AlexThe Architect“Two native apps. Share the model, not the UI.”
JoThe Cowboy“React Native. One repo. Both stores by Friday.”
RileyThe Minimalist“The website already works on phones.”
TaylorThe AI Native“Build three clients. Let the agents maintain them.”
MorganThe Threat Modeler“Native, if the phone is becoming a credential.”
ChrisThe Sovereign“PWA. No gatekeeper gets to revoke our app.”
PatThe Enterprise Adult“Both native. Supported platforms are part of the product.”
MayaThe Visionary“iPhone first. If they love it, Android next month.”
NoraThe User Advocate“Whichever phones our users actually have.”
HugoThe Perfectionist“Swift and Kotlin. If we're doing mobile, do mobile properly.”
RuthThe Maintainer“Start with the web. I've maintained three ‘write once, run anywhere’ eras.”
GregThe Hedger“React Native. Keep every native escape hatch open.”
🎯 SUPER REASONABLE
Super Reasonable, the advisor who never takes a side
There is no correct mobile stack independent of the product. Start with the cheapest client that can answer the next important product question, and go native when the product, the users or the device capabilities prove that native is what you are actually buying. Keep API and domain contracts independent of the client, so this year's choice does not become the company's permanent architecture.
- Does anyone need an installed app? If the responsive site does the job, native has to earn its complexity.
- Which phones do real users carry? Read traffic and account data, not the team's pockets.
- What truly needs native? Push, background work, Bluetooth, credentials, payments, raw performance.
- What can the team sustain? Two native apps and one overloaded engineer is not a strategy.
📚 Seen in the field: Try everything · The button that does nothing
🔬 IN THE FIELD GUIDE
