React Native
React Native architecture decisions that become expensive later.
September 17, 2026 · 7 min read
React Native makes starting cheap. Some decisions made in the first few weeks are much harder to reverse than they look, and they tend to show up again a year later.
Letting components own data fetching
Fetching inside screens is fast to write and hard to evolve. When offline support, caching or a new backend arrives, the change touches every screen. A thin repository layer from day one costs little and keeps that change local.
Treating native code as someone else's problem
Sooner or later — BLE, NFC, background work, a payment SDK — you will need Kotlin and Swift. Teams that plan for native modules, with owners and tests, handle this calmly. Teams that avoided it tend to accumulate unmaintained third-party wrappers instead.
Postponing the release pipeline
Manual builds feel fine with one developer. With five, they become the bottleneck and the main source of release mistakes. Automated builds, signing and store delivery are some of the cheapest reliability wins in mobile.
I build and lead teams around systems where reliability matters. If you're designing an offline workflow, evaluating an architecture, or untangling a queue that has become part of your product, I'm happy to compare notes.
More writing
- Why Good Engineers Care About Failure Modes
Distributed Systems · 5 min read
- What Engineering Managers Should Actually Measure
Engineering Management · 6 min read
- The Difference Between Shipping Features and Shipping Systems
Engineering Management · 5 min read