One Backend, Three Surfaces: Web, React Native, and Flutter
Shipping the same product to a Next.js web app, a React Native app, and a Flutter app at once forces a clarity about where the logic actually lives.
I work across several concurrent products, and more than once the same feature has to land on a Next.js web dashboard, a React Native screen, and a Flutter screen. Three surfaces, one product.
The only way that stays sane is to keep the logic on the server. The NestJS API owns the rules; the clients own presentation and interaction. If a client is making a business decision, that decision is in the wrong place.
It also changes how you design endpoints. A screen-shaped API — one call that returns exactly what a screen needs — beats a chatty REST-purist one when you're feeding three different UIs that each want the data arranged their own way.
React Native and Flutter each have their moment: React Native when the team already shares React muscle memory, Flutter when the UI is heavy and custom. But the backend doesn't care which one is calling — and that's exactly the point.
