W-Enterprises/Work/Bilingual HR document SaaS
Case study / KSA · HR-Tech · 2026
A bilingual HR document platform, live in Saudi Arabia.
An HR consultancy in the Saudi market needed to produce compliant employment paperwork across dozens of document types, in Arabic and English, for many client companies at once. It is now a multi-tenant product running on the client's own Google Cloud account, in production, taking real payments.
Context
The client is an HR consultancy serving Saudi employers. Their work involves producing the paperwork that sits behind employment in the Kingdom: offer letters, employment contracts, probation confirmations, salary and finance letters, leave and assignment documents, exit clearances. Every one of those needs to exist in Arabic and English, be correct against Saudi labour practice, and carry the employer's branding.
Before the platform, this was manual drafting. Manual drafting scales linearly with headcount, produces inconsistency between documents, and is difficult to keep bilingual and on-brand at the same time. It is also exactly the kind of work that becomes risky as compliance obligations tighten, because a document that is out of date is worse than no document.
Constraints that shaped the build
- Multi-tenant from day one. The consultancy's own clients each needed isolated data, their own branding and their own employee directory, under one product.
- Bilingual, not translated. Arabic and English side by side, with correct right-to-left rendering and typography, in documents that would be signed.
- Data protection. Saudi PDPL reaches processing of Saudi residents' data regardless of where the processor sits. Employment documents are dense with personal data.
- Their infrastructure, not mine. The client had to own and operate the system, in-Kingdom, on their own cloud account.
- Real payments. A subscription product taking Saudi cards, not an invoice-and-hope arrangement.
Approach
Next.js and Firebase, multi-tenant on custom claims
Tenant identity carried in auth custom claims rather than inferred at the query layer, so isolation is enforced at the identity boundary and again in security rules. A super-admin surface for tenant provisioning. Employee directory import from spreadsheet, because that is what HR teams actually have.
Server-rendered PDFs, nothing persisted
Templates render server-side through headless Chromium and stream straight to the browser. No field values are written to disk or database. That single decision removed most of the PDPL surface area rather than mitigating it, and it is cheaper than the alternative. The technique is written up here.
A bilingual field schema, not two templates
Each field carries both languages in one schema, so a document cannot drift out of sync between its Arabic and English forms. Fonts embedded and awaited before every render. Direction resolved per field rather than per page.
Geidea hosted checkout, verified webhooks
Live Saudi checkout including Apple Pay, with signature-verified webhooks and tokenised recurring billing. Replaced an earlier mock payment integration. A renewal callback that silently fails is a revenue bug, so the verification path is tested by breaking it.
In-Kingdom, on the client's account
Compute on Cloud Run and data in Firestore in Gulf regions, deployed into the client's own Google Cloud project with a separately deployed security ruleset. The client owns the infrastructure and the bill.
Guards control-tested by breaking them
Eleven architecture decision records. Verification scripts that prove a guard works by deliberately violating what it protects, so a passing test means the protection is live rather than absent. A sanitised deployment mirror keeps commercial material out of the client-facing repository.
Result
The platform is in production on the client's own Google Cloud account, generating bilingual HR documents on demand across 34 templates in six categories, with live subscription payments through Geidea. Document generation persists no field values, so the sensitive payload never comes to rest.
The client's own commercial model is a per-tenant monthly subscription, which means the system they now own is an annuity rather than a cost centre.
What would be done differently
Two things, stated plainly because they are more useful than a clean narrative.
First, the engagement was priced fixed against a scope that turned out to be exploratory rather than fixed. Where scope is genuinely settled and written down, fixed price is right. Where it is not, billing by sprint protects both sides, because absorbed out-of-scope work trains everyone to expect more of it.
Second, a support and operations arrangement should have been agreed at handover rather than after it. A production system on managed cloud with payment webhooks and a security ruleset needs someone who can deploy it and debug a failed renewal. Naming that person and pricing it upfront is a service to the client, not an upsell.
Reusable capability this produced
Custom-developed code for a client belongs to the client. The methods do not transfer with it, and these are the ones that carry into the next engagement:
- A bilingual field schema pattern where one record drives both language forms of a document.
- A render pipeline that waits on font readiness and asserts it, so typography failures cannot ship silently.
- A no-persistence document architecture that keeps a data protection surface small by construction.
- Verified webhook handling for Geidea, including the failure paths.
- A deployment split between a private working repository and a sanitised client-facing mirror.
Reusable materials are declared in a schedule at signature on every engagement, licensed to the client, and never presented as bespoke work. Both sides know what they own before the work starts.
Need something like this?
Bilingual, multi-tenant, compliance-aware, and yours at the end. Send what you are building and what obligations sit behind it, and you will get a written read on scope and risk within one working day.
The client is credited by sector and region rather than named, in line with the confidentiality terms of the engagement. Figures describe delivered scope. Portfolio rights are agreed in writing in every proposal.