Pro Master
The operator front-end for a multi-tenant ERP — invoicing, ledger, ZATCA, payroll, inventory, and treasury — rebuilt on the App Router with English and Arabic RTL as first-class layouts.
Pro Master is a business operating system for Saudi teams: sales invoices, double-entry books, ZATCA Phase 2 clearance, GOSI/WPS payroll, inventory, treasury, and hospitality — one traceable path instead of spreadsheets and side portals. I own the Next.js front-end against the NestJS API, from marketing and onboarding through the dense operator console.
The product is bilingual by default. Locale-aware routing, RTL and LTR shells, stacked Arabic/English names in tables, and Hijri-aware dates live in the same design system as the forms — not a translation layer bolted on after English shipped. Incomplete onboarding never reaches the dashboard; cookie session, refresh, and locale live in middleware.
With dozens of modules, the only way to stay honest is a shared pattern. Paginated tables, module headers, react-hook-form plus Zod at the form boundary, and a typed Axios client mapped to the OpenAPI spec mean a new screen copies an existing module instead of inventing one. shadcn/ui and Tailwind v4 carry appearance tokens (accent, radius, type) across marketing and app.
The capabilities that matter in a walkthrough — what a team can actually run.
One operating system, not six tools
invoicing, ledger, payroll, inventory, and treasury share a single order ID from POS to closed period
ZATCA Phase 2 on the invoice itself
XML, QR, and Fatoora clearance next to the document finance already issued, not a side portal
Books that post from operations
receivable, revenue, and VAT write to the general ledger in the same transaction; trial balance is already current
Built for Saudi teams
full Arabic and English, real RTL, Hijri dates, bilingual PDFs, and GOSI / WPS / end-of-service on the same payroll run
Cash you can trust
banks, cashboxes, transfers, and reconciliation tied to the ledger, not a weekly spreadsheet
Stores, properties, and wallets on the same books
Salla/Zid-style orders, hospitality units, COD, and owner settlements without a month-end export
Multi-company from day one
tenants, branches, and roles so each entity has isolated books and a team that only sees what they should
An operator console people live in
dense tables, search, bulk actions, and exports designed for the task someone runs forty times a day
Tell me about your product
Share a short brief — problem, timeline, and stack — and I'll reply with a candid view on fit, effort, and the fastest path to a shippable milestone.