Fleetovo
A centralised fleet operations platform managing bookings, duties, vehicles, drivers, estimates, payments, invoices, purchases, ledgers, and reporting through one connected system.
- Technical Head / Full-Stack Developer
- Fleet operations and booking management ecosystem
- URV India Pvt. Ltd.
- Company product · contribution within URV India Pvt. Ltd.
- Spring Boot
- Java
- MySQL
- Angular
- Tailwind CSS
- REST APIs

The project in operational terms.
Scope, complexity, responsibility, and business outcomes are described without unsupported statistics.
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.
Who uses it?
Employees coordinate operations; the backend is designed to support client-facing booking and driver-facing duty applications.
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.
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.
What changed?
Fragmented fleet processes are consolidated into a shared operational source of truth for bookings, duties, vehicles, drivers, clients, and financial records.
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 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
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.
The boundaries that shaped the work.
These are product and delivery constraints, not a disclosure of private production configuration.
State-dependent operations
Estimate, booking, duty, payment, and invoice actions depend on valid prior state.
Multi-duty bookings
A booking can contain several duties with different vehicle, driver, and completion contexts.
Financial consistency
Operational completion, purchases, invoices, payments, and ledgers must retain their relationships.
Application boundaries
The shared backend must support employee, client, and driver experiences without coupling every rule to one interface.
Confidential operations
Client, driver, vehicle, payment, and company records cannot be exposed in public evidence.
Shared fleet-operations API and workflow architecture
A static, keyboard-inspectable model with visible relationships and a complete text alternative.
Fleetovo platform architecture
A shared Spring Boot API coordinates employee operations today and provides the foundation for client and driver applications.
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.
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.
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
- Employee operations portalSpring Boot APIcoordinates fleet operations
- Client-facing applicationsEstimate, booking & dutyuse shared booking and payment data
- Driver-facing applicationsEstimate, booking & dutyuse authorised duty actions
- Estimate, booking & dutyInvoice, payment & ledgerprovides completed operational context
- 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.
Reviewed product interfaces.
Public screenshots are presented in full without cropping. Private product images use opaque, irreversible redaction.



Trade-offs, not slogans.
Each decision records what was selected, what was considered, and the cost accepted.
Use one shared API foundation
- Employee, client, and driver experiences need consistent booking and duty rules.
- Implement separate workflow logic inside each application.
- API contracts and authority context require careful versioning.
- Operational rules remain central while interfaces can evolve independently.
Keep estimate and booking records connected
- A paid estimate becomes operational work and must retain its commercial context.
- Create an unrelated booking after payment.
- Conversion rules and references add lifecycle complexity.
- The estimate-to-booking path remains traceable.
Generate finance from completed operations
- Invoices need final duty and booking context.
- Allow independent invoice creation without workflow guards.
- Completion checks must be maintained as business rules evolve.
- Invoices and ledgers remain grounded in operational records.
Safe examples of system behavior.
These examples are simplified and generic. They contain no credentials, client data, internal URLs, or confidential production code.
Estimate-to-booking workflow
A safe product-level sequence without payment-provider or client data.
Prepare estimate
Employee creates shareable service and pricing context.
Client review
Client reviews the estimate through its link.
Record successful payment
The workflow confirms an accepted payment outcome.
Convert to booking
Create the connected operational booking.
Multi-duty booking lifecycle
A booking can coordinate several duties before final invoicing.
Create booking
Capture client and service context.
Add duties
Create the required operational work.
Allocate resources
Assign or reassign vehicles and drivers.
Start and close duties
Capture controlled progress and completion information.
Complete financial workflow
Generate invoices, payments, ledgers, and reports from approved records.
Qualitative, evidence-based outcomes.
- 01Consolidates bookings, duties, allocation, payments, invoices, purchases, ledgers, and reports into one consistent workflow.
- 02Provides employees and backend-supported client and driver experiences with shared operational data.
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.
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.