Laravel and Flutter: one product, two codebases
Contracting on a two-sided marketplace meant guarding API contracts, Stripe webhooks, and map UX across a Laravel core and Flutter apps. Practical seams I still reach for.
I spend a lot of time where Laravel is the source of truth for money, permissions, and workflows—and Flutter is how posters and workers actually live through a job. The product is one story; the repos are two. The friction shows up at the seams.
Treat the API like a published contract
Mobile clients age in the field. If you “just change” a response shape because Blade templates were easy to update, you will ship a Friday surprise. I lean on versioned JSON, explicit error envelopes, and boring validation rules that return the same keys every time—not clever polymorphic payloads that require tribal knowledge.
When you add a field, ask: who is the slowest updater? Usually the app store review clock, not your API deploy.
Webhooks are state machines wearing a Stripe hat
Payment and notification flows look simple in diagrams. In production they are retries, duplicates, and out-of-order delivery. I document idempotency keys and the exact rows that must flip for “paid”, “refunded”, and “stuck”. Tests that replay webhook fixtures catch more than optimistic unit tests around a happy path.
Maps, lists, and the lie of “just load everything”
Geospatial UX punishes lazy defaults. Cluster markers, distance sorts, and server-driven filters need to agree with what the API can afford at scale. I would rather ship a slightly conservative filter set than a map that feels fast until someone zooms out over Sydney.
What I optimize for in code reviews
- Authorization checks mirrored server-side—never trust the client badge alone.
- Pagination contracts that do not paint you into an N+1 corner later.
- Feature flags that can turn off risky paths without a mobile redeploy, when possible.
Two codebases do not have to mean two cultures. They should still mean one definition of done: money and user trust stay consistent across both sides.
If you are building a similar marketplace stack and want a second pair of eyes on API shape or release sequencing, reach out from the links on this site.