The Uber lesson
Uber Eats and Uber Rides feel like one app, but mature platforms rarely run every vertical on one monolithic database. Food orders spike at meal times; marketplaces spike around sales and holidays. Search patterns, fraud signals, and regulatory requirements differ.
LAIZ applied the same principle early: LAIZ Shop is an official-brand marketplace with escrow checkout and Supabase-backed catalog data. LAIZ Eats is food delivery with its own Node API, Prisma schema, and Postgres on Railway. They meet at the brand layer — not in a shared `orders` table.
What customers actually experience
On thelaiz.com you see one group story. When you order food, you land on eat.thelaiz.com. When you buy electronics or fashion, you land on shop.thelaiz.com. Redirects are deliberate: they keep you on the correct product surface and prevent marketplace URLs from leaking into food flows (and vice versa).
That discipline reduces bugs like food carts appearing on shop checkout, or restaurant APIs querying marketplace Supabase tables. It also makes it obvious which team owns an incident when something breaks.
What partners should expect
Restaurant partners onboard through Eats portals and APIs. Brand sellers onboard through Shop and Brand Central. A restaurant menu never lives next to SKU catalog rows; a courier parcel workflow never shares code with a rider food-delivery app.
If you are evaluating LAIZ as a platform, ask other vendors whether they truly separate verticals or simply namespace tables. LAIZ publishes this architecture openly because it is a feature, not an implementation detail.
