Delivered remotely for a business based in Edinburgh, United Kingdom. Names withheld by agreement.
Project Overview
Industry: Transportation and logistics — asset-intensive fleet operations.
Type of solution: A custom enterprise web application used internally by operations, workshop, administrative and management staff across multiple operating locations.
Business context: Operators that run large owned fleets carry an unusual mix of responsibilities. The same organisation has to keep vehicles legally roadworthy, keep them earning, control fuel and tire spend, schedule workshop capacity, dispatch trips, settle trip costs, and retain the documentation that proves all of it. Each of those responsibilities tends to grow its own tool. Over time the organisation ends up with accurate data in a dozen places and a reliable picture in none.
General users: Dispatch and traffic controllers, workshop and maintenance staff, inspectors, depot and warehouse teams, administrative and HR staff, finance staff handling settlements, site managers and system administrators. A limited external view supports partner-side trip visibility.
General purpose: To provide one operational record per asset and per trip, to enforce consistent processes around spend and compliance, and to give management reliable visibility across distributed sites.
The Business Challenge
The operator's day-to-day work was spread across tools that did not talk to each other.
No single record per asset. Purchase details lived in one place, maintenance history in another, inspection forms on paper, tire history in a spreadsheet. Answering a simple question — what has this unit cost us this year, and is it legal to dispatch tomorrow? — required assembling several sources by hand.
Manual, unenforced processes. Requests for spend, vendor onboarding and equipment acquisition followed conventions rather than a system. Approvals happened over email, so there was no reliable record of who approved what, when, or on what evidence.
Compliance documentation trapped on paper. Inspections were captured on printed forms. Producing a document on demand meant finding the paper, and there was no way to trend inspection findings across the fleet.
Fuel and tire cost leakage. Two of the largest controllable cost lines in fleet operations are fuel and tires. Both were being tracked, but not analysed — there was no systematic way to detect a unit consuming outside its expected band, or to track a tire from purchase through mounting, rotation and retirement.
Fragmented dispatch and settlement. Trips, freight orders and the settlement of trip costs were handled separately from the asset data they depended on, which made reconciliation slow and error-prone.
A legacy back-office system that could not be removed. An existing database held data the business still depended on. Any new platform had to coexist with it rather than demand its replacement.
Distributed sites, inconsistent practice. Each location had evolved its own way of working. Management needed comparable data across sites without forcing every site to change everything at once.
Our Approach
Discovery and domain modelling. We began with the asset lifecycle rather than with screens. Mapping how a unit enters the fleet, how it earns, what is consumed against it, what must be inspected and recorded, and how it eventually leaves gave us a domain model that the later modules could all share. Master data — equipment types, manufacturers, leasing companies, service vendors, locations — was designed first, because every other module depends on it.
Architecture for breadth. The platform covers a wide functional surface, so we structured it as a set of clearly bounded modules over shared master data and a shared security model, rather than as one undifferentiated application. Each module owns its controllers, data access and views; cross-module interaction happens through defined data relationships and shared services.
A workflow engine instead of hard-coded processes. Rather than implementing each approval path in code, we built a configurable engine: processes are made of stages, stages carry dynamically composed form components, and requests route through stages with status and commentary recorded at each step. New processes become a configuration exercise.
Incremental modernisation. The platform was modernised module by module while it remained in production. We introduced newer interface and controller generations alongside the existing ones, cut modules over individually, and kept the ability to fall back instantly. Users were never asked to absorb a single disruptive change.
Integration by data bridge. We connected the platform to the existing back-office database as a secondary data source rather than attempting a migration, and used structured spreadsheet and CSV interchange for bulk data exchange with other systems.
Testing and release. Functional verification focused on the highest-risk paths: workflow routing, inspection capture and document output, fuel calculations and bulk imports. Releases run through an automated pipeline that installs dependencies, deploys, refreshes the application server and restores permissions in a fixed order, so deployments are repeatable rather than manual.
The Solution
The platform consolidates fleet operations into a set of connected capabilities.
Asset lifecycle management. Every powered unit, towed unit and piece of equipment has one record carrying its specification, ownership or lease arrangement, location, current status and complete document trail. Status changes are recorded rather than overwritten, so the history of an asset is preserved.
Acquisition and vendor management. Equipment requests move through a structured ordering pipeline with vendor and leasing-company master data behind them, so procurement is tied to the asset record it will eventually create.
Maintenance and workshop management. Maintenance events are recorded against the asset with supporting attachments, and notifications keep the relevant people informed without anyone chasing status by phone.
Digital inspections. Inspections are captured as structured checklists with controlled status transitions, and the completed inspection is rendered as a formatted PDF document — the same artefact the business previously produced on paper, now generated from data that can also be reported on.
Tire lifecycle management. Tires are managed as inventory with their own history: registration into an available pool, mounting to a specific position on a specific unit, rotation, and retirement. This turns a large consumable cost into a tracked, analysable asset class.
Fuel consumption monitoring. Refuelling is logged against units and measured in consumption cycles. Configurable calculation parameters and tolerance bands let the business define expected performance per unit type and surface deviations, so exceptions are found by the system rather than by manual review.
Dispatch and trip management. Trips, freight orders and route circuits are planned and tracked through entry and exit events to closure, with active-trip views for controllers and a restricted external view for partner-side visibility.
Settlement and financial capture. Trip settlements, deposits and payment receipts are recorded against the trips and units they relate to, closing the loop between operational activity and its financial record.
Depot slot scheduling. Loading and service slots are generated, checked for availability, booked and cancelled through the system, which smooths yard congestion and gives visibility of committed capacity.
Configurable workflows and digital document files. Approval processes are defined as data, and every entity carries a digital file of its attachments, so supporting evidence sits with the record rather than in someone's inbox.
Administrative and people processes. The platform also covers internal ticketing, organisational structure, HR document generation, survey capture and site-level configuration — the surrounding administrative work that keeps a distributed operation running.
Reporting, import and export. Grid-based reporting with filtering and export, bulk CSV import with validation, and spreadsheet output for downstream analysis.
Key Features
Unified asset register One authoritative record per unit covering specification, ownership, location, status history and documents. Every other module reads from and writes to this record.
Structured digital inspections with PDF output Checklist-driven inspection capture with controlled status transitions, producing a formatted PDF of the completed inspection for compliance and hand-off purposes.
Tire lifecycle and mounting management Tires are tracked from purchase into an available pool, mounted to specific positions on specific units, rotated and retired — with full history per tire and per unit.
Fuel consumption analytics with tolerance bands Refuelling logs are evaluated over defined consumption cycles against configurable parameters and statistical tolerance bands, so units performing outside expectation are surfaced automatically.
Configurable workflow and approval engine Processes, stages and dynamic form components are defined as configuration. Requests route through stages with status, commentary and audit trail, so new approval paths do not require development work.
Dispatch, trip and freight management Planning and tracking of trips, freight orders and route circuits through entry, exit and closure events, with live views of what is currently active.
Maintenance management with document trail Work records attached to assets, with supporting files and automated notifications to keep workshop, operations and management aligned.
Depot slot scheduling Generation, availability checking, booking and cancellation of loading and service slots, giving sites a controlled view of committed capacity.
Settlement and receipt capture Trip settlements, deposits and payment receipts recorded against operational records, connecting activity to its financial outcome.
Bulk import and reporting exports Validated CSV import for onboarding and periodic data loads, with filtered grid reporting and spreadsheet export for analysis outside the platform.
Technical Architecture
The platform follows a layered architecture:
Presentation layer. Browser-based interface combining server-rendered views with JavaScript-driven modules. Data-heavy screens use client-side grid components backed by server-side paging and filtering; dynamic modules communicate with the application over JSON endpoints.
Application / API layer. A front controller routes requests to domain controllers — one per business area. Controllers handle request validation, authorisation and orchestration, and return either a rendered view or a JSON payload for the interactive modules. This dual-mode controller design is what allowed progressive modernisation of the interface without re-architecting the back end.
Business logic layer. Domain rules live in models and shared service classes: workflow routing and stage transitions, fuel consumption calculations and tolerance evaluation, inspection state machines, tire mounting rules, and document generation. Keeping these out of the presentation layer is what makes the same logic reusable across the web interface, PDF output and export paths.
Data layer. A relational database holds the operational record. A second, separate relational data source is read as a bridge to a pre-existing back-office system, allowing the new platform to be adopted without first decommissioning the old one.
Supporting services. Document generation (PDF), spreadsheet and CSV processing, transactional email delivery, file/attachment storage, and a scheduled task that dispatches notification email outside the request cycle.
Delivery pipeline. Source control triggers a continuous integration pipeline that runs an automated deployment: dependency installation, code release, autoloader regeneration, application server reload and permission normalisation.
Flow: Browser (server-rendered views + JS modules) → Front controller & routing → Domain controllers (HTML or JSON) → Business logic & services → Relational database + legacy data bridge → PDF / spreadsheet / email outputs
Technology Stack
| Category | Technology |
|---|---|
| Backend language | PHP |
| Backend framework | CodeIgniter (MVC) |
| Primary database | MySQL |
| Secondary data source | Microsoft SQL Server |
| Frontend | AngularJS, jQuery, Bootstrap |
| UI components | DataTables, Select2, FullCalendar, rich text editing, notification/dialog libraries |
| Charting & visualisation | JavaScript charting libraries for dashboards and org structure |
| Documents | PDF generation library; PhpSpreadsheet and CSV libraries for import/export |
| SMTP delivery via PHPMailer | |
| Dependency management | Composer |
| CI/CD | CircleCI with Capistrano-based automated deployment |
| Web server | Apache (with IIS configuration also supported) |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| A very wide functional surface — dozens of business areas in one platform | Modular structure over shared master data and a single security model. Each business area owns its controllers, data access and views, so modules can be built, changed and released independently. |
| Approval processes that differ per business area and change over time | A data-driven workflow engine: processes composed of stages, stages composed of dynamic form components, requests routed with recorded status and commentary. New processes are configured rather than coded. |
| Two different database platforms in one application | An abstraction over data access that isolates dialect differences, with the legacy platform used strictly as a read/reporting bridge so the new system's write model stays clean. |
| Replacing legally significant paper forms | Structured capture of inspection data with controlled state transitions, plus server-side generation of a formatted PDF that reproduces the required document from the stored data. |
| Turning raw fuel logs into actionable exceptions | Consumption measured over defined reset cycles against configurable parameters, with tolerance bands that flag deviation automatically instead of relying on manual review. |
| Modernising a live system without disrupting operations | Versioned controller and view generations running side by side, with module-by-module cutover and immediate fallback if a module needed to be reverted. |
| Large data grids and heavy exports slowing the interface | Server-side paging, filtering and sorting for all list views; JSON endpoints scoped to what the screen renders; streamed spreadsheet generation for large exports; notification email moved out of the request path into a scheduled sender. |
| Bulk data loads arriving in inconsistent formats | Validated import pipeline that checks file structure and content before any data is committed, so a malformed upload is rejected cleanly rather than partially applied. |
Security & Reliability
Authentication. Session-based authentication with server-side session storage. Sessions are additionally bound to attributes of the connecting client, providing a control against session reuse from another context.
Authorisation. Role information is attached to the authenticated user and route access is evaluated centrally before a controller action executes, rather than being re-implemented in each module. Public and authenticated view namespaces are kept separate.
Data validation. Server-side validation on write paths, with dedicated validation for bulk imports so that file-based data entry is held to the same standard as form entry.
Auditability. Status changes, workflow transitions and approvals are recorded rather than overwritten, and supporting documents are attached to the records they evidence — which is what makes the operational history defensible after the fact.
Application logging and error handling. Framework-level logging with environment-specific error display, so diagnostic detail is available to operators without being exposed to users.
File and document handling. Uploaded evidence and generated documents are stored against their parent records with controlled access through the application rather than direct exposure.
Repeatable deployment. Automated release through CI reduces configuration drift between environments and makes rollback a known procedure rather than an improvisation.
Scalability & Performance
Server-side data handling. Every large list is paged, filtered and sorted at the database level. The browser never receives a dataset it is not about to display.
Targeted JSON endpoints. Interactive modules fetch exactly the data a component needs, which keeps payloads small and avoids full-page reloads on data-heavy operational screens.
Scoped queries. Operational data is filtered by location and status at query level, so working sets stay proportional to what a given site actually handles rather than to the size of the whole fleet.
Work moved out of the request path. Notification email is dispatched by a scheduled sender rather than during user requests, so user-facing response times are not tied to mail server behaviour.
Efficient document and export generation. Spreadsheet and PDF generation use streaming-capable libraries so large exports do not scale linearly in memory.
Horizontal readiness. The application layer is request-stateless apart from session and file storage, so it can be placed behind a load balancer with those two concerns externalised.
Business Outcomes
- One operational record per asset. Specification, ownership, location, maintenance, inspections, tires, fuel and documents resolve to a single record, so questions about an asset are answered from one place.
- Processes that are enforced rather than assumed. Approvals, acquisitions and status changes follow a defined path with an audit trail, which improves control over spend and makes decisions traceable.
- Compliance documentation available on demand. Inspection records are captured digitally and rendered as formal documents whenever required, replacing paper retrieval.
- Visible control of major cost lines. Fuel deviation and tire lifecycle are monitored systematically, so exceptions surface without manual analysis.
- Reduced manual and duplicate data entry. Shared master data and bulk import replace re-keying between spreadsheets and systems.
- Comparable visibility across distributed sites. Head office sees consistent data from every location, while sites retain views scoped to their own operation.
- Coexistence with existing systems. The platform was adopted without first decommissioning the legacy back-office database, lowering the risk of the transition.
- A platform that keeps evolving. The modular structure and configurable workflow engine mean new processes and modules are added without destabilising what already works.
Why it worked
Projects of this shape are not difficult because any single feature is hard. They are difficult because there are forty features, they share data, they are used by people with different jobs at different sites, and the system cannot stop working while it is being improved.
Our team brought the engineering practices that make that manageable: modelling the domain before building screens, isolating business rules so they can be reused across web, document and export paths, building configuration-driven engines where the business is likely to keep changing its mind, and modernising a live production system incrementally instead of betting the operation on a rewrite. We also built the delivery discipline around it — automated, repeatable deployment so that shipping a change to a system people depend on is routine.
Our teams work across PHP, JavaScript and relational database platforms, and are comfortable integrating with the legacy systems that real businesses actually have, rather than the clean slate that project plans assume.
Final Summary
An asset-intensive transport operator was running a complex business on tools that could not see each other. Fleet data, maintenance history, compliance records, fuel and tire costs, dispatch and settlement each lived in their own spreadsheet, form or legacy database. The cost was not just inefficiency — it was the inability to answer basic operational questions with confidence.
Our team designed and delivered a single operations platform built around the asset lifecycle. It carries one authoritative record per asset, structures the workflows that surround it, digitises compliance capture with formal document output, and applies analysis to the consumable costs that quietly dominate fleet economics. Underneath it sits a configurable workflow engine, so the processes the business runs on can change without a development cycle. The platform was introduced module by module into a live operation, and integrates with the existing back-office database rather than demanding its removal.
The engineering value here is in breadth handled well: a wide domain modelled coherently, business logic kept reusable across interface, document and export paths, performance designed in through server-side data handling, and a delivery pipeline that makes ongoing change safe. For any organisation whose operational reality is spread across spreadsheets, paper and a system nobody wants to touch, this is the pattern that consolidates it — without asking the business to stand still while it happens.