How We Picked Flutter for Cerebyte and React Native for My Home Delivery

Stack choice is the most over-debated and under-explained decision in mobile development. Founders agonize over Flutter vs. React Native for weeks, then forget what they decided and why three months into the build. By month six, when something gets hard, the stack feels like an arbitrary constraint rather than a deliberate choice.

We try to write the reasoning down so it doesn't fade. Below are two of our recent builds — Cerebyte on Flutter, My Home Delivery on React Native — with the actual decision logic behind each. They're useful as examples because they pulled in opposite directions, and we picked deliberately for each.

Project 1: Cerebyte — why Flutter

The product: a wellness app that plays audio tracks derived from a user's real EEG brain-activity recordings. You wear an EEG headset, record a session, and the app generates and plays an audio composition based on the patterns in your brainwaves. The hard part is the audio engine.

The stack choice: Flutter + Node.js back-end.

What we considered

Cerebyte could plausibly have shipped on any of native, React Native, or Flutter. We considered all three.

Native iOS + Android was tempting because audio is one of the few categories where native APIs really do matter — AVAudioEngine on iOS and AudioTrack/Oboe on Android both expose low-level control that cross-platform wrappers don't always surface. The downside: two codebases for the audio engine itself, which meant duplicating the hardest, most-error-prone work.

React Native was on the list because the back-end was Node and the founder's small existing team had JS skills. But RN's audio story in 2024 was unimpressive — most of the well-maintained audio libraries were either iOS-only or wrapped basic playback, not the kind of real-time mixing and modulation Cerebyte needed. Going RN meant writing native modules for the audio engine on both platforms anyway, which mostly defeated the cross-platform value.

Flutter had the best audio-ecosystem in 2024 for what we needed. The flutter_audio family of plugins was active, the just_audio package supported the low-level controls we needed, and Dart's FFI made it straightforward to call C-level audio libraries when the Dart wrappers weren't fast enough. We could write the audio engine once in Dart, with thin native shims for platform-specific audio session management.

The deciding factor

The audio engine had to be written exactly once. Anything else made the build risk too high. Flutter let us do that with the best off-the-shelf tooling, and the cross-platform UI was a free side benefit.

We made the call in week 2 of discovery. The founder asked the obvious question — "but native would be more performant, right?" — and we walked through the numbers. The Flutter implementation was within 5ms of native on audio latency, well below the threshold where humans perceive it. The 5ms cost was worth not having to maintain two engines.

If you'd like us to make a similar call for your project — written reasoning included — book a two-week discovery and we'll deliver a stack recommendation you can challenge.

How it played out

Cerebyte shipped on iOS and Android in 14 weeks. The audio engine was the largest single piece of work, but because it was written once, the second-platform engineering cost was almost entirely UI polish and platform-specific permissions plumbing. We hit a few rough spots with iOS's audio session interruption handling (calls, alarms) and had to dig deeper than the Flutter abstraction wanted us to, but we never had to write a parallel engine. Stack choice held up.

Project 2: My Home Delivery — why React Native

The product: a two-sided marketplace where customers book big-and-bulky on-demand delivery (furniture, appliances) and drivers accept jobs from their phone. Real-time location tracking, multi-party payments (customer pays, platform takes a cut, driver gets paid), push notifications scoped per role.

The stack choice: React Native + Laravel back-end.

What we considered

A marketplace like My Home Delivery is, in a stack sense, the opposite of Cerebyte. There's no exotic hardware integration. The hard parts are payments, real-time tracking, and the operational complexity of running two simultaneous user roles in production. The mobile UX is standard marketplace shapes.

Native iOS + Android was overkill. The marketplace didn't need anything platform-specific enough to justify the doubled build cost.

Flutter was a fair option. The marketplace UX would have worked. But the founder had an existing Laravel back-end and a small team that knew React. Going Flutter meant introducing a third language (Dart) to a team that was already running PHP server-side and React in their web admin. That's a real onboarding cost.

React Native matched the team. The shared mental model between the web admin (React) and the mobile app (React Native) meant the founder's existing engineer could read and contribute to both. CodePush gave us a fast iteration loop after launch — we could push critical fixes without going through App Store review.

The deciding factor

Stack picks are often more about the team than the project. My Home Delivery's stack picked itself the moment we learned the founder's team was already a React shop. The cost of teaching them Dart, or hiring Flutter engineers separately from their existing JS hires, would have outweighed any technical advantage Flutter might have brought.

This is the under-mentioned half of stack decisions. The "best" stack for a project, in pure technical terms, is often not the best stack for a specific team. The right call respects both.

How it played out

My Home Delivery shipped in 16 weeks. The four key integrations — Stripe Connect for multi-party payments, real-time location tracking for drivers, push notifications scoped per role, and the Laravel back-end the founder already had — all landed in their planned sprints. CodePush became important post-launch when we pushed three small UX fixes in the first month that would otherwise have waited 5–7 days each for Apple review.

The choice held. Six months in, the founder hired their first internal mobile engineer; they hired a React Native developer in a week. If we'd picked Flutter, that hire would have taken longer and cost more.

What these two decisions have in common

Look past the surface (different stacks, different categories) and the decision logic is identical:

1. Identify the hard part of the project. For Cerebyte, audio. For My Home Delivery, integrations + team fit.
2. Pick the stack that makes the hard part easiest — without making the other parts noticeably harder.
3. Write down the reasoning so it survives the inevitable week-12 frustration where the stack feels arbitrary.

The framework is simple. The discipline is in resisting the urge to pick based on what's trendy, what your favorite blog post recommended, or what the loudest engineer in the room prefers.

A few common stack-decision mistakes

"The cross-platform option saves us money." Sometimes true, sometimes very false. If the cross-platform abstraction breaks on the hard part of your project, you'll spend the savings (and more) writing native modules to work around it. Pick the stack that fits the hard part.

"Native is always better for performance." Less true than it was. For most apps in 2026, the performance gap is invisible to users. If your app is a list-and-form app with standard mobile UX, native is more expensive without being meaningfully better. Save native for projects where performance genuinely matters.

"We'll pick based on what the team prefers." The team's preference matters — see My Home Delivery — but it shouldn't be the only factor. We've seen teams want to use a stack because they want to learn it. Personal-growth motivations are fine on side projects. On a build budget, the stack should serve the project first.

"We can change the stack later if we need to." You can't. Or rather, you can, but the cost is a full rewrite. The stack you ship v1 on is almost always the stack you ship v3 on. Pick deliberately.

How to do this for your own project

Three questions answer most stack decisions:

1. What's the hard part of your project? Audio? Real-time? Custom UI? BLE? On-device ML? Health integration?
2. What stack makes that hard part easiest?
3. Does your team — or the team you'll hire — have skills that overlap with that stack?

If you can answer those three honestly, you're 90% there. The remaining 10% is the kind of thing discovery is for — surfacing the integration risks, validating the ecosystem health of your preferred libraries, sanity-checking the hiring market in your geography.

The shorter version

Cerebyte was a Flutter project because audio was the hard part and Flutter had the best audio-engine ergonomics. My Home Delivery was a React Native project because the founder's team was a React team and the marketplace shape had no platform-specific requirements that demanded otherwise. Two different stacks, same decision process.

Your project has a hard part. The right stack is the one that makes it easiest. If you'd like a written recommendation for yours, with the reasoning, start with a discovery engagement. Two weeks, a real deliverable, no upsell.