Web & mobile
Choosing between React Native and native for a small team
Cross-platform is not a compromise, and native is not a luxury. The four questions that actually decide it.
5 min readByteWeave Studio
The framework debate is usually argued on performance, which is the least useful axis for a small team. Modern React Native is fast enough for the overwhelming majority of applications, and a badly built native app is slower than a well built cross-platform one.
The question that matters is how many people you have and what the app has to touch. Four things decide it, and none of them are frame rates.
How many engineers can you keep on it
Two native apps need people who know both platforms, or two people. For a team of three or four building a product that also has a backend and a web surface, that is the whole team on mobile and nothing left over.
One shared codebase means one set of business logic, one release process, and one place a bug is fixed. This is the strongest argument for cross-platform and it is organisational rather than technical. It stops being decisive around the point you can staff a dedicated engineer per platform.
What the app has to reach
Straightforward CRUD, lists, forms, camera capture, push notifications and maps are all well served by the cross-platform ecosystem. If that is your app, the platform question is close to settled.
It changes if you depend on something at the edge of the platform: continuous background location, tight Bluetooth peripheral work, custom video pipelines, widgets and complex system extensions, or a hardware SDK that ships native-only. You can bridge to native from React Native, and that is a normal thing to do — but if you are writing bridges for the core of the product rather than the periphery, you have chosen the harder path to the same place.
How much the interface should feel like the platform
A branded product surface — a booking flow, a dashboard, an ordering app — should look like itself on both platforms, and shared code gets you there faster with less drift.
An app whose value comes from feeling native, or one leaning heavily on new platform UI conventions the moment they ship, is a poorer fit. You will spend the saved time reimplementing platform behaviour, and it will lag the real thing by a release or two.
Who maintains it in two years
This is the question teams skip and later regret. Cross-platform means one upgrade treadmill instead of two, but it is a treadmill with more moving parts: the framework, the native toolchains underneath, and the third-party modules in between. A dependency that stops being maintained is a real risk and it is worth auditing before you adopt one.
Native means two codebases to keep current, but each is upgrading against a single vendor with predictable release cycles and long deprecation windows. For a team that will be small indefinitely, one treadmill usually wins. For a team that expects to grow into platform specialists, the second option ages better.
- React Native
- Mobile
- Architecture
- Product
More reading
Web & mobile
Prerendering a React SPA for SEO without switching to Next.js
A Vite SPA serves crawlers an empty div. You can fix that in about a hundred lines without adopting a framework or a server.
6 min read
Document AI
Why your invoice OCR works in testing and fails in production
The test folder is clean exports. The real intake is phone photographs. What changes between the two, and how to find out before a client does.
5 min read
LLM engineering
Why your RAG demo works and your RAG product doesn’t
A retrieval demo on twenty documents proves almost nothing about the same system on twenty thousand. The four things that break in between.
6 min read
Have a problem
worth solving?
Tell us what you're building. We'll help you figure out what's possible — and say so if we're not the right people for it.