N°05
Meridian
Direct booking, operated 2026
A direct-booking platform built under your brand, deployed on your domain, and operated by the people who built it.
The challenge
Luxury property operators rent their guest relationships from the OTAs: the booking, the SEO equity and the repeat stay all belong to someone else's domain, and the commission is a percentage of every night. Meridian had to give each operator a sovereign direct-booking business — own domain, own guests, own search equity — while keeping channel sync, payments and events inside one platform that a small team can operate.
The approach
The model is Shopify, not Airbnb. A single Go binary holds the platform: a versioned public booking API with schema.org-complete inventory, a session-authenticated operator console with roles, and a multi-tenant Postgres schema where tenant_id leads every index. Channel sync writes price and availability only, enforced by the sync worker's database privileges rather than by convention. Events are a first-class booking type, not a variant of a stay. Revenue is a platform fee plus a payments margin — never a percentage of the stay.
Result
Own domain, own guests, no commission on the stay.
The OTAs stay discovery channels; the platform is where the repeat booking happens.
The evidence
Live screenshots, not mockups.
-
The homepage — the platform's own storefront, an Astro site on the Go core. -
Full length — the offer, the model, the operator surface, the foot. -
Mobile at 390 pixels.
Case study
Meridian is the MFX Platform: multi-tenant direct-booking infrastructure for luxury property operators. Each tenant gets a sovereign direct-booking business — their own domain, their own SEO equity, their own guest relationships — and the platform is operated by the people who built it.
What’s running
The core is one Go binary on the standard library’s net/http, with sqlc-generated queries against Postgres 16: no ORM, no framework, every query a reviewed file. The storefront at meridianhq.dev and the operator console are Astro applications that consume the core’s JSON. Everything runs as services on infrastructure MoonFactory owns, behind Cloudflare.
Multi-tenant by construction
tenant_id sits on every tenant-scoped table and leads every composite index, from the first migration. Guest identity is tenant-partitioned but platform-resident, so federation across tenants stays a policy decision rather than a migration. Twenty-six migrations, each run up and down in CI before it may merge.
The sync boundary
Channel sync — Hostaway and its kind — writes price and availability, and nothing else. That is not a rule in the code: the sync worker connects with a database role granted exactly those columns, so an integration cannot overwrite the operator’s curated property data even by accident.
The two surfaces
A versioned public booking API serves machine-legible inventory: schema.org-complete property data and a controlled amenity vocabulary, consumable by an agent as readily as a browser. The operator console at /operator/v1 is session-authenticated with roles — owner, manager, operations — under a private OpenAPI contract.
Money and mail
Payments through Stripe with verified webhooks; transactional mail through Resend; media on S3-compatible object storage behind presigned URLs. Revenue is a platform fee plus a payments margin, never a share of the stay.
Hosted and operated by MoonFactory
Three services and a Postgres on infrastructure we own, deployed by KANBANi from release branches, with restore points taken before anything is moved. We own the uptime commitment.
The live site
Visit the live site at meridianhq.dev (opens in a new tab).
Stack proof
Every claim is verifiable.
- Go core
- One binary on the standard library's net/http, sqlc-generated queries against Postgres, no ORM and no framework. The public booking API is versioned and machine-legible; the operator console is a session-authenticated /operator/v1 surface with roles owner, manager and operations.
- Postgres 16
- Multi-tenant from the first migration: tenant_id on every tenant-scoped table, composite indexes leading with it. Twenty-six goose migrations, each validated up and down in CI.
- A sync boundary the database enforces
- Channel sync (Hostaway and the like) may write price and availability and nothing else: the sync worker's database role is granted exactly that, so operator-curated property data cannot be overwritten by an integration.
- Astro storefront and console
- The marketing site and the operator web are Astro applications that consume the core's JSON; they render, the core decides.
- Stripe, Resend, object storage
- Payments through Stripe with webhook verification, transactional mail through Resend, media on S3-compatible object storage behind presigned URLs — each held in the environment, none in the code.
- MoonFactory-hosted
- Three services and a Postgres 16 on infrastructure we own and operate, Cloudflare-fronted, deployed by KANBANi. We own the uptime commitment.
Infrastructure
- API Go
- Site Astro
- Console Astro
- DB Postgres 16