Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Fleet manager

FleetManager

Inspiration

FleetManager was inspired by the operational challenges many transport and logistics businesses face every day, especially in environments where internet connectivity is unreliable. I wanted to build a platform that goes beyond simple vehicle tracking — a system that helps fleet operators manage drivers, trips, maintenance, fuel records, and day-to-day fleet operations from one place while still working smoothly even when users go offline.

The idea came from observing how much manual coordination happens in fleet businesses: drivers reporting updates through calls or WhatsApp, dispatchers struggling to track vehicle availability, and managers having limited visibility into maintenance schedules, fuel usage, and trip performance. In many cases, cloud-only systems break down when internet access becomes unstable. That challenge pushed me toward building an offline-first fleet management SaaS designed for real-world operational conditions.


What it does

FleetManager is an offline-first fleet management platform that helps transport businesses and logistics teams manage their operations across web and mobile.

It is designed to support:

  • Vehicle management
  • Driver management
  • Trip assignment and trip tracking
  • Maintenance scheduling
  • Fuel and expense logging
  • Operational visibility for dispatchers and managers
  • Offline data capture and later synchronization

The web dashboard is intended for admins, dispatchers, and fleet managers, while the mobile app is designed for drivers and field operators who need to continue working even without a stable internet connection.


How I built it

FleetManager is being built as a monorepo SaaS application so that both the web and mobile products can share core business logic, types, and sync behavior.

Core stack

  • Next.js for the fleet admin dashboard
  • React Native for the mobile driver application
  • TypeScript across the stack for consistency and maintainability
  • Supabase / PostgreSQL for backend services, auth, and data persistence
  • Shared packages for reusable types, utilities, and sync logic
  • Offline-first local storage + sync architecture for resilient field usage

Architecture approach

The project is structured around two main applications:

  • "apps/web" → admin and operations dashboard
  • "apps/mobile" → driver and field operations app

It also includes shared packages for:

  • UI components
  • domain types
  • utilities
  • database helpers
  • sync logic

The goal was to avoid duplicating business logic between platforms and to create a foundation that can scale as the product grows.


Offline-first thinking

One of the core design ideas behind FleetManager is that internet access should improve the product, not determine whether it works at all.

Instead of assuming every user action can immediately reach the server, the app is designed around a simple sync model:

[ \text{Local Action} \rightarrow \text{Queue} \rightarrow \text{Sync When Online} \rightarrow \text{Conflict Resolution if Needed} ]

This means drivers and operators can continue recording trip updates, status changes, and operational data locally, and the system can synchronize those updates once connectivity is restored.

A simplified way to think about the flow is:

  1. User performs an action offline
  2. Data is stored locally
  3. Action is added to a sync queue
  4. When the network returns, the queue is processed
  5. The server validates and merges updates
  6. The local state is refreshed with the latest synced result

Challenges I ran into

One of the biggest challenges was designing the system around real-world constraints instead of ideal ones.

  1. Offline synchronization complexity

Offline-first apps are much harder to reason about than traditional online dashboards. I had to think through:

  • local persistence
  • retry behavior
  • duplicate submissions
  • partial sync failures
  • stale records
  • conflict resolution between local and remote updates
  1. Product scope

Fleet management is not a single-feature product. It touches multiple connected workflows:

  • vehicles
  • drivers
  • dispatch
  • trip records
  • expenses
  • maintenance
  • reporting

The challenge was figuring out what should be part of the MVP and what should come later without making the architecture messy.

  1. Multi-platform consistency

Because the product includes both web and mobile, I needed to think carefully about what logic should live in shared packages and what should remain platform-specific. The aim was to keep the experience consistent without forcing both platforms into the exact same implementation.


What I learned

Building FleetManager taught me a lot about designing software for operations-heavy businesses.

Key things I learned

  • How to think in terms of business workflows, not just pages and CRUD forms
  • How offline-first architecture changes the way data flow is designed
  • How to structure a scalable monorepo for multiple apps
  • How to separate shared domain logic from UI-specific code
  • How to plan for future SaaS concerns like:
    • multi-tenancy
    • permissions
    • billing
    • reporting
    • operational analytics

More importantly, I learned that building useful software often means designing for imperfect environments. A good system should still be reliable even when connectivity, devices, or field conditions are inconsistent.


Why I built this

I built FleetManager because I wanted to create something that solves a practical business problem, especially in places where operations often depend on manual processes and unreliable connectivity. I’m interested in building software that doesn’t just look good in demos, but actually supports the way people work in the real world.

FleetManager represents that goal for me: a product that combines SaaS architecture, operational tooling, and offline resilience into a single platform for transport and logistics teams.


Future improvements

As the project grows, I want to expand FleetManager with:

  • real-time dispatch visibility
  • maintenance reminders and service history
  • fuel analytics and expense reporting
  • role-based access control
  • organization-level dashboards
  • subscription and billing support
  • smarter sync conflict handling
  • more advanced reporting for fleet performance

Summary

FleetManager is my attempt to build a practical, scalable, and offline-capable fleet operations platform for logistics and transport teams. It started from a simple observation — many fleet businesses still rely on fragmented tools and unstable connectivity — and grew into a project focused on making fleet operations easier to manage across both web and mobile.

Built With

Share this project:

Updates