Loading...
← All work
Case study · MotorpoolDelivered
From maintenance notebooks to a schedule and a cost line for every vehicle.
A vehicle management system for fleet operators: vehicles, recurring maintenance, repairs, parts, suppliers, taxes and cost reports, offered to many customers on subscription plans and in several languages.
- Sector
- Logistics & Fleet
- Our role
- Multi-tenant SaaS architecture, full-stack build, i18n
- Capabilities
- Platforms
- Status
- Delivered
The challenge
Fleet owners tracked services in notebooks, and paid for it in breakdowns.
Fleet owners track services in notebooks and pay for it in breakdowns. Motorpool turns maintenance into a schedule and every repair into a cost line, so the cheapest kilometre is easy to see.
What made it hard
- 01
Reactive maintenance
Work due by date or odometer is forgotten until a vehicle fails.
- 02
Invisible cost
Parts, services, suppliers and taxes are scattered, so cost per vehicle is unknown.
- 03
Productised, not bespoke
One codebase had to serve many operators, on subscription plans, in several languages.
The approach
Preventive scheduling, cost-ledgered repairs, and SaaS built into the model.
Recurring maintenance rules raise work orders before they are due, by date or distance. Every repair posts parts, services and taxes against the vehicle. Subscriptions and translations are part of the data model, and each domain lives in its own feature module on client and server.
System map
- AI step
- Person in the loop
- Service or store
How it works
- 01
Register
Vehicles are grouped into fleets with plate, model and odometer.
- 02
Schedule
Recurring maintenance by date or distance raises work before it is due.
- 03
Repair
Repairs record parts, services, suppliers and taxes against the vehicle.
- 04
Report
Cost and administrative reports show spend by fleet, category and month.
Key decisions
Built to be sold, not just used.
Decision 01
Subscriptions built in
Plans and subscribers are part of the model, so the product can be sold to many operators.
Decision 02
Translations as data
Interface text is managed in the app, so a new language is content, not code.
Decision 03
Feature folders
Each domain (vehicles, repairs, suppliers) lives in its own module on both client and server.
What shipped
A fleet console for operators.
Fleet registry
Vehicles grouped into fleets with plate, model and odometer.
Preventive schedules
Date- or distance-based rules that raise work before it is due.
Repair costing
Parts, services, suppliers and taxes posted against each vehicle.
Cost analytics
Spend by fleet, category and month.
Plans and i18n
Subscription tiers and content-managed translations.
Architecture
A cross-section of the system.
Every layer, from what people touch down to where it runs, and the one job each layer does.
L1Interface
React+Vite+Tailwind
Feature-foldered console, translated from managed content.
L2Services
Node.js+Express
Domain modules for vehicles, repairs, suppliers and plans.
L3Data
MongoDB
Fleets, schedules, cost lines, subscriptions and translations.
Our scope
SaaS architecture/Web application/Reporting and analytics/Localisation (i18n)
Where it is now
Delivered as a multi-customer, multilingual product.
Motorpool is delivered. A new language is content, not code, and feature modules on client and server keep the product easy to extend.
Something like this in mind?
Tell us the problem. We will tell you honestly if we are the right team to solve it.