Motion Frame. Owned outright.
A fleet management platform built from the ground up — a custom application rather than a third-party system, with the source code, the data, and the infrastructure belonging to Motion Frame.
A platform to own, not to rent.
Motion Frame needed a fleet management platform and had a decision to make about how to get one. A third-party system would have been faster to stand up and slower to live with — licensing, a feature roadmap owned by someone else, and data in a system they did not control.
They chose to build. That put the burden on the engineering: a greenfield application with no existing deployment to migrate, real-time telemetry from a moving fleet, and infrastructure that had to be reliable enough to run a working operation on from day one.
Eight modules a fleet operator uses daily.
Vehicle and asset registry
One catalog holding every vehicle, its documents, and its full service history.
Real-time GPS tracking
Where every vehicle is now, where it has been, and an alert when one leaves the area it should be in — telemetry through AWS IoT Core, maps and geofencing on Amazon Location Service.
Driver management
Who is licensed for what, who is in which vehicle, and the record behind both.
Maintenance scheduling
Service raised before it is overdue: preventive plans, reminders, and the work orders that follow.
Dispatch and route planning
Assign a job, plan the route, and calculate the arrival time it implies.
Reporting and analytics
Utilization, mileage, fuel and idle time, as reports that leave the system.
Role-based access
A dispatcher sees dispatch. A driver sees their own. Multi-tenant-ready from the first commit.
Alerts and notifications
Geofence breaches, speeding, and maintenance due, routed by email, SMS, or push to whoever has to act.
Five phases. Each one produces something reviewable.
Every stage ends in a concrete output before the next begins. No phase closes on a status update.
- Phase 1
Discovery
The feature set confirmed, and the fleet-size and telemetry-volume assumptions written down where they could be checked against.
- Phase 2
Planning and design
Application architecture and data model settled, and the build order sequenced before anything was written.
- Phase 3
Implementation
Application and infrastructure built together across eight stages, each ending in something that ran — landing zone first, then the API on ECS Fargate and PostgreSQL on RDS, the telemetry pipeline, the dashboard on CloudFront, and hardening last.
- Phase 4
Testing
Functional, load, and failover testing, including telemetry ingestion at the fleet volume the assumptions named, and Multi-AZ database failover.
- Phase 5
Knowledge transfer
Documentation, codebase, runbooks, and training handed to the people who now operate it.
What Motion Frame owns.
- A custom fleet management web application: dashboard and backend API, containerised on ECS Fargate.
- Real-time GPS tracking and geofencing across the full fleet.
- Driver, vehicle, and maintenance management modules.
- A Multi-AZ production environment on AWS, and a mirrored staging environment for pre-production testing.
- CI/CD pipelines on GitHub Actions for both application and infrastructure, authenticating by OIDC rather than stored keys.
- Monitoring, alerting, and automated backups across both environments.
- Every AWS resource defined in Terraform, documented, with remote state.
- Source code and documentation handed to the Motion Frame team.