How Moven's Multi-Tenant Architecture Lets Every Villa Operator Have Their Own Brand Without the Dev Cost

One of the earliest architectural decisions I had to make when building Moven was: do we build separate websites for each villa operator, or do we build a shared platform where each operator gets their own space? The answer — a multi-tenant architecture — sounds like a technical detail but has enormous implications for every operator using the platform. Here's how it works and why it matters.

The Problem With Generic Booking Platforms

Existing booking platforms have a common pattern: you create a listing, you get a page at platform.com/your-villa-name, and it looks exactly like every other listing on the platform. Your brand identity is completely subordinate to the platform's brand. Guests book through the platform's checkout, see the platform's confirmation emails, and have the platform's name in their booking history.

For some operators, this is fine — they're arbitraging the platform's traffic and don't care about brand. For operators trying to build something distinctive, it's a problem. A luxury villa brand can't be built on a URL that doesn't belong to you.

What Multi-Tenancy Means in Practice

In a multi-tenant architecture, a single application serves multiple customers (tenants), but each tenant experiences the application as their own. In Moven's case, each villa operator gets their own subdomain — typically their brand name at a .moven.in subdomain, or a custom domain they bring themselves — with their own logo, color scheme, typography, and content.

From the guest's perspective, they're on a website that belongs entirely to the villa. The URL, the branding, the experience all reflect the operator's identity. The only hint that Moven is involved is at the technical layer — and that's intentional. Guests should feel like they're dealing directly with the property.

How Theme Injection Works

Each tenant in our system has a theme configuration: primary color, accent color, surface color, border color. These are stored in Payload CMS as part of the tenant record. When a page loads for a specific subdomain, the application reads that tenant's theme configuration and injects it as CSS custom properties at the root level.

This means a single Next.js codebase serves pages that look completely different for different operators. The structural components — hero layout, booking widget position, gallery grid — are shared. But the visual identity — colors, fonts, header style — is per-tenant. It's the same principle as how SaaS tools use themes, applied to villa booking pages.

Subdomain Routing

When a request comes in to villa-name.moven.in (or a custom domain pointing to Moven), our middleware reads the hostname, looks up the corresponding tenant record, and attaches that tenant's configuration to the request context. Every component downstream knows which tenant it's serving and renders accordingly.

This routing happens at the edge — before the request reaches the application server — which means there's no latency penalty for the tenant lookup. The tenant-aware rendering is folded into the normal static generation pipeline, so each tenant's pages are cached separately at the CDN.

Why This Is Better Than Building Separate Sites

The alternative — building a separate website for each operator — would mean 10 separate codebases, 10 separate deployment pipelines, 10 separate maintenance contracts. A bug fix in the booking calendar would need to be applied 10 times. A performance improvement would need to be deployed 10 times. The economics don't work for small or mid-sized villa operators who can't afford a dedicated engineering team.

Multi-tenancy means that every improvement to the platform benefits every operator simultaneously. When we optimize image loading, every property gets faster. When we improve the mobile checkout flow, every operator's conversion rate benefits. Shared infrastructure, individual brand identity.

The Trade-offs

I'll be honest about the trade-offs. Multi-tenancy means that customization has limits — an operator who wants a radically different page structure or a completely bespoke feature can't just change it without it potentially affecting others. We manage this with a feature flag system and a clear product roadmap, but it's a real constraint.

The benefit exchange is this: operators give up unlimited customization and get, in return, a professionally engineered platform that they couldn't build themselves for any reasonable budget. For most villa operators, who are experts in hospitality and not software, that's a very good trade.