A few months ago I shipped tourism.krd — first-party hotel and motel management software built specifically for property owners in the Kurdistan Region: Duhok, Erbil, Slemani and Zakho. This post is about the engineering decisions behind it, and why building for a local, underserved, right-to-left, multilingual market turned out to be a genuinely interesting problem.
The problem
Most small hotels and motels in the region still run on paper ledgers or scattered WhatsApp chats. The result is predictable: double-bookings, lost income records, and no clear view of occupancy or revenue. The few digital options that exist are global OTA platforms that take a commission on every booking and assume English-only, left-to-right staff. Nobody had built management software that speaks the local languages and leaves every booking — and every dinar — with the owner.
Why multi-tenant, subdomain per property
Every property runs on its own subdomain — yourmotel.tourism.krd — with its data fully isolated. I went with a single database and row-level multi-tenancy rather than a database per tenant: every row carries a tenant_id, and a host-to-tenant lookup in middleware resolves the subdomain to that ID on each request.
Postgres Row Level Security is the backbone. Reads and writes are scoped by a current_tenant_id() function so a query can never leak across tenants, even if application code has a bug:
create policy tenant_isolation on bookings
using (tenant_id = public.current_tenant_id());
The trilingual / RTL challenge
The admin works fully in English, Arabic and Kurdish (Bahdini, written in Arabic script), with correct right-to-left mirroring. The hard part isn't translation — it's that every piece of content is multilingual. Room names, taglines, landing-page copy: each is stored as a small object rather than a single string.
type Localized = { en: string; ar: string; ku: string };
Layout direction flips based on locale, and the whole UI mirrors so Arabic and Kurdish read naturally. Getting RTL right across a real dashboard — calendars, tables, forms — is far more work than wrapping things in dir="rtl".
The stack
Next.js (App Router, React Server Components) for the admin and the public site
Supabase — Auth, Postgres, Storage, and RLS — accessed SSR
Tailwind for styling, with a dedicated palette per surface
Cloudflare Workers for deployment, so it's fast and cheap to run regionally
What I learned
Building for an underserved local market is its own kind of constraint. There's no off-the-shelf component library tuned for Bahdini RTL, no Stripe support for local payment rails, and the users aren't developers — so the bar for "obvious and calm" UI is high. Those constraints made the product sharper, not weaker.
Try it
If you run a hotel or motel in the Kurdistan Region, it's live and first-party at tourism.krd — 0% commission, trilingual, your software. Feedback from other builders very welcome.
SOCIAL SHARE CARD GENERATOR