Skip to content
← All work

Case study · Fleet operations and booking management ecosystem

Fleetovo

A centralised fleet operations platform managing bookings, duties, vehicles, drivers, estimates, payments, invoices, purchases, ledgers, and reporting through one connected system.

LiveFleet operationsBookingFinancial workflows
Amit's role
Technical Head / Full-Stack Developer
Project type
Fleet operations and booking management ecosystem
Organisation
URV India Pvt. Ltd.
Team context
Company product · contribution within URV India Pvt. Ltd.

Primary technologies

  • Spring Boot
  • Java
  • MySQL
  • Angular
  • Tailwind CSS
  • REST APIs
Redacted Fleetovo booking details interface showing an operational booking workflow
Booking workflow detail

Outcome snapshot

The project in operational terms.

Scope, complexity, responsibility, and business outcomes are described without unsupported statistics.

01

What was built?

A Spring Boot and MySQL backend, an Angular employee application, and shared APIs for employee, client, driver, estimate, payment, invoice, and reporting experiences.

02

Who uses it?

Employees coordinate operations; the backend is designed to support client-facing booking and driver-facing duty applications.

03

Why does it matter?

Fleet work crosses allocation, live duties, customer communication, financial records, purchases, and reporting, so state must remain consistent across operational handoffs.

04

What did Amit own?

Amit designed and developed the core backend, built the employee application, translated fleet operations into digital workflows, and continues hands-on implementation while leading delivery.

05

What changed?

Fragmented fleet processes are consolidated into a shared operational source of truth for bookings, duties, vehicles, drivers, clients, and financial records.

Business and operational context

Understand the operation before the technology.

Fleet operations extend well beyond creating a booking. Estimates may become paid bookings; bookings contain one or more duties; duties require vehicle and driver allocation, controlled starting and closing, and complete operational records before invoicing.

Fleetovo models that lifecycle as connected backend workflows. The aim is consistent state and traceability across operational, customer, driver, purchase, payment, ledger, and reporting concerns rather than a collection of disconnected screens.

Product scope

Product capabilities.

Capabilities describe the product; Amit's contribution is documented separately below.

Estimates and booking conversion

A client-facing path from a prepared estimate to an operational booking.

  • Employees prepare and share estimate links
  • Clients can review and pay through the estimate workflow
  • A successfully paid estimate can be converted into a connected booking
  • Estimate and booking records remain linked

Booking and duty operations

Structured control of multi-duty bookings and their real-world execution.

  • Create and manage bookings with multiple duties
  • Assign or reassign vehicles and drivers
  • Allow drivers or authorised employees to start assigned duties
  • Capture completion information and duty-slip details
  • Maintain controlled booking and duty states

Invoices, payments, purchases, and ledgers

Financial records remain connected to their operational source.

  • Generate and download invoices after required booking completion
  • Record payment-in and payment-out entries
  • Create purchase invoices and vendor expenses
  • Maintain client and vendor ledgers

Reports and shared API ecosystem

Operational data supports employee, customer, driver, finance, and reporting experiences.

  • Sales, purchase, operational, and financial reports
  • Supported PDF, CSV, and JSON exports
  • Shared REST APIs for employee operations, client booking, driver duty, estimate, payment, invoice, and report workflows

Personal contribution

Amit's contribution and responsibilities.

Leadership, implementation, and team contribution are described separately to avoid overstating individual ownership.

01

Architecture

Designed the Spring Boot backend, MySQL data model, API boundaries, and workflow contracts across booking, duty, financial, purchase, ledger, and reporting concerns.

02

Implementation

Developed the core backend and built the Angular and Tailwind CSS employee operations application.

03

Team leadership

Continues direct architecture and implementation work while setting technical direction and reviewing delivery decisions.

04

Delivery coordination

Coordinates backend, employee-interface, client, driver, payment, invoice, and reporting requirements without claiming every client or driver application is publicly released.

05

Production ownership

Maintains production workflows and resolves issues with attention to active bookings, duties, and financial records.

06

Stakeholder collaboration

Translated real fleet-management operations into implementable rules and connected digital workflows.

Constraints

The boundaries that shaped the work.

These are product and delivery constraints, not a disclosure of private production configuration.

Constraint 01

State-dependent operations

Estimate, booking, duty, payment, and invoice actions depend on valid prior state.

Constraint 02

Multi-duty bookings

A booking can contain several duties with different vehicle, driver, and completion contexts.

Constraint 03

Financial consistency

Operational completion, purchases, invoices, payments, and ledgers must retain their relationships.

Constraint 04

Application boundaries

The shared backend must support employee, client, and driver experiences without coupling every rule to one interface.

Constraint 05

Confidential operations

Client, driver, vehicle, payment, and company records cannot be exposed in public evidence.

System architecture

Shared fleet-operations API and workflow architecture

A static, keyboard-inspectable model with visible relationships and a complete text alternative.

Architecture model

Fleetovo platform architecture

A shared Spring Boot API coordinates employee operations today and provides the foundation for client and driver applications.

Layer 01

Applications

Interfaces built on the shared operational model.

  • Employee operations portal

    Angular and Tailwind CSS application for daily fleet work.

  • Client-facing applications

    Backend-supported booking, estimate, payment, history, and invoice experiences.

  • Driver-facing applications

    Backend-supported assignment and duty lifecycle experiences.

Layer 02

Spring Boot API

Validation, authority, and workflow orchestration.

  • Estimate, booking & duty

    Conversion, multi-duty lifecycle, allocation, and completion.

  • Invoice, payment & ledger

    Connected financial records and documents.

  • Purchases & vendors

    Purchase invoices, expenses, outgoing payments, and vendor ledgers.

Layer 03

Data and evidence

Persistent operational and reporting context.

  • MySQL

    Relational operational and financial records.

  • Documents & exports

    Invoices and supported PDF, CSV, and JSON reports.

Relationships

  1. Employee operations portalSpring Boot APIcoordinates fleet operations
  2. Client-facing applicationsEstimate, booking & dutyuse shared booking and payment data
  3. Driver-facing applicationsEstimate, booking & dutyuse authorised duty actions
  4. Estimate, booking & dutyInvoice, payment & ledgerprovides completed operational context
  5. Spring Boot APIMySQLpersists controlled records

Text alternative

The Angular employee portal, estimate links, payment workflows, and supported client and driver applications use a shared Spring Boot REST API. Domain services coordinate booking, duty, allocation, invoices, payments, purchases, ledgers, and reports over MySQL records and document-generation boundaries.

Visual evidence

Reviewed product interfaces.

Public screenshots are presented in full without cropping. Private product images use opaque, irreversible redaction.

Redacted Fleetovo operations dashboard
Operations overview
Redacted Fleetovo booking overview interface
Booking workflow
Redacted Fleetovo payment details interface
Payment workflow

Key decisions

Trade-offs, not slogans.

Each decision records what was selected, what was considered, and the cost accepted.

Decision 01

Use one shared API foundation

Why selected
Employee, client, and driver experiences need consistent booking and duty rules.
Alternative considered
Implement separate workflow logic inside each application.
Trade-off accepted
API contracts and authority context require careful versioning.
Current result
Operational rules remain central while interfaces can evolve independently.

Decision 02

Keep estimate and booking records connected

Why selected
A paid estimate becomes operational work and must retain its commercial context.
Alternative considered
Create an unrelated booking after payment.
Trade-off accepted
Conversion rules and references add lifecycle complexity.
Current result
The estimate-to-booking path remains traceable.

Decision 03

Generate finance from completed operations

Why selected
Invoices need final duty and booking context.
Alternative considered
Allow independent invoice creation without workflow guards.
Trade-off accepted
Completion checks must be maintained as business rules evolve.
Current result
Invoices and ledgers remain grounded in operational records.

Selected implementation

Safe examples of system behavior.

These examples are simplified and generic. They contain no credentials, client data, internal URLs, or confidential production code.

Example 01

Estimate-to-booking workflow

A safe product-level sequence without payment-provider or client data.

  1. 01

    Prepare estimate

    Employee creates shareable service and pricing context.

  2. 02

    Client review

    Client reviews the estimate through its link.

  3. 03

    Record successful payment

    The workflow confirms an accepted payment outcome.

  4. 04

    Convert to booking

    Create the connected operational booking.

Example 02

Multi-duty booking lifecycle

A booking can coordinate several duties before final invoicing.

  1. 01

    Create booking

    Capture client and service context.

  2. 02

    Add duties

    Create the required operational work.

  3. 03

    Allocate resources

    Assign or reassign vehicles and drivers.

  4. 04

    Start and close duties

    Capture controlled progress and completion information.

  5. 05

    Complete financial workflow

    Generate invoices, payments, ledgers, and reports from approved records.

Impact

Qualitative, evidence-based outcomes.

  1. 01Consolidates bookings, duties, allocation, payments, invoices, purchases, ledgers, and reports into one consistent workflow.
  2. 02Provides employees and backend-supported client and driver experiences with shared operational data.

Reflection

What the work teaches next.

What worked

Explicit lifecycle and shared API boundaries keep operational and financial context connected.

What was difficult

Multi-duty state, allocation changes, financial records, and several application audiences create cross-workflow complexity.

What could improve

Continue publishing only reviewed, redacted workflow evidence and diagrams.

Next architectural step

Evolve client and driver application support through the same guarded domain contracts.

Current status

Status stated without inference.

Production platform. The employee application and shared backend are active; the backend is designed to support client and driver applications without claiming every application is publicly released.