Building a multi-tenant field-service SaaS that onboards a new company in under a day

The client

An operations company in Riyadh dispatching field technicians for maintenance contracts. They resold their internal dispatch tool to two partner firms by cloning the codebase, and were maintaining three diverging copies. Every bug was fixed three times. Adding a fourth customer meant a fourth copy.

The problem

Cloning an app per customer is the most common way a working product turns into an unmaintainable one. The real requirement was one product, many isolated customers: separate data, separate branding, separate billing, one deploy.

The constraints

Saudi infrastructure only. Data residency and the client's own compliance posture required hosting inside the Kingdom, and payments had to run through Moyasar — no international gateway detours. Stripe was never on the table.

Three live customers on day one. The two partner firms could not tolerate downtime or a data migration that changed how their dispatchers worked. The consolidation had to happen underneath them, invisibly.

No dedicated ops team. The client has no infrastructure staff. Whatever was built had to be deployable, backed up, and observable by the two engineers who maintain it part-time.

Shared schema, enforced isolation

One Postgres database with a tenant_id on every row and isolation enforced by row-level security policies at the database layer, not in application code. A missed WHERE clause in a query cannot leak another company's data, because the database itself refuses to return it.

Tenant provisioning as a product feature

New-company onboarding became a form, not a project: company record, subdomain, branding, seat limits, a Moyasar payment profile, and a Wafeq invoicing account created in one transaction. Setup that previously took weeks of manual work now completes in under a day, most of it waiting on the customer's own data import.

Billing that matches the plan

Per-seat subscription billing with proration and dunning collected through Moyasar, the Saudi payment gateway, with invoices issued through Wafeq and reconciled nightly against the tenant registry so finance and the database never disagree about who pays for what.

Per-tenant branding and domain handling

Each tenant gets its own subdomain, logo, and color scheme resolved at the edge from the hostname, before application code runs. A dispatcher at acme.app and one at globex.app see two different products that happen to share one deployment.

Operated by two, not twenty

Migrations run automatically on deploy, and background workers handle everything that must not block a dispatcher's request: subscription charges, dunning retries, and the nightly reconciliation that compares the tenant registry against Moyasar and Wafeq. Alerting ships to the small internal team. The architecture assumes no on-call rotation exists, because for this client it does not.

One codebase, three companies, zero forks

The three diverging copies became one deployment. Every fix since ships to all customers at once, and the per-customer patch burden that consumed the client's week is gone.

Onboarding measured in hours

A new company goes from sales call to working subdomain in under a day, with the data import as the only slow step. The fourth customer took hours, not weeks.

Finance and the database agree

Nightly reconciliation has turned billing disputes into a lookup instead of an investigation: the tenant registry, Moyasar, and Wafeq report the same answer.