HisabKarLay: one POS, many tenants

01 /The problem

A naive build would copy the app for every merchant. That explodes ops: patches, Nginx vhosts, database dumps, and payment credentials all drift. The product only works if one codebase can host many businesses and still feel private.

Checkout also had to take JazzCash in production, not a demo form — so tenant isolation had to survive real payment callbacks and queued jobs, not just CRUD screens.

02 /Architecture & implementation

Custom Laravel middleware resolves the tenant on every request, then scopes queries so stock, invoices, and users never leak across shops. Background queues and schedulers run the heavy work (reports, invoices, gateway sync) off the request path so the till stays snappy at peak hours.

JazzCash is wired for live traffic: sandbox first, then production credentials per tenant where required. Nginx fronts the app with a deployment path that does not require a new box when a merchant signs up.

03 /My responsibility

My work covered Laravel backend engineering and integrations: tenant middleware, scoped business data, queues and scheduling, live JazzCash payments, and Nginx deployment. The same tenant boundary had to hold across web requests, payment callbacks and background work.

04 /Scaling considerations

Moving reports, invoices and gateway synchronization into background jobs keeps that work out of the checkout request. A shared codebase also centralizes application updates as merchants join. Neither choice removes the need to monitor production behavior or verify tenant boundaries; those remain part of maintaining the platform.

05 /Result

One product, many isolated businesses — live JazzCash checkout, tenant-safe invoices, and a stack that can take another merchant without a rebuild. That is the difference between a POS demo and a SaaS.