Mobility & fleet apps (multi-package repo)
Vehicle Maintenance Platform
Offline Flutter car-maintenance tracker plus NestJS/MongoDB JWT API—same repo also holds an unrelated Wingz admin client and a Nest GraphQL form generator.
The challenge
Vehicle owners needed on-device service history and due-date organization; a companion API was also designed for multi-user ownership—without claiming end-to-end sync that source does not wire. Without a coherent mobility & fleet apps (multi-package repo) foundation, Vehicle Maintenance Platform stakeholders faced fragmented tools, slow handoffs, and limited visibility—classic failure modes Tekvers designs against.
The solution
Vehicle Maintenance Platform: Offline Flutter car-maintenance tracker plus NestJS/MongoDB JWT API—same repo also holds an unrelated Wingz admin client and a Nest GraphQL form generator. On-device vehicle inventory and maintenance schema foundation. Tekvers delivered a maintainable mobility & fleet apps (multi-package repo) system for Vehicle Maintenance Platform using Flutter, Provider, sqflite, NestJS 11, with phased rollout, operator workflows, and documentation suited to long-term ownership.
Approach
Offline-first mobile
SQLite keeps the garage usable without inventing a sync protocol the Flutter app does not implement.
API as companion domain
Nest models the same cars/maintenance concepts with ownership and analytics endpoints for future clients.
Repo hygiene in the narrative
Case study separates car product from Wingz admin client and form-generator tooling so reviewers are not misled.
Deliverables
- ▸Flutter maintenance tracker with Provider + sqflite
- ▸NestJS 11 `/api/v1` cars/maintenance/users/notifications API
- ▸JWT auth and admin-gated user management
- ▸Maintenance aggregation and upcoming/overdue queries
- ▸React TailAdmin client for external Wingz catalog API (separate product surface)
- ▸NestJS GraphQL form code-generator CLI with examples
Outcomes
- ▸On-device vehicle inventory and maintenance schema foundation
- ▸Multi-role Nest API ready for authenticated clients
- ▸Explicit non-claims: no mobile↔API sync, incomplete Flutter maintenance write UX (TODOs), no push delivery
- ▸Clear separation of unrelated packages in the same repo
Impact
Owners can keep a durable local maintenance record; engineers get a Nest domain model for the same problem—Tekvers documents the architectural reality instead of inventing cloud sync.
Tech stack
Want something similar?
I build production systems like Vehicle Maintenance Platform—from architecture through launch. Tell me what you need.
Contact me →