Building a Multi-Vertical Marketplace: One Backend, Web and Mobile

The Real Challenge Isn't the Checkout Flow

Most people picture a ticket marketplace as "browse events, click buy" — and that part is genuinely the easy 20%. The hard 80% is that a real marketplace has three completely different audiences needing three completely different interfaces: customers buying tickets, vendor companies managing their own listings and payouts, and platform admins overseeing the whole thing. That's the architecture I built for Billets24, a marketplace spanning sports events, concerts, cinema, and travel packages, across both a Next.js web app and a companion Flutter mobile app.

One Backend, Two Frontends

The temptation with a web+mobile product is to build the mobile app as an afterthought, hitting whatever endpoints the web app happens to expose. That approach breaks down fast — mobile has different auth persistence needs, different offline expectations, and a different navigation model. Instead, both surfaces talk to the same Supabase backend (Postgres, Auth, Storage, Edge Functions) as the actual source of truth, with each frontend built natively for its platform: Next.js 16 App Router with Zustand on web, Flutter with flutter_bloc (Cubit/Bloc pattern) and go_router on mobile. Supabase's row-level security policies become the single place business rules live — a customer can only see their own orders, a company can only manage their own listings — enforced identically regardless of which app is asking.

Three Roles, Three Dashboards

• Customer storefront — browse and buy across four verticals (sports, concerts, cinema, travel), each with different metadata needs (seat maps vs. showtimes vs. package dates), unified under one checkout
• Company dashboard — vendors manage their own listings, track orders, and see their payouts, scoped entirely to their own data via RLS
• Platform admin panel — oversight across every company and vertical, without which a multi-vendor marketplace has no way to catch fraud or resolve disputes

Payments and Trust

Checkout runs through Stripe, chosen specifically because a multi-vendor marketplace needs more than "charge a card" — it needs a payment model that can eventually support split payouts to different vendor companies without rebuilding the checkout logic from scratch. Getting this right early, even before every vendor payout feature is live, avoids a much more painful migration later once real transaction volume exists.

Localization and Theming Across Two Codebases

Because both apps needed to work for a Moroccan and international audience, multi-language support (via easy_localization on mobile, matching patterns on web) and a light/dark theme system were built in from day one on both platforms — retrofitting i18n after a UI is built is one of the more tedious categories of technical debt, since every hardcoded string has to be hunted down individually.

Conclusion

A real marketplace is really three products sharing one backend, not one product with an admin flag. Designing the Supabase schema and RLS policies around that from the start — rather than bolting on roles later — is what let the customer, vendor, and admin experiences ship as three focused apps instead of one bloated one. See the full Billets24 case study for the complete feature breakdown.