transitops

Inspiration

Fleet operations involve a chain of dependent decisions: vehicle availability, driver eligibility, cargo capacity, maintenance, fuel, expenses, revenue, and billing. Managing these workflows independently creates inconsistencies and makes operational decisions slower.

We built TransitOps to bring these processes into one connected system. The core idea was simple: when an operational event occurs, every dependent part of the system should reflect that change automatically.

For example, placing a vehicle into maintenance should immediately remove it from trip dispatch, while an expired or suspended driver should no longer be eligible for assignment.

What it does

TransitOps is a fleet and transit operations platform covering the complete operational lifecycle.

It provides:

Vehicle registry and fleet status management
Driver profiles, safety scores, and license validation
Trip creation and dispatch with real-time eligibility checks
Maintenance workflows with automatic vehicle status transitions
Fuel and operational expense tracking
Fleet analytics and financial reporting
JWT authentication and role-based access control
Billing, invoicing, and payment tracking

The system supports four operational roles: Fleet Manager, Dispatcher, Safety Officer, and Financial Analyst, with permissions enforced across the application.

How we built it

We designed the system around a relational data model connecting users, roles, permissions, vehicles, drivers, trips, maintenance logs, fuel logs, expenses, and billing records.

Authentication is handled through JWT-based sessions, with role-based permissions controlling module access.

Rather than treating validation as a frontend-only concern, we designed the application around explicit business rules and state transitions.

For example, trip dispatch requires:

$$ \text{Cargo Weight} \leq \text{Vehicle Max Load} $$

Only vehicles with Available status and drivers who are available with valid licenses can be assigned.

Vehicle states are updated automatically through operational events:

$$ \text{Available} \leftrightarrow \text{On Trip} $$

$$ \text{Available} \rightarrow \text{In Shop} \rightarrow \text{Available} $$

Similarly, analytics are calculated from operational data, including:

$$ \text{Fuel Efficiency} = \frac{\text{Total Distance}}{\text{Total Fuel Consumed}} $$

$$ \text{Fleet Utilization} = \frac{\text{Active Vehicles}}{\text{Total Vehicles}} \times 100 $$

This connects the operational layer directly to the reporting layer.

Challenges we ran into

The main challenge was maintaining consistency between interconnected workflows.

A single state change can affect multiple modules. For example, creating a maintenance record changes vehicle availability, which changes trip eligibility, and can subsequently affect dashboard KPIs and fleet utilization.

We therefore had to carefully define state transitions and validation rules for vehicles, drivers, trips, and maintenance.

Another challenge was implementing permissions consistently across modules. Different roles require different levels of access, so RBAC had to be part of the application architecture rather than an isolated feature.

Accomplishments that we're proud of

We are most proud of building TransitOps as a connected operational system rather than a collection of CRUD interfaces.

The system automatically propagates important operational changes across dependent workflows:

Vehicle status affects dispatch eligibility
Driver status and license validity affect assignments
Trip activity feeds operational metrics
Operational costs feed financial analytics

We also extended the platform with a billing layer that connects completed trips with clients, invoices, payments, and financial reporting — connecting the operational and financial sides of fleet management within the same system.

What we learned

We learned that designing a real-world operations platform requires thinking in terms of state, dependencies, and business rules.

One of the most useful questions throughout development was:

What else should change when this action occurs?

This helped us identify dependencies that would otherwise be easy to miss.

We also learned that analytics are most useful when they are derived directly from operational events and relationships, rather than maintained as separate data.