The brief
Architecture and construction firms run on project economics. Labor and costs that have to roll up per project, payroll driven by who worked which job, and money that has to reconcile to the cent. Most run this on spreadsheets and disconnected tools. Z Analytics is the system of record for all of it, today for roughly 19 firms, some of whom have run their entire operation on it for the better part of a decade.
What it handles
A decade of features, refined in production. There’s projects, phases, and stages cost structures, time records (DTR) with per-organization break rules and bulk and self time-in, payroll auto-computed from time records with holiday multipliers and payslip PDFs, expenses & procurement (receipts, materials estimates and comparisons), cash & banking (petty cash, checks), inventory with locations and transaction logs, and managerial analytics dashboards, all behind role-based access control.
Three architectures, one decade, zero dropped clients
The proof point isn’t a launch. It’s that Z Analytics has stayed in production since 2016 and been rebuilt twice underneath the same firms, without breaking their day-to-day.
v1, Laravel monolith (2016)
Shipped on Laravel and white-labeled per client. It proved the model and put real firms on the platform.
v1.5, config-driven white-label (Laravel 12)
A 137-commit, full-stack modernization carried the original forward without a rewrite-from-scratch. That meant Laravel 5.2 to 12, PHP 5.5 to 8.2+, and, because this is financial software, floating-point money moved to DECIMAL with bcmath arithmetic so totals never drift. The front end moved from Gulp/jQuery to Vite + Tailwind + Alpine (CSP-hardened), timestamps moved to UTC-at-rest, and the whole thing was delivered with reversible migrations and zero-downtime, per-tenant cutovers. White-labeling is fully config-driven, so each client is a separately deployed, configurable instance, with enabled modules, branding, time rules and timezone all set by a per-tenant config file, and no code forks.
v2, true multi-tenant SaaS (Go + React)
The current generation is a ground-up rebuild into a real SaaS. A Go (Gin) REST backend, with GORM on PostgreSQL 16, ~70 documented endpoints, and clean layering (controllers / services / repositories), paired with a React 18 + Vite + Redux-Saga front end. Multi-tenancy is genuine row-level isolation, so every record is org-scoped, every request carries its organization, and the data layer enforces the boundary automatically. Add Firebase Google SSO, a cached RBAC model (Root, Owner, Admin, Supervisor, Staff), the projects, phases and stages hierarchy, multi-day DTR with analytics, invitation-based onboarding, and a PWA that works offline for crews in the field.
Why it matters
Ten years in production. Roughly 19 firms. Two ground-up rebuilds, plus a database migration from MySQL to PostgreSQL, with the same clients carried across every one of them, money correct to the cent the whole way. A decade of daily use adds up quietly. Millions of records, every time record, payslip, receipt and stock movement logged since 2016, carried intact through each rebuild and still reconciling to the cent today. That longevity, and the discipline to modernize without disrupting the businesses that depend on it, is the standard we bring to everything we build.