About the project
A trilingual e-commerce platform built once and forked for three Tunisian retailers, with cash on delivery, millime accurate pricing and the fiscal stamp handled natively.
My role: Product architect and full stack developer of the template and of each retailer fork.
I kept rebuilding the same shop. Different client, different products, but the same trilingual catalogue, the same cash on delivery checkout, the same Tunisian invoicing rules. So I stopped treating each project as a new build and turned the third one into a white label template, then forked it deliberately rather than copying files around.
Everything a tenant can change lives in one place. Brand, contact details, theme and feature flags sit under a single tenant directory, and all tenant specific copy is grouped in dedicated translation namespaces. Forking for a new retailer is a documented checklist rather than an archaeology exercise. That template now runs an electronics retailer, a parapharmacy and a low voltage and surveillance distributor, each with its own catalogue and identity on the same foundations.
The stack is Next.js 16 with the App Router in strict TypeScript, Tailwind v4, and next-intl serving French by default alongside English and Arabic with full right to left support. Data lives in PostgreSQL on Cloud SQL through Drizzle, with Firebase handling authentication, storage and hosting. The Tunisian specifics are built into the domain rather than patched on top: money is modelled in millimes so no rounding drifts, cash on delivery is the primary path rather than a fallback, and the fiscal stamp is applied on every order as the law requires.
Main features
- 🎨 Tenant configuration in one directory: Brand, contact, theme and feature flags live in a single place, so a fork is a checklist and not an investigation.
- 🌍 Trilingual with real RTL: French, English and Arabic are served by next-intl, with right to left layout treated as a first class case.
- 💵 Cash on delivery as the main path: The dominant Tunisian payment method drives the checkout design instead of being bolted on afterwards.
- 🪙 Millime accurate money model: Amounts are stored in millimes rather than floating point, so totals and taxes never drift by a rounding error.
- 🧾 Fiscal stamp on every order: The Tunisian legal stamp is part of the order domain, so invoices are compliant without manual intervention.
- 📱 Mobile first storefront: Layouts are designed for the phone first, which is where the large majority of Tunisian shoppers arrive from.
- 🗂️ Typed data access: Drizzle over PostgreSQL on Cloud SQL keeps the schema and the queries checked by the compiler.
- 📘 Documented fork handbook: A written checklist covers every step of standing up a new retailer, which is what makes the template reusable by anyone.
Problems and solutions
Problem: Small and mid sized Tunisian retailers all need the same things: a trilingual catalogue, cash on delivery, legally compliant invoicing. Building each shop from scratch means paying three times for the same work, while a generic international platform handles neither the millime nor the fiscal stamp nor Arabic layout properly.
Solution: I consolidated the third build into a white label template where every tenant specific value sits in one configuration directory and one set of translation namespaces. A new retailer is now a documented fork, and the Tunisian rules that generic platforms get wrong are part of the domain model rather than local patches.
