HomeCase studiesA Fleet Inspection, Service and Parts Platform...

Case study · Toronto, Canada

A Fleet Inspection, Service and Parts Platform for Industrial Equipment

Industrial equipment — material handling fleets and the dealer service, parts and rental business around them

Every powered industrial machine has to be inspected before it is used, and almost everywhere that inspection is still a paper pad hanging on the equipment. Nobody can prove it happened, a fault found by an operator reaches nobody, and the service provider hears about a breakdown only when the phone rings. Our team built a platform that replaces the pad: QR-tagged equipment, structured digital inspections that classify condition and escalate automatically, service and parts requests that flow straight into a helpdesk, a self-service quote builder, per-machine cost-of-ownership reporting and a warehouse picking module — delivered as two native mobile applications and a role-scoped web platform over a Laravel API.

Industry
Industrial equipment — material handling fleets and the dealer service, parts and rental business around them
Solution
A multi-tenant B2B platform: a REST API with a role-scoped web application and administrative back office, plus native Android and iOS applications for field use.
Platforms
Android · iOS · Web & API
Stack
Laravel · PHP · Blade · jQuery · Bootstrap · MySQL
Location
Toronto, Canada · delivered remotely
Role
Engineering, with the team behind for mobile and QA

Delivered remotely for a business based in Toronto, Canada. Names withheld by agreement.

Project Overview

Industry: Industrial equipment — material handling fleets and the dealer service, parts and rental business around them.

Type of solution: A multi-tenant B2B platform: a REST API with a role-scoped web application and administrative back office, plus native Android and iOS applications for field use.

Business context: An equipment dealer does not simply sell machines; it services the fleets it has placed with its customers. That relationship runs on inspections, breakdowns, parts orders, rentals and invoices — and historically on paper and phone calls. The customer's operators inspect equipment before each shift and record it on a pad. The customer's site managers approve service calls verbally. The dealer receives requests as unstructured emails and phone messages and re-keys them into its helpdesk. Nobody, on either side, has a consolidated picture of what any individual machine costs to keep running.

General users: Equipment operators, site fleet managers, company-level fleet managers, dealer administrators, and platform administrators.

General purpose: To make pre-shift inspection provable and actionable, to route the resulting work automatically to the people and systems that handle it, and to give both the customer and the dealer a single, current view of equipment condition and cost.

The Business Challenge

The inspection record lives on the machine. A paper checklist proves nothing to anyone who is not standing next to the equipment. There is no history, no aggregate, and nothing to produce when compliance is questioned.

A fault found by an operator reaches nobody. The operator ticks a box, parks the machine, and goes home. The defect is discovered by whoever needs the equipment next — often a shift later, sometimes a week later.

Unsafe equipment stays in service. Without a mechanism that marks a machine as out of service and keeps reminding people that it is, a locked-out unit quietly becomes just another unit.

Requests arrive unstructured. Service, parts, rental and equipment requests come by phone and email, in whatever form the requester chose, and have to be interpreted and re-entered into the dealer's ticketing system before any work can start.

Approval is verbal. A site manager authorises a service call in conversation. There is no record of who approved what, or when, or whether it was declined.

Nobody knows what a machine costs. Parts, labour and miscellaneous charges arrive on invoices and are never aggregated per machine, so decisions about repair versus replacement are made on instinct.

The warehouse runs on printed lists. Parts picking has no bin-location guidance, no record of shortfalls and no timing, so the operation cannot be measured or improved.

All of this happens away from a desk. Operators are on a machine, managers are on a floor, pickers are in an aisle. The mobile applications had to be the primary product, not a companion to a web system.

Our Approach

Put the identity on the machine and make it one scan. Every unit carries a generated QR code whose payload opens that exact machine inside the mobile app. An operator scans the sticker and is already in the right inspection — the app resolves the equipment, selects the checklist family appropriate to its power type, and pre-fills make, model and serial. Friction is what kills adoption of pre-shift inspection, and this removes almost all of it.

Make the inspection produce a decision, not a document. Rather than storing answers and leaving interpretation to a human, the platform reduces each submission to a three-state condition — safe to operate, defective but operable, or out of service — and writes that condition back onto the equipment record. The fleet list stops being a history of past submissions and becomes a live condition board.

Escalate automatically, to the right tier. A defect or lockout notifies the site manager, the company fleet manager and the dealer administrator for that site simultaneously, as a stored notification and a push to every registered device, each carrying a deep link straight to the affected machine.

Do not let a locked-out machine go quiet. Equipment marked out of service generates a recurring reminder that re-notifies on a fixed interval until the condition is cleared.

Turn a request into a ticket without a human in between. Structured request forms create a ticket in the dealer's helpdesk directly, with the contact created, the company, site and serial attached as custom fields, and priority derived from the machine's current condition. The re-keying step disappears.

Model approval as data. An operator's service request is routed to the site manager for an explicit approve or deny, recorded against both the request and the notification, so the authorisation trail exists after the fact.

Aggregate cost where the decision is made. Maintenance costs are recorded per machine across categories and cost types, rolled up to life-to-date and year-to-date totals in the database, and denormalised back onto the equipment record so a fleet-wide cost view renders as cheaply as a plain list.

Build both mobile platforms natively — and abstract the forms. The product's surface area is largely long, conditional forms mixing option grids, free text, timers, photographs and signatures. On iOS this was addressed with a form engine that renders screens from declarative row descriptors over a library of reusable input cells, with validation, auto-fill and submission factored out — so a new form is a description rather than a new screen.

Prototype the interface before implementing it. The desktop experience was designed and built out as a complete static prototype across all four role variants before the server-rendered application was written, giving the team a visual contract to implement against.

The Solution

Equipment register. Companies, sites and units, with make, model and serial maintained as managed reference data. Each unit carries hour meter and starting hour meter, ownership and lease information, location, imagery and a live condition.

QR tagging. A code is generated per machine and can be downloaded for printing. Scanning it opens that unit in the mobile application.

Dual-family inspections. Separate checklist families for the two equipment power types, each with its own checkpoint set, both producing a comparable outcome and a single unified history. Checkpoint sets are managed as configuration in the back office rather than being fixed in code.

Inspection capture. Hour meter entry validated against the machine's recorded starting value, photograph capture, on-screen signature capture and a fluid-added record, all attached to the submission.

Condition classification and lockout. Each submission is reduced to a three-state condition, written onto the machine, with out-of-service equipment escalated and placed under recurring reminder until cleared.

Request workflows. Service, parts, rental, sales, equipment and warehouse-product requests, each with its own structured form and reference code. Equipment and rental requests capture load, lift height, dimensional and site-access requirements. Parts requests carry part details, shipping preference, delivery address and file attachments.

Manager approval. Operator-raised service requests are routed for explicit approval or denial, recorded against the request.

Helpdesk integration. Approved and submitted requests create tickets in the dealer's hosted helpdesk with contact creation, custom fields and condition-derived priority.

Instant quote builder. A line-item quote assembled from the parts catalogue with quantities, prices and shipping, totalled, signed on screen and submitted against a specific machine and site.

Warehouse picking. A catalogue of warehouse items with SKU, description and bin location; pick lists assembled through a staging basket; pick orders with number, requested date, priority and duration; and a fulfilment flow capturing quantity picked, quantity available, per-line completion and elapsed pick time.

Cost-of-ownership reporting. Maintenance recorded per machine across categories and cost types, rolled up to life-to-date and year-to-date totals, with fleet-level and per-machine views including a mobile-optimised variant.

Document library. Per-company, per-site and per-user document storage with upload and download.

Messaging and notifications. Direct chat between site users and the dealer, a notification centre with read state and deep links, and push delivery to registered devices.

Administrative back office. Full management of reference data, checklist configuration, catalogue, companies, sites, units, users, roles, all request types, quotes, content and broadcast notifications.

Key Features

QR-scanned equipment identification Each machine carries a generated code whose payload opens that unit directly in the mobile application, resolving the equipment and routing the operator to the checklist family matching its power type — so an inspection begins with a single scan rather than a search.

Digital pre-shift inspection with photo and signature capture Structured checklists for both equipment power types, with hour meter validation, photographic evidence and an on-screen signature attached to every submission.

Automatic condition classification and lockout Every inspection is reduced to a three-state condition that is written onto the equipment record, so the fleet view reflects current safety status rather than submission history.

Tiered automatic escalation with deep links Defects and lockouts notify the site manager, company fleet manager and dealer simultaneously, in-app and by push, each notification linking straight to the affected machine.

Recurring out-of-service reminders Equipment marked out of service is re-notified on a fixed interval until the condition is cleared, so a locked-out machine cannot become invisible.

Structured requests that become helpdesk tickets Service, parts, rental, sales and equipment requests are captured as structured forms and create tickets directly in the dealer's helpdesk with contact, context fields and condition-derived priority.

Recorded manager approval Operator-raised service requests carry an explicit approve or deny decision recorded against the request, replacing verbal authorisation with an auditable trail.

Self-service instant quoting A line-item quote builder over the parts catalogue with quantities, shipping, totals and a captured customer signature.

Warehouse pick lists with bin locations and timing Pick orders with prioritised lines, bin-location guidance, per-line shortfall capture and elapsed pick time, so the picking operation becomes measurable.

Per-machine cost-of-ownership reporting Maintenance costs aggregated by category and cost type into life-to-date and year-to-date totals, denormalised onto the equipment record so fleet-wide cost views stay fast.

Three-level tenancy with role-appropriate entry Company, site and user scoping, with each role entering the system at its own level and working within a selected context.

Technical Architecture

Mobile clients. Two independently built native applications covering the same feature set. The Android application is a fragment-based single-activity app with a shared HTTP client layer, image loading, QR scanning, signature capture and push messaging, and separate development, staging and production build variants that supply their configuration at build time. The iOS application is a UIKit application built around a data-driven form engine: screens are described as row collections and rendered by a generic controller over a library of reusable input cells — option grids, text and text-view inputs, segments, elapsed-time counters, image upload, signature and confirmation — with validation, auto-fill and submission handled separately. Both handle QR scanning, camera and signature capture, push notifications and deep links, and both step operators through the inspection as a short guided sequence rather than one long form.

API layer. A token-authenticated REST API serving the mobile clients, with rate limiting and a separate controller tree from the web application.

Web layer. A server-rendered, role-scoped application for customer and dealer staff, and a separate administrative back office, each with its own authentication guard and its own controller tree over shared domain models.

Domain and workflow layer. Inspection classification, tiered notification fan-out, approval state, helpdesk ticket creation and the maintenance rollup computation, backed by managed reference data for checklist types, categories, catalogue items and the equipment taxonomy.

Scheduled work layer. Console commands run on a schedule for recurring out-of-service reminders and equipment status maintenance.

Data layer. A relational database with an extensive equipment, inspection, request, quote, picking and maintenance schema, evolved through a long migration history, with cost aggregates computed in SQL and denormalised onto the equipment record.

Media layer. All photographs, signatures and attachments captured on device or in browser, uploaded to cloud object storage, and referenced by URL from web views, mobile screens and templated emails.

Delivery layer. Continuous deployment from the version control pipeline to staging and production, with shared configuration symlinked outside the release directory, retained previous releases, cache and process-manager hooks, and single-command rollback.

Flow: QR scan on device → Native mobile app (role-specific) → Token-authenticated API → Inspection classification and condition write-back → Tiered notification fan-out (in-app + push with deep links) → Helpdesk ticket creation → Relational database with denormalised cost rollups → Object storage for media → Scheduled reminder commands

Technology Stack

Category Technology
Backend language PHP
Backend framework Laravel
Database PostgreSQL (MySQL also configured), with Doctrine DBAL and a long migration history
API authentication Laravel Passport (OAuth2 bearer tokens)
Web authentication Separate session guards for the customer web application and the administrative back office
Object storage Google Cloud Storage
Push notifications Firebase Cloud Messaging
Ticketing Hosted helpdesk platform integrated over REST with an OAuth refresh-token flow
Spreadsheet import/export Maatwebsite Excel
Server-rendered UI Blade templates with Bootstrap, jQuery, DataTables, Chart.js, Select2, input masking, date/time pickers and a canvas signature widget
Asset pipeline Laravel Mix / webpack
Scheduled work Laravel console commands on a scheduler
Android Java with a Kotlin module, fragment-based single-activity architecture
Android libraries Retrofit with Gson, Glide, QR/code scanner, signature pad, WorkManager, Material Components, ConstraintLayout, Firebase Messaging and Analytics
Android build Product flavours supplying per-environment configuration at build time
iOS Swift with UIKit and XIB-driven views
iOS libraries Alamofire, Firebase Messaging, QR scanner, signature view, keyboard manager, slide-menu container, popover components
iOS architecture Custom data-driven form engine with a reusable input-cell library and separate validation, auto-fill and submission helpers
Design prototype Static HTML/CSS/JS prototype covering all four role variants, used as the implementation contract
CI/CD CircleCI driving Capistrano deployment to staging and production with retained releases and rollback

Technical Challenges & Solutions

Challenge Our Approach
Pre-shift inspection only works if it is faster than the paper pad it replaces A QR code on each machine whose payload opens that exact unit in the app, with equipment details pre-filled — reducing the start of an inspection to a single scan.
A completed checklist is a document, not an action Each submission is reduced to a three-state condition written back onto the equipment record, so the inspection changes the machine's status rather than adding to an archive.
A defect or lockout has to reach several people immediately, across two organisations Tiered notification fan-out to site manager, company fleet manager and dealer administrator simultaneously, as stored notifications and push messages carrying deep links to the affected machine.
Equipment taken out of service can quietly stay that way A recurring reminder record created on lockout, re-notified on a fixed interval by a scheduled command until the condition is cleared.
Requests arriving as unstructured phone calls and emails had to be re-keyed by the service desk Structured request forms that create helpdesk tickets directly, with contact creation, company/site/serial as custom fields, and priority derived from the machine's current condition.
Two equipment power types need materially different checkpoint sets but comparable outcomes Separate checklist families driven by back-office-managed checklist types and categories, both resolving to the same three-state condition and a single unified history.
The same long, conditional, multi-input forms had to exist on two native platforms On iOS, a data-driven form engine rendering screens from declarative row descriptors over a reusable input-cell library, so new forms are described rather than built; on Android, a staged fragment flow that breaks each inspection into short, ordered steps over a shared HTTP layer.
Fleet-wide cost views require six-way maintenance aggregation per machine Aggregates computed in SQL and denormalised back onto the equipment record, so list views read a column rather than recomputing a multi-category sum per row.
Three tenancy levels and four roles, each entering the system at a different point Company and site selection carried as working context, with every query scoped to it and each role landing at its appropriate level on sign-in.

Security & Reliability

Token authentication for field devices. The mobile applications authenticate with OAuth2 bearer tokens, keeping the API tier stateless and revocable per device.

Separate authentication guards per audience. The customer-facing web application and the administrative back office authenticate independently, with distinct controller trees over shared domain models.

Forced credential change on first access. Accounts provisioned with a temporary password cannot proceed until the password has been changed.

Tenancy scoping on every query. Company and site context bounds what any user can retrieve, so data belonging to one customer or site is not reachable from another's session.

Recorded approval trail. Service request authorisation is captured as an explicit approve or deny decision against both the request and the notification, so who authorised what remains answerable afterwards.

Inspection provenance. Every submission retains its submitter, timestamp, hour meter reading, photograph and captured signature — the evidentiary record that a paper pad cannot provide.

Soft deletion. Core records are marked rather than destroyed, so history survives day-to-day administrative changes.

Media isolation. Photographs, signatures and attachments are held in cloud object storage rather than on application servers, and are referenced by URL from every surface that renders them.

Rate limiting. The API tier applies request throttling.

Deployment safety. Releases are deployed through a continuous delivery pipeline with environment configuration held outside the release directory, previous releases retained, and rollback available as a single command.

Scalability & Performance

Stateless API tier. Token authentication and externalised media keep application instances free of local state, so the API tier scales horizontally.

Denormalised cost aggregates. Six-category maintenance rollups are computed in SQL and written onto the equipment record, so a fleet-wide cost view reads a column instead of recomputing a multi-way aggregate for every machine in the list.

Bounded queries by construction. Tenancy scoping means every list is constrained to one company and one site before any other filter applies, keeping result sets small on the platform's hottest paths.

Media offloaded to object storage. Every photograph and signature is uploaded once and served from cloud storage thereafter, keeping image bandwidth entirely off the application tier — significant in a product where every inspection can carry photographic evidence.

Push rather than polling. Time-sensitive events — a machine taken out of service, a request awaiting approval — reach devices by push notification, so clients do not poll for state that changes rarely.

Scheduled work off the request path. Recurring reminders and status maintenance run as scheduled console commands rather than as work triggered by user requests.

Per-environment builds. Separate development, staging and production build variants on Android allow the full stack to be exercised against non-production infrastructure before a release reaches users.

Continuous deployment. Changes reach staging automatically from the pipeline, with production deployment and rollback as single, repeatable operations.

Business Outcomes

  • Pre-shift inspection became provable. Every inspection carries its submitter, time, hour meter reading, photographs and a signature, retrievable per machine and per site.
  • A fault found by an operator now reaches the people who can act on it, in-app and by push, across both the customer's management tiers and the dealer, within the same submission.
  • Unsafe equipment is marked as such on the equipment record itself, and stays visible through recurring reminders until the condition is cleared.
  • Service requests carry a recorded authorisation decision instead of a verbal one.
  • Requests reach the dealer's helpdesk as tickets rather than as messages, removing an interpretation-and-re-keying step from the start of every job.
  • Quoting became self-service, with a signed, itemised quote produced against a specific machine without a phone call.
  • Fleet cost is visible per machine, with maintenance aggregated by category and period rather than scattered across invoices.
  • Warehouse picking became measurable, with bin-location guidance, shortfall capture and elapsed time recorded against every pick order.
  • Field work happens on the device it belongs on, through native applications on both mobile platforms rather than a web page adapted to a phone.

Why it worked

Compliance software has a specific failure mode: it gets adopted for a month and then quietly abandoned, because the paper it replaced was faster. An operator with a machine to move will not open an app, search a fleet list, find a unit and type a serial number. They will use the pad. Any honest assessment of this category starts there — the entire product succeeds or fails on how many seconds it takes to begin.

That is why the design work went into the scan, the pre-filled form and the single condition that comes out of the other end. Our team builds for the operating reality rather than the requirements document: we made starting an inspection one scan, made the result change the machine's status rather than fill an archive, made a defect notify three tiers of management automatically, and made a locked-out machine keep asking to be dealt with. We integrated the request flow directly into the service desk's own ticketing system, because a workflow that ends in an email is a workflow someone still has to re-type. And on iOS we abstracted the product's dominant cost — long, conditional, multi-input forms — into a form engine, so the next checklist is a description rather than a screen.

Our teams work across Laravel and PHP, relational data modelling and reporting, native Android and iOS development, third-party service and ticketing integration, push notification architecture, cloud object storage and continuous deployment — with the domain judgement to know that in field software, the thing that matters most is usually the first ten seconds.

Final Summary

A powered industrial machine has to be checked before it is used. For decades that check has been a pad of paper hanging on the equipment: unverifiable, unaggregated, and incapable of telling anyone that something is wrong. The consequences run in every direction — operators find faults that nobody hears about, unsafe machines stay in service, service providers learn about breakdowns from a phone call, and neither party can say what any individual machine actually costs to run.

Our team built a platform that replaces the pad. Each machine carries a QR code that opens its own record in the mobile app, so an inspection starts with a scan rather than a search. The checklist — one family for each equipment power type, both configurable from the back office — captures hour meter, photographs and a signature, and is reduced to a single three-state condition written back onto the equipment itself. A defect or a lockout escalates immediately to the site manager, the company fleet manager and the dealer, in-app and by push, with a deep link to the machine; equipment taken out of service keeps generating reminders until it is dealt with.

Around that inspection core sits the commercial workflow it feeds. Service, parts, rental, sales and equipment requests are captured as structured forms, routed for recorded manager approval, and turned directly into helpdesk tickets with context attached and priority derived from the machine's condition. A self-service quote builder produces signed, itemised quotes against a specific machine. Maintenance costs are aggregated per machine by category and period, denormalised so fleet-wide cost views stay fast. A warehouse module turns parts picking into prioritised, bin-guided, time-measured orders.

Delivered as two native mobile applications — one built around a data-driven form engine that renders complex forms from declarative descriptions — over a Laravel API with a role-scoped web platform, an administrative back office and a continuously deployed pipeline, it turns a compliance ritual that produced nothing into the event that drives the whole service relationship.

01 — Questions

asked about this kind of project

How do you build inspection software that people actually use?

By optimising the first ten seconds. Field compliance software is not competing with a better app; it is competing with a pad of paper that takes no time to start. If an operator has to open an app, search a fleet list and type a serial number, they will use the paper. A code on the machine that opens that machine's record, with everything already known pre-filled, is the difference between a product that is adopted and one that is abandoned in week three.

Why should an inspection change the equipment record rather than just be stored?

Because a stored checklist is a document that someone has to read, and nobody reads them. Reducing each submission to a single condition and writing it onto the machine turns the fleet list into a live status board: anyone can see at a glance which equipment is safe, which has a defect, and which is out of service. The archive is still there for evidence, but the operational value is in the write-back.

How do you make sure a defect reaches the right people quickly?

Fan out to every relevant tier at once rather than relying on a chain. In a dealer-operated model that means the site manager, the company-level manager and the service provider simultaneously, as both a persisted in-app notification and a push message. Deep links matter more than people expect — a notification that opens the affected machine gets acted on; one that opens a home screen gets dismissed.

Should service requests integrate with an existing helpdesk or replace it?

Integrate, almost always. The service organisation already runs on its ticketing system, with its own routing, SLAs and reporting. A platform that emails requests instead of creating tickets simply relocates the re-keying step. Creating the ticket directly — with the contact, the asset context and a derived priority — is where the time is actually saved.

How do you handle equipment types that need different checklists?

Treat the checkpoint sets as configuration rather than code. Different power types, classes and manufacturers need materially different inspection items, but the outcome must remain comparable across the fleet. Managing checklist types and categories as reference data lets the checkpoint sets evolve without a release, while every submission still resolves to the same condition model and the same history.

Why build two native mobile apps rather than one cross-platform app?

It is a trade-off, not a rule. Native gives the most reliable camera, scanning and signature behaviour and the best offline-adjacent performance, which matters for field work in warehouses and yards. The cost is that every screen is built twice. The way to control that cost is abstraction inside each platform — in this project, a form engine that renders complex, conditional forms from declarative descriptions, so adding a form is a data change rather than a new screen.

How do you keep cost reporting fast when it aggregates across many dimensions?

Compute the aggregates in the database and denormalise the results onto the entity being listed. Maintenance cost split several ways across categories and periods is expensive to recompute per row, and a fleet list view will do exactly that if you let it. Rolling the totals up in SQL and writing them back to the equipment record turns an expensive list into a cheap one, at the cost of a recalculation whenever a maintenance record changes — which is the right side of that trade.

What should be built first in a field operations platform?

The capture path, end to end, for the single most frequent action — and then measure how long it takes. Everything else in this kind of product (reporting, quoting, approvals, integrations) is valuable only if the underlying records exist, and the records only exist if the people in the field find the capture faster than what they did before. Build the reporting first and you will have beautiful dashboards over an empty table.

03 — Similar project?

describe what is different about yours

Build yours.

Tell me what exists, what you need and the deadline. Fixed price for a defined scope, or hourly from $10 with a written estimate first.

Ahmedabad, India · IST (UTC+5:30) · --:-- IST · Mon–Fri 09:00–18:00 IST · US & EU overlap daily

No newsletter, no CRM. Just a reply.