The Laravel + React Native Combo: SEM Nexus's Marketplace Playbook
Two-sided marketplaces — Uber, DoorDash, TaskRabbit, the long tail of vertical-specific delivery and service platforms — share a small set of engineering shapes. Once you've shipped one, the next one is mostly a matter of replacing the domain logic. SEM Nexus's marketplace playbook is Laravel on the back-end + React Native on the front-end, and it's proven on My Home Delivery and several smaller builds. This post is the playbook.
If you're scoping a two-sided marketplace right now, this is the engineering shape we'd recommend. If we're not the right partner, you'd still get a usable build by following the structure below.
Why Laravel + React Native specifically
Three reasons:
Laravel has the best ORM + admin story for marketplace data shapes. Marketplaces are heavily relational — users, roles, jobs, transactions, locations, ratings, payments, disputes. Laravel's Eloquent ORM and Nova admin panel cover 80% of the back-office work that founders would otherwise hand-build. Saving that 80% is worth months of calendar.
React Native has the deepest hiring market and the lowest cross-platform overhead for the shapes marketplaces actually need — lists, maps, forms, payment flows, push notifications. The shapes are standard. RN doesn't need to flex into custom rendering or audio engineering.
The two communicate cleanly over REST/JSON. No GraphQL ceremony, no serialization tax, no exotic infrastructure. The team you'll hire in 18 months can read both sides.
The seven layers of a marketplace build
A typical two-sided marketplace has seven engineering subsystems. SEM Nexus ships all seven on every marketplace build; here's how we structure each.
1. Multi-role auth
Marketplaces have at minimum two user roles (customers, providers) and usually a third (admins). The auth layer needs to support:
- Role-scoped access tokens
- Role-specific onboarding flows
- Role-specific home screens
- Cross-role identity if applicable (a user can be both customer and provider)
Laravel Sanctum handles tokens cleanly. React Native consumes them via a single auth context with role gates around routes.
2. The job/transaction shape
Every marketplace has a central transactional object — a "job," "booking," "order," "task." It's the spine of the data model:
job
├─ customer_id
├─ provider_id (nullable until accepted)
├─ state (pending / accepted / in_progress / completed / disputed)
├─ scheduled_at
├─ location_data
├─ payment_id
└─ ratings (both directions, after completion)
State transitions are explicit and enforced server-side. The client never advances state directly — it requests a transition, the server validates and updates.
3. Multi-party payments
This is where the "free discovery" failures show up. Multi-party payments — customer pays, platform takes a cut, provider gets paid — are non-trivial. Stripe Connect is the right answer for ~95% of US marketplaces. The cap table:
- Customer pays via the platform's Stripe account
- Platform takes a percentage cut at capture
- Provider receives payouts to their connected Stripe account
- Stripe handles 1099-K reporting for US providers above thresholds
The wrong move here is to roll your own. Stripe Connect's fees are higher than raw Stripe, but the saved engineering work + saved compliance liability is worth it.
For My Home Delivery, the Stripe Connect integration was named as the hard part in discovery, prototyped in sprint 2, and live by sprint 4.
If your marketplace project has multi-party payments — almost all do — SEM Nexus's discovery will name the Stripe Connect work as a first-class engineering item, not a "we'll figure it out" feature.
4. Real-time location (when relevant)
Not every marketplace needs real-time location, but delivery and field-service ones do. See our separate post on the My Home Delivery location stack for the deep dive. The key architectural call is: native modules behind a React Native facade, with platform-specific background-mode state machines.
5. Role-scoped push notifications
Marketplaces have notifications by the dozen, every one scoped to a role:
- Customer-facing: "Your driver accepted the job," "Driver is 3 minutes away," "Job completed, please rate"
- Provider-facing: "New job available," "Customer messaged you," "Payment cleared"
- Admin-facing: "Dispute opened," "Provider verification needed"
Notifications routed by user role + active session state. iOS APNS + Android FCM via a single Laravel notification subsystem that handles deduplication, throttling, and channel separation.
6. Admin dashboard
The platform owner needs to see and intervene. Laravel Nova or a hand-rolled admin shipped on the same Laravel back-end gives the founder visibility into:
- Active jobs and their state
- Provider supply and customer demand
- Payment volumes and platform take
- Disputes and resolution status
- Provider verification queue (KYC, document review)
We strongly recommend Laravel Nova for v1; founders can build a custom admin later when they've learned what they actually need from the data.
7. Audit, replay, dispute resolution
Marketplaces generate disputes. The customer says the delivery never arrived. The provider says it did. Without an audit trail, the platform becomes the human arbitrator of every dispute, which kills founder productivity in week 4 of operations.
We persist every location update, every state transition, every payment event, and every message into the job's audit log. When a dispute happens, the platform owner can replay the entire job timeline in 30 seconds and make a defensible call.
This is one of the most-skipped features in marketplace builds and one of the highest-leverage ones. We ship it in v1, every time.
The My Home Delivery build, in shape
| Subsystem | Implementation |
|---|---|
| Auth | Laravel Sanctum, three roles (customer / driver / admin) |
| Job shape | Standard state machine, server-enforced transitions |
| Payments | Stripe Connect, multi-party split at capture |
| Location | Native modules + per-platform state machines (see linked deep-dive) |
| Notifications | Laravel notification subsystem, role-scoped routing |
| Admin | Laravel Nova-based dashboard for the founder |
| Audit | Per-job timeline of every event, replayable in admin |
Build time: 16 weeks. Quote: fixed. Live in the App Store and Google Play by week 17. Two years later, the architecture hasn't required a single material rewrite.
What this stack is bad at
To stay honest: Laravel + React Native is not the right stack for every shape.
High-volume real-time apps (live trading platforms, real-time gaming) outgrow the Laravel + React Native combo. Stack moves to something like Node.js + WebSockets + native rendering.
Apps where the value depends on custom UI rendering — drawing apps, video editors, intricate visual experiences — push toward Flutter for the rendering control.
Apps with on-device ML or BLE-heavy work push toward native modules deeper than RN typically wants.
We pick Laravel + React Native when the project is a standard-shape two-sided marketplace. We pick something else when it isn't.
What this means for your marketplace
If you're scoping a marketplace mobile app — delivery, service, dating, healthcare provider matching, vertical-specific platforms — the engineering shape above is the proven playbook. The seven layers will all be present in your build whether you plan for them or not; planning for them in discovery is what makes the difference between shipping in 4 months and slipping by 6.
If you'd like the playbook applied to your specific marketplace, SEM Nexus's two-week discovery will scope all seven layers in writing — with a fixed quote against v1, a real sprint plan, and the Stripe Connect work named as a sprint goal, not a hand-wave. The marketplace shape is what we've shipped. It's not theory.
