RentFlow — Fleet & Rental Operations Platform
Vehicle rental SaaS combining reservations, contracts, GPS tracking, immobilization workflows, analytics, and agency operations.
Visual Proof
Fleet Dashboard
Live map showing all vehicles with status indicators, last ping time, and quick-action menu per vehicle.
Vehicle List
Complete vehicle inventory with status, GPS last-seen, and quick actions per vehicle.
Live GPS Tracking
Real-time GPS map view showing vehicle positions updated via Server-Sent Events.
Contract Generation
Auto-filled contract template with client details, vehicle info, dates, and pricing. PDF export ready for signature.
Analytics Dashboard
Fleet utilization charts, revenue per vehicle, cost breakdown, and agency KPI summary cards.
Analytics Detail
In-depth analytics view with time-range filters, per-vehicle breakdowns, and trend data.
Vehicle Control Panel
Two-step immobilization workflow with speed gate, audit trail, and SMS alert to driver.
Maintenance Module
Maintenance scheduling and service history per vehicle with cost tracking.
GPS Device Setup
GPS hardware onboarding flow linking Teltonika device IMEI to a vehicle in the fleet.
Marketing Storefront
Customer-facing rental storefront allowing clients to browse vehicles and request reservations.
Problem & Solution
Fleet Operations Running on Paper and WhatsApp
Vehicle rental agencies in Morocco operated without any operational software. Bookings were tracked in WhatsApp groups and paper calendars. Contracts were handwritten, signed physically, and filed in folders. When a vehicle left the lot, the agency had zero visibility — no location, no status, no alerts. End-of-day reconciliation meant cross-referencing paper records against a spreadsheet by hand. Immobilizing a vehicle (to recover from a defaulting client) meant calling a mechanic to physically cut a relay — hours later, sometimes not at all.
- No real-time vehicle location or status visibility after departure
- Paper contracts and manual booking reconciliation took hours per day
- Double-bookings happened regularly due to no shared availability system
- Vehicle immobilization was a slow, undocumented, manual process
- No fleet utilization data — agencies couldn't identify underperforming vehicles
- WhatsApp-based reservation flow created no paper trail and no conflict detection
Full-Stack Fleet Operations Platform with Live GPS Telemetry
RentFlow is a SaaS platform that replaces every manual workflow in a vehicle rental agency: reservations with conflict detection, auto-generated contracts, live GPS tracking via Teltonika hardware, remote immobilization with safety gates, analytics dashboards, and multi-role access for agencies, agents, and customers.
- Live GPS map: vehicle positions updated in real-time via Server-Sent Events
- Calendar-based reservation system with atomic conflict detection at the database level
- Auto-generated PDF contracts with all agency/client/vehicle data pre-filled
- Two-step immobilization workflow with speed check, audit trail, and SMS alert to driver
- Fleet analytics: utilization rate, revenue per vehicle, cost tracking, agency KPIs
- Role-based access: agency admin, field agent, and customer-facing views
- Custom TCP server parsing Teltonika binary AVL protocol directly
Architecture
RentFlow has two separate ingestion paths that converge at the database. The GPS telemetry path is a custom Node.js TCP server parsing Teltonika binary protocol, feeding normalized events into PostgreSQL/PostGIS and a Redis state cache. The application path is a NestJS REST API served by the Next.js frontend. Real-time updates travel from the telemetry path to the frontend via Server-Sent Events, not polling.
- 1
Teltonika GPS device sends binary AVL data packet over raw TCP connection every 30 seconds or on event
- 2
Custom Node.js TCP server authenticates device by IMEI, parses binary packet into structured event
- 3
Parsed event (lat, lng, speed, heading, ignition, I/O states) written to PostgreSQL with PostGIS geometry
- 4
Redis vehicle state cache updated with latest position and status for fast dashboard reads
- 5
NestJS SSE gateway detects state change and pushes event to the agency's active dashboard connection
- 6
Frontend map updates marker position without polling — only on server push
- 7
Immobilization command follows reverse path: API validates safety conditions, sends GPRS command to device
Technical Challenges
Parsing Teltonika Binary AVL Protocol over Raw TCP
Why it was hard
Teltonika GPS devices don't speak HTTP. They send binary Codec 8/8E AVL packets over a raw TCP socket. The packet format includes: preamble, data length, codec ID, number of records, each record containing a timestamp, GPS element, IO element count, and up to 100 I/O event IDs — each with 1, 2, 4, or 8-byte values depending on type. Getting this wrong silently corrupts telemetry data.
How I solved it
Wrote a custom Node.js TCP server with a stateful binary parser. Each device maintains a persistent TCP socket connection. The parser reads bytes sequentially, validates checksums (CRC-16), and maps I/O element IDs to named signals (ignition, speed, fuel, immobilizer relay state). Device authentication happens via IMEI lookup in the first packet handshake.
Result
Reliable, low-latency telemetry ingestion. The parser handles packet fragmentation (a packet split across two TCP segments) and reconnection without data loss.
Safe Vehicle Immobilization Workflow
Why it was hard
Remotely stopping a moving vehicle is a safety and legal issue. A single button press could cause an accident. Agencies also needed full legal coverage — a traceable record of who authorized the command, when, and under what conditions.
How I solved it
A two-step workflow: (1) manager confirms immobilization intent with a reason; (2) backend checks current GPS speed — if above 15 km/h, the command is queued, not sent immediately, and the system waits for the vehicle to slow down. GPRS command is sent to device I/O only when speed condition is met. Every step is logged to an immutable audit table: operator ID, timestamp, speed at command time, command state. SMS sent to driver via gateway on command execution.
Result
Zero unintended immobilizations in production. Complete audit trail satisfies legal requirements. The speed gate prevents the most dangerous failure mode.
Reservation Conflict Detection Under Concurrent Load
Why it was hard
Multiple agents working simultaneously can both attempt to book the same vehicle for overlapping dates. A naive implementation — check availability, then insert — creates a race condition where both agents see the vehicle as available, both insert, and a double-booking occurs.
How I solved it
Reservations are written inside a PostgreSQL transaction with a SELECT FOR UPDATE lock on the vehicle's reservation rows for the requested date range. If a conflicting reservation is detected inside the transaction, it rolls back and returns a conflict error to the API. The UI shows real-time availability indicators via optimistic updates, but the authoritative check is always at the database level.
Result
Zero double-bookings in production. The lock scope is narrow enough (per vehicle, per date range) to not create contention between agents booking different vehicles.
Real-Time Map Updates Without Polling
Why it was hard
A map showing 20+ vehicles updating every 30 seconds would generate significant polling load if each frontend client polled independently. At agency scale (multiple agents viewing the same dashboard), this multiplies. WebSockets add reconnection complexity and bidirectional overhead not needed for a read-only live map.
How I solved it
Server-Sent Events (SSE) over HTTP/2. Each authenticated dashboard session opens one SSE connection scoped to the agency. The NestJS SSE gateway subscribes to vehicle state change events from the telemetry layer (via an in-process event emitter and Redis pub/sub for horizontal scale). Only changed vehicle positions are pushed — not full fleet snapshots.
Result
Live map updates with sub-second latency from device ping. Server load scales with number of agencies, not with number of agent browser sessions.
Key Engineering Decisions
PostgreSQL + PostGIS over MongoDB for all data
Why
GPS telemetry requires geospatial queries: find vehicles within a polygon, calculate route distance, query movement history within a time window. PostGIS provides these natively with index support. The relational model also enforces the referential integrity required by the reservation → contract → vehicle chain.
Alternative considered
MongoDB's flexible schema would simplify early telemetry storage but loses PostGIS geospatial query power and ACID transaction guarantees needed for reservation locking.
Custom TCP server over MQTT broker for telemetry ingestion
Why
Teltonika devices speak their own binary protocol over TCP/UDP. Using an MQTT broker would require a translation layer (device → MQTT gateway → broker → backend) with additional infrastructure. A direct TCP server eliminates the translation hop, gives full protocol control, and handles Teltonika-specific features (codec selection, I/O mapping) without abstraction leakage.
Alternative considered
An MQTT broker with a Teltonika codec adapter is a valid production architecture for very large fleet scale. At the scale RentFlow targets, the direct TCP server is simpler and fully controllable.
NestJS over Express for the API layer
Why
RentFlow's feature count is high: auth, reservations, contracts, telemetry, analytics, PDF generation, immobilization, role guards. NestJS's module/controller/service structure, dependency injection, and guard/interceptor system made each feature independently testable and bounded. An Express app at this feature count becomes an unstructured collection of middleware.
Alternative considered
Express is lighter and faster to start. The maintainability cost becomes clear at feature 10+.
Impact
Eliminated paper-based contract and booking workflows
Contract generation that took 15+ minutes of manual data entry is now automatic. Booking conflicts that required phone calls between agents are detected at the system level.
Real-time fleet visibility where none existed before
Agencies went from zero visibility after a vehicle left the lot to a live map showing every vehicle's position, speed, ignition status, and last seen time.
Traceable immobilization replacing undocumented manual process
The dangerous phone-to-mechanic immobilization process was replaced with a safety-gated, audited workflow. Every command has a timestamp, operator, speed-at-time, and outcome logged.
Operational data enabling fleet decisions
Utilization rates, revenue per vehicle, and maintenance cost tracking gave agencies the data to make decisions about fleet composition that previously relied on gut feeling.
What I Would Improve Next
These aren't speculative features — they're the gaps I identified while building and operating the system.
Full multi-tenancy with agency isolation
Current architecture is single-tenant per deployment. Multi-tenant architecture with strict data isolation, per-agency billing, and agency onboarding flow would enable SaaS distribution.
Native mobile app for drivers
A lightweight driver app using the phone's GPS as a fallback when hardware devices fail or for short-term rental vehicles without Teltonika hardware.
Predictive maintenance alerts
Mileage-based and telemetry-pattern-based maintenance alerts: brake behavior patterns, idle time accumulation, engine temperature anomalies.
Online payment and deposit collection
Integrating a payment gateway to collect rental deposits online, tied to the reservation flow, would remove the last cash-dependent step in the process.
E2E test coverage for the booking and immobilization flows
The two highest-risk flows — concurrent reservation and immobilization — deserve full integration test coverage with a real test database, not just unit tests of individual services.
Interested?
Let's talk about what I can build for you.
Open to senior full-stack roles, founding engineer positions, and contract engagements. Remote only.