Delivered remotely for a business based in Phoenix, United States. Names withheld by agreement.
Project Overview
Industry: Regulated safety and compliance management — equipment that must be maintained, inspected and evidenced across distributed locations.
Type of solution: A multi-tenant, web-based SaaS platform with a REST API, a scheduled automation engine, and a reporting and audit layer.
Business context: Compliance obligations around safety-critical equipment share an awkward property: the equipment is distributed, rarely used, and easy to forget, yet the consequence of it failing at the moment it is needed is severe. Consumable components expire on fixed dates. Inspections are due on cycles. Responsibility moves between staff. The organisation carrying the obligation frequently cannot answer, on demand, which units are compliant right now — and that gap is exactly what an audit, an insurer or an incident investigation examines.
General users: Platform administrators, coordinators responsible for a company's equipment programme, maintenance staff, and inspectors invited externally and scoped to specific locations. Managers receive scheduled reporting for the geographies or organisations they are assigned to.
General purpose: To hold one authoritative register of equipment and its components, to convert compliance deadlines into automated advance notifications, and to produce reporting and audit evidence that stands up after the fact.
The Business Challenge
Compliance data scattered across spreadsheets. Each site tended to keep its own record. There was no single view of the estate, and no way to answer an estate-wide compliance question without asking every site individually.
Silent expiry of consumable components. Components with fixed expiry dates fail quietly. Nothing alerts anyone; the item simply becomes non-compliant on a date that has already passed by the time someone notices. Any credible system had to warn well in advance and repeatedly.
Inspections dependent on human diligence. Inspection cycles were tracked manually, inspectors were often external to the organisation, and there was no controlled way to give an outside inspector access to exactly the locations they were responsible for and nothing else.
Reporting was a recurring manual burden. Periodic compliance reports were assembled by hand from whatever data could be gathered, which made them expensive to produce, inconsistent between periods and slow to arrive.
No defensible audit trail. When compliance is questioned after an incident, current state is not enough — the organisation needs to show what was true at a point in the past, who changed what, and that the required notices were actually issued.
A complex responsibility structure. Accountability does not follow a simple tree. A user can be a manager for some geographies and an inspector in others; a company sits inside a wider organisation; locations sit inside a geographic hierarchy. The permission model had to represent that faithfully rather than approximate it.
Multi-tenancy from day one. The platform serves many client organisations simultaneously. Every query, report and notification must be correctly scoped, with no possibility of one tenant's data appearing in another's report.
Our Approach
Model the hierarchy before the screens. We established the tenancy and geography hierarchy first — organisation, company, location, device, layered over country, state/province and city — because every permission check, every report scope and every notification audience derives from it. Two orthogonal assignment models were then built on top, allowing a user to hold different responsibilities in different geographies.
Treat automation as a product feature, not a background script. The heart of this platform is what happens when nobody is logged in. We therefore built the scheduled work as first-class functionality: every automated run is logged, visible to administrators in the interface, reviewable after the fact, and manually triggerable when needed.
Build a real dry-run capability. Bulk automation that creates records and emails hundreds of people is unnerving to operate blind. We introduced an execution-context abstraction so that any batch command can run in preview mode: database work executes inside a transaction that is rolled back, and mail transport is suppressed — while the results still flow through the real selection logic, so the preview reflects what the live run would genuinely do. Operators can inspect the outcome before committing to it.
Make evidence a design requirement. Rather than bolting on reporting at the end, we designed for evidence: activity logging across entity changes, an outbound email audit including attachments, and daily historical snapshots of device state so that point-in-time compliance can be reconstructed.
Engineer the batch layer for scale. All batch processing uses chunked iteration with memory reclamation and deliberate pacing, so long runs across a large estate stay stable and stay inside mail-provider limits.
Deliver through an automated pipeline. Releases run through continuous integration with automated deployment, cache clearing, migration execution and application server reload, so shipping to a live compliance system is a controlled, repeatable process.
The Solution
Central equipment register. Every device has a single record with a comprehensive attribute set: type, model, manufacturer, purchase details, physical placement information, status and location assignment. Daily snapshots preserve historical state alongside the live record.
Component and expiry management. Consumable components are modelled separately and linked to the devices they serve, each carrying its own expiry date. This is what makes proactive alerting possible, because the platform knows what expires when, everywhere.
Staged reminder engine. Rather than a single notification, the platform issues staged advance warnings at multiple intervals ahead of an expiry or inspection deadline, plus recurring and overdue reminders. Users control whether they receive them. The effect is that a deadline has to be ignored repeatedly and deliberately in order to be missed.
Inspector invitation and scoped access. Coordinators invite inspectors by email; the inspector accepts and is granted access limited to the specific locations assigned to them. External participation in the compliance process therefore requires no broad account provisioning and no shared credentials.
Maintenance scheduling. Maintenance activity is scheduled against devices and recorded against them, so service history sits with the asset rather than in a separate log.
Configurable report groups. Reports are defined as configurable groups with saved filters rather than as fixed outputs. Groups can be generated on demand or automatically, are exportable to PDF and spreadsheet, retain generation history, and are emailed to the managers assigned to the relevant scope.
Automated reporting at multiple scopes. Scheduled commands materialise reports at geographic and organisational scope, attach the relevant devices and responsible inspectors, and dispatch documents to the correct recipients per tenant — with every send recorded.
Operational transparency for administrators. Administrators see the audit log of entity changes, the outbound email log with downloadable attachments, and the execution history of scheduled jobs — with the ability to trigger a job manually when a run needs repeating.
Device identification via QR codes. Individual devices carry generated QR codes, so a unit encountered in the field can be resolved directly to its record.
Supported access for troubleshooting. Administrators can operate the platform in the context of a specific user account to reproduce and resolve reported issues, which materially shortens support cycles for a distributed, non-technical user base.
REST API. A versioned API with OAuth2 bearer-token authentication exposes authentication and location data for integration and companion-application use.
Key Features
Central multi-tenant equipment register One record per device with a wide attribute set, scoped through an organisation → company → location hierarchy so each tenant sees exactly its own estate.
Expiry tracking for consumable components Components are modelled and dated independently of the device they serve, which is what allows the platform to detect and warn about upcoming non-compliance across the whole estate.
Multi-stage automated reminders Staged advance alerts, recurring reminders and overdue notifications, delivered by email to the responsible parties, with per-user opt-in control.
Inspector invitation with location-scoped access External inspectors are invited by email and granted access strictly limited to their assigned locations — no shared logins, no over-provisioning.
Configurable report groups with saved filters Reports are defined as reusable configurations rather than hard-coded outputs, generated on demand or on schedule, exported as PDF or spreadsheet, with full generation history.
Scheduled report generation and distribution Automated batch commands build reports at geographic and organisational scope and deliver them to the assigned managers, per tenant, without human involvement.
Preview (dry-run) mode for batch automation Any batch run can be executed in preview: writes are rolled back and email is suppressed, while the real selection logic still executes — so operators can verify exactly what a live run will do.
Full audit trail across changes, emails and jobs Entity change logging, outbound email logging with attachments, and scheduled job execution history — the three records needed to demonstrate that a compliance obligation was actually met.
Point-in-time historical snapshots Daily archiving of device state means compliance can be evidenced as at a past date, not only as it stands today.
QR-coded device identification Generated codes link a physical unit directly to its digital record for fast field lookup.
Technical Architecture
Presentation layer. Server-rendered application interface built on a modern component framework and compiled through a contemporary front-end build pipeline, with server-side-processed data grids for large datasets and asynchronous requests for interactive operations.
API layer. A separately routed, versioned REST API authenticated with OAuth2 bearer tokens, sharing the same domain models as the web application — so integrations and companion apps operate against the same business rules rather than a parallel implementation.
Application layer. Domain controllers segregated by audience (administration, coordinator operations, authentication). Cross-cutting concerns — role authorisation, account status, support access, cache control, signature validation — are implemented as middleware so they apply consistently rather than being repeated in each controller.
Business logic and services layer. Dedicated service classes encapsulate the platform's operational behaviour: report export generation, outbound email auditing, scheduled-run logging, and the execution-context abstraction that provides live/preview behaviour to every batch command.
Automation layer. A scheduler drives console commands for reminders, report generation, historical snapshots and report distribution. Queueable jobs handle email dispatch. This layer is where most of the platform's value is delivered, and it is instrumented accordingly.
Data layer. A relational database holds tenancy, equipment, inspection, reporting and audit data, with a substantial migration history reflecting continuous evolution of the model.
Infrastructure services. Cloud object storage for documents and generated reports, a transactional email provider for delivery, and an error and performance monitoring service for production observability.
Flow: Browser / API client → Middleware (auth, role, tenancy scope) → Controllers → Services & domain models → Relational database → Scheduler & queue → PDF / spreadsheet generation → Object storage & email delivery → Audit logs
Technology Stack
| Category | Technology |
|---|---|
| Backend language | PHP 8.1+ |
| Backend framework | Laravel 10 |
| Database | MySQL (SQLite for test runs) |
| API authentication | Laravel Passport (OAuth2) |
| Web/session authentication | Laravel Sanctum and session guard |
| Frontend | Bootstrap 5, Sass, Axios, built with Vite |
| Data grids | Yajra DataTables (server-side processing) |
| PDF generation | DomPDF (Laravel integration) |
| Spreadsheet export | Maatwebsite Excel, PhpSpreadsheet |
| Audit logging | Spatie Activity Log |
| Monitoring | Sentry (errors and performance) |
| Log inspection | Log viewer packages for operational diagnostics |
| QR codes | SimpleSoftwareIO QR Code |
| File storage | AWS S3 |
| Email delivery | Configurable SMTP / AWS SES / Mailgun / Postmark |
| Cache & queue | Redis / database / sync (configurable) |
| Testing | PHPUnit, model factories with Faker |
| Code style | Laravel Pint |
| CI/CD | CircleCI with Capistrano automated deployment |
| Scheduling | Laravel scheduler via system cron |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| Bulk report generation across a large, hierarchical estate without exhausting memory or hitting mail-provider limits | Chunked iteration over records with explicit memory reclamation and deliberate pacing between sends, so runtime stays flat as the estate grows and outbound volume stays within provider thresholds. |
| Operators needing confidence before running automation that writes records and emails hundreds of people | A shared execution-context abstraction giving every batch command a genuine preview mode: database writes run inside a rolled-back transaction and mail transport is suppressed, while real selection logic still executes so the preview matches live behaviour. |
| Proving that a compliance obligation was met, after the fact | Three complementary audit surfaces — entity change logging, outbound email logging including attachments, and scheduled job execution history — plus daily historical snapshots so past state can be reconstructed. |
| A permission model where responsibility does not follow a single hierarchy | Tenancy modelled as an explicit hierarchy, with two orthogonal assignment models layered on top, so a user can hold different role types in different geographies and organisations. Enforcement is centralised in middleware rather than duplicated per controller. |
| Giving external inspectors access without over-provisioning | An email invitation flow that grants access strictly scoped to assigned locations on acceptance, avoiding shared credentials and broad account creation. |
| Deadlines being missed because a single notification is easy to ignore | A staged reminder engine issuing multiple advance warnings at different intervals plus recurring and overdue notices, with per-user delivery preferences. |
| A core entity with a very large attribute surface | Careful separation of master data (types, models, manufacturers, component models, site classifications) from the device record itself, keeping the entity manageable and reference data reusable and consistent. |
| Reporting requirements that change per client and per period | Reports implemented as configurable groups with saved filters and retained history, so a new reporting requirement is a configuration change rather than a development task. |
Security & Reliability
Authentication. Session-based authentication for the web application and OAuth2 bearer tokens for API clients, with password reset and email verification flows.
Authorisation. Role enforcement implemented as middleware and applied to route groups, with account status checks preventing disabled accounts from transacting. Access to sensitive administrative areas is restricted at the route level.
Tenant isolation. All operational queries and report scopes derive from the tenancy hierarchy and assignment records, so users see only the estate they are responsible for.
Auditability. Entity changes are recorded with actor and detail, related changes are grouped so a multi-step operation reads as one logical event, outbound email is logged with its content and attachments, and scheduled runs record what they did.
Support access controls. Administrator-level support access allows an issue to be reproduced in the reporting user's context, restricted to administrators through dedicated middleware.
Web security hygiene. CSRF protection, encrypted cookies, signed URL validation, trusted proxy and host configuration, and cache-prevention headers on authenticated pages.
Monitoring and diagnostics. Production error and performance monitoring through an external service, with in-application log inspection tooling for operational diagnosis.
Data durability. Documents and generated reports are stored in cloud object storage rather than on application servers, so application instances remain disposable and stored evidence survives them.
Scalability & Performance
Chunked batch processing. Every scheduled command iterates in bounded chunks with memory reclamation, so processing time and memory usage scale predictably with estate size rather than degrading sharply.
Server-side data grids. Large lists are paged, sorted and filtered at the database layer, keeping response times stable regardless of dataset size.
Asynchronous dispatch. Email and report distribution are implemented as queueable jobs, so user-facing requests never wait on mail delivery.
Deliberate pacing on outbound volume. Batch email dispatch is paced to stay within provider rate limits — a practical reliability measure that prevents a large run from being throttled or partially delivered.
Externalised storage and cache. Object storage for files and a configurable cache/queue backend mean the application layer can be scaled horizontally without state pinned to individual servers.
Generated document handling. PDFs and spreadsheets are written to storage rather than held in memory, so large exports do not create memory pressure.
Production observability. Performance monitoring in production identifies slow paths against real usage rather than assumptions.
Business Outcomes
- One authoritative register replaces distributed spreadsheets, so estate-wide compliance questions are answered from a single source.
- Deadlines are surfaced before they are missed, because staged automated reminders replace human diligence as the primary control.
- Compliance reporting stops being manual work. Reports that previously had to be assembled by hand are generated and distributed automatically on schedule.
- Compliance is defensible after the fact, through change logs, email evidence, job execution history and point-in-time historical snapshots.
- External inspectors participate safely, with scoped invitations replacing shared credentials and broad access grants.
- Administrators can operate the automation with confidence, thanks to preview runs, visible execution history and manual re-triggering.
- Multiple client organisations are served from one platform, keeping operating cost per tenant low while preserving strict data separation.
- Support cycles are shorter, because issues reported by non-technical users at distributed sites can be reproduced directly in context.
Why it worked
The hard part of a compliance platform is not the forms. It is everything that happens when nobody is watching: the batch that must run correctly across a large estate, the notification that must go to precisely the right person at precisely the right time, and the evidence that must still be there in two years when someone asks a difficult question.
Our team builds that layer deliberately. We instrument automation so it can be observed and operated, not just scheduled. We build preview modes so that a bulk run is verifiable before it commits. We treat audit trails as a design input rather than a late addition. And we engineer batch processing to stay stable as data volume grows, because compliance systems accumulate data indefinitely by their nature.
Alongside that, our teams bring deep working knowledge of the modern PHP and Laravel ecosystem, multi-tenant SaaS design, OAuth2-secured APIs, cloud storage and email infrastructure, and automated CI/CD delivery — the full set required to run a platform that other organisations depend on for their own regulatory position.
Final Summary
Organisations accountable for safety-critical equipment across many sites face a problem that is administrative in appearance and serious in consequence. The equipment is distributed and rarely used, its components expire on fixed dates, its inspections fall due on cycles, and the records that prove all of this tend to live in spreadsheets owned by whoever happened to be responsible at the time. When compliance is questioned, current state is not enough — the organisation needs evidence of what was true then.
Our team designed and built a multi-tenant SaaS platform that turns that obligation into managed, automated process. A central register holds every device and every dated component across a full organisational and geographic hierarchy. A staged reminder engine warns responsible parties repeatedly and well in advance. Configurable report groups generate and distribute compliance reporting on schedule. Underneath, an audit layer records entity changes, outbound notifications and scheduled job execution, while daily snapshots preserve historical state for point-in-time evidence.
The engineering emphasis was on the parts that run unattended: chunked batch processing that stays stable as the estate grows, paced delivery that respects mail-provider limits, queueable dispatch that keeps the interface responsive, and a preview mode that lets operators verify a bulk run before committing to it. For any organisation whose compliance position currently depends on somebody remembering, this is the pattern that replaces memory with system.