Vendor Portals & Multi-Tenant Architecture for Small Marketplaces

IslaTodo is a marketplace where tourists request services and vendors fulfill them. Vendors sign in, manage listings, accept bookings, and respond to concierge requests. The architecture that makes this work is multi-tenant — and it's the same pattern any small marketplace should steal.

The problem multi-tenancy solves

A marketplace has two user populations: customers (tourists in our case) and vendors (taxi drivers, restaurants, tour operators, charter captains). Each population sees a different interface. Each vendor sees only their own data — their listings, their bookings, their messages — never anyone else's.

Naively, you'd build two separate applications. Customer-facing app on one codebase, vendor portal on another. They'd share a backend but the front-ends would be separate. This works but creates duplication: shared design components, shared auth, shared business logic, all maintained in two places.

Multi-tenant means: one codebase, one front-end, but the user's identity and role determine what they see. A customer hits the marketplace homepage and sees listings to book. A vendor hits the same domain and gets routed to their dashboard. Same code, different rendering paths.

The auth model

Three roles in our system: anonymous (default tourists), customer (signed-in tourists with bookings), and vendor (sign-in via vendor portal). The auth layer assigns the role based on the user's account type. The application layer checks the role on every request and renders accordingly.

Permissions are checked at every layer. Front-end hides nav items the user shouldn't see. API rejects requests for data the user doesn't own. Database queries are scoped by tenant_id at the ORM level. Defense in depth — even if one layer is bypassed, the others hold.

The data isolation pattern

Every vendor-owned record in the database has a vendor_id column. Every query filters by it. There is no query in the codebase that selects vendor data without specifying which vendor.

This sounds like a small thing. It's the entire architectural foundation of multi-tenant apps. One missed filter and you're showing Vendor A's bookings to Vendor B — a catastrophic data leak. We use a base ORM class that automatically applies the tenant filter, so it's impossible to write a query that bypasses it without explicitly opting out.

The vendor onboarding flow

Vendors sign up via a separate landing page (visible from islatodo.com/list-your-business). They go through email verification, listing setup, and a manual approval step. Once approved, their account is flagged as "vendor" and they get access to the portal.

The manual approval step is critical. We're a small marketplace; trust is the differentiator. A vetted listing from a verified vendor converts dramatically better than the chaos of an unmoderated marketplace. The approval step costs us a few hours per week. It's worth it.

The dashboard the vendor actually wants

The vendor portal isn't a generic SaaS dashboard. It's tuned to the specific operator personas. A taxi driver sees: today's incoming requests, his availability toggle, his earnings this week. A restaurant sees: tonight's reservations, the menu/hours editor, dispute escalations. A charter captain sees: this week's bookings, the boat availability calendar, weather alerts.

Same architecture, different default views. The framework supports it; the implementation tunes it. Vendors who feel like the portal was built for their job specifically use it daily. Vendors who feel like they're using a generic system don't.

What scales and what doesn't

Multi-tenant scales beautifully on the technical side. Adding a new vendor type (we recently added "spa booking") is hours of work, not weeks. The architecture absorbs new categories without restructuring.

What doesn't scale: trust and quality control. Every new vendor has to be vetted. Every new category has to be QA'd. Marketplace quality is the value proposition; you can't automate it away.

That tension is why most successful small marketplaces stay small for a long time. Going from 50 vendors to 5,000 is mostly a quality-control problem, not a technical one.

The takeaway

If you're considering a marketplace product, multi-tenant architecture is the right starting point. Build it right at the foundation — tenant_id on every record, role-based rendering, defense in depth — and the technical side won't be your bottleneck. Your bottleneck will be the human work of curation, and that's where you want to be spending your energy anyway.