I lead product at Bagisto, an open-source Laravel eCommerce platform used by thousands of merchants worldwide. A big part of my job is deciding what we build next — and how we build it.
Earlier this year, we had a decision to make. Store owners kept telling us the same thing: "Running our store from a desk is killing us. We want a real mobile admin."
The brief was simple. The stack decision wasn't.
We had three serious options on the table, and one of them was Flutter. This is the story of why we didn't pick it — and why, after genuinely evaluating the alternatives, we chose NativePHP instead.
If you're a Laravel shop weighing the same decision for your own admin panel or SaaS, I hope the tradeoffs we worked through save you a few meetings.
The Three Options on the Table#
We weren't going to pick a stack on vibes. Three options got real evaluation:
1. Flutter (with a REST API layer)#
Flutter was the obvious frontrunner. It's mature, has a great rendering engine, and the community is massive. We have Flutter developers on the team. On paper, perfect.
Here's what made us pause: Bagisto's admin is huge. Orders, customers, products, marketing, reports, settings, tax rules, channels, invoices, shipments, promotions. Thousands of form fields. Years of business logic baked into controllers and Eloquent models.
Picking Flutter meant:
- Rebuilding the entire admin UI in Dart
- Building and maintaining a full REST API on the Laravel side
- Two codebases, two release cycles, two teams working in parallel
- Re-implementing auth, validation, permissions, and pagination on the mobile side
- Keeping both sides in sync every time Bagisto shipped a feature
As a product decision, that meant doubling our engineering surface area — forever — for a feature that was meant to extend Bagisto, not fork it. For a consumer app with heavy animations or offline-first needs, I'd swallow that cost. For an admin panel, it's hard to justify.
2. A PWA#
Fast to build, but no real push notifications on iOS, no app-store presence, and merchants kept telling us they wanted "a real app." Ruled out.
3. NativePHP#
I'd been watching NativePHP from a distance for a while — mostly on Twitter, mostly skeptical. PHP running as a native mobile app? Really?
But the pitch, when I read it properly, was disarmingly practical: take the Laravel app you already have, and ship it as a native app. Same controllers. Same Blade views. Same auth. Same models. Just... native now.
We gave ourselves a weekend to prototype it.
The Weekend That Decided It#
Our team installed NativePHP, pointed it at a fresh Bagisto install, and ran the build.
The Bagisto admin opened on an Android emulator. Logged in with the existing session-based auth. Navigated through orders. Tapped into a customer profile. Saved a product.
It just worked.
We kept looking for the catch. There wasn't one — not for an admin app, anyway. Everything we'd been dreading about mobile development (re-auth, API contracts, state sync, separate builds) had simply evaporated, because there was no second app. There was just the Laravel app, running natively.
That weekend killed Flutter for this project.
Why NativePHP Won (For This Project)#
I want to be fair here — Flutter is a great framework. If I were building a rich consumer-facing app with heavy animations, offline-first logic, and a dedicated mobile team, I'd still reach for Flutter. It's built for that.
But for a CRUD-heavy, form-heavy, dashboard-heavy admin app — the kind most Laravel devs are asked to build for their SaaS or eCommerce backend — NativePHP is an almost absurdly good fit.
Here's what actually mattered in practice:
One codebase. Every Bagisto feature ships once, not twice. When a new admin module gets added to Bagisto core, it shows up in the mobile app without me writing a single extra line.
No API layer to maintain. This one's bigger than it sounds. Every Laravel dev has felt the dull ache of keeping an API in sync with a frontend. Auth tokens, pagination contracts, validation errors, response shapes. NativePHP lets the session-based auth and server-rendered views you already have just... keep working.
Customisation is just Bagisto customisation. This is the part I love most. If someone wants to override a Blade view in the mobile app, they override it exactly the way they'd override it on the web. Same service provider pattern. Same view inheritance. Same Tailwind config. There's no "mobile way" to do anything — there's just the Laravel way.
Native where it needs to be. Push notifications via FCM, native navigation, OS-level integration. Admins get real push alerts when an order comes in, not a polling loop or an in-app banner. That part is genuinely native.
A Note to the Flutter Developers Reading This#
If you're a Flutter dev who's been asked to contribute to a Laravel project, NativePHP is probably the gentlest on-ramp you'll find. Your instincts about widget composition map cleanly onto Blade components. Reactive UI logic maps to controller methods (or Livewire, if you want reactivity on the client). The build pipeline is still npm-based — Vite instead of the Flutter toolchain, but the mental model is the same.
You don't have to write Dart. You don't have to learn Laravel from scratch. You can work inside the same codebase as the backend team instead of shouting across an API boundary. For teams that are already split between a Laravel backend and a Flutter frontend, NativePHP is worth a serious look as a consolidation move.
What the Experience Was Actually Like#
A few honest observations from months of living inside NativePHP:
The learning curve is almost nothing if you know Laravel. The hardest part for our team wasn't learning NativePHP — it was unlearning the instinct to build an API. Our engineers kept reaching for Route::apiResource before remembering they didn't need to.
Debugging feels normal. Laravel Telescope still works. dd() still works. Stack traces are still stack traces. After years of mobile developers telling me how painful debugging React Native bridges can be, this was a genuine relief.
The build process is boring — in a good way. composer install, npm run build, package it up, ship it. No Xcode rituals, no Gradle sacrifices. Just the Laravel workflow the team already knew, with a mobile binary at the end.
Push notifications took more work than we expected. FCM setup has its own learning curve. But this isn't a NativePHP problem — it's a mobile platform problem. Once it was wired up, it worked exactly as it should.
Performance surprised us. We went in expecting "good enough for an admin app" performance. What we got was indistinguishable-from-native for the kind of workflows admins actually do: tap into an order, update a status, scroll a list, submit a form. No jank. No weird lag.
Who Should Actually Pick NativePHP#
I'll be direct about this because the NativePHP docs won't be:
Good fit:
- Admin panels, dashboards, back-office tools
- B2B SaaS with existing Laravel backends
- CRUD-heavy apps with lots of forms and tables
- Teams that are Laravel-strong and don't want to hire a mobile team
- Anyone with a mature Laravel app who wants to extend it to mobile without rewriting it
Probably not the right tool:
- Heavy 3D or game-like UI
- Apps where the mobile version is radically different from the web version
- Teams that already have strong mobile expertise and no Laravel team
For us at Bagisto, and for most Laravel shops I talk to, the "good fit" list describes 90% of what anyone actually gets asked to build.
The Bigger Point#
For a long time, PHP developers — Laravel developers especially — were told that "serious" mobile development meant learning something else. Dart. Swift. Kotlin. JavaScript and a framework-of-the-week.
NativePHP quietly reframes that assumption. Your Laravel skills aren't a stepping stone to mobile; they are mobile, if you want them to be. For admin apps, internal tools, dashboards, and back offices, you don't need a second language, a second team, or a second codebase.
You just need NativePHP.
NativeBagisto is live on the Play Store and featured on the NativePHP showcase. But more than that — it's a real, production app running in PHP on Android devices, serving actual merchants. And nothing about that sentence feels weird to me anymore.
If you're on the fence, my honest advice: clone a NativePHP starter, point it at your existing Laravel app, and give your team a weekend with it. That's all it took for us.
Saurav Pathak is CPO at Bagisto, the open-source Laravel eCommerce platform. You can find him on LinkedIn and X. Bagisto's mobile admin, NativeBagisto, is built with NativePHP and available on the Play Store.
