RentFlow: Fleet and Rental Operations
Vehicle rental SaaS combining reservations, contracts, GPS tracking, immobilization workflows, analytics, and agency operations.
Role
Full-Stack Engineer, B2B Freelance Collaboration
Timeline
2023 · Engagement completed
Type
SaaS
Screenshots
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 no location, status, or alert data. End-of-day reconciliation meant cross-referencing paper records against a spreadsheet by hand. Recovering a vehicle from a defaulting client required a mechanic to cut a relay, often hours after the request.
- 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 a preamble, data length, codec ID, record count, timestamp, GPS element, I/O element count, and up to 100 I/O event IDs. Each value can use 1, 2, 4, or 8 bytes depending on its type. A parsing error can silently corrupt 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
The workflow adds an explicit confirmation step, a speed gate and a complete audit trail to reduce the risk of unsafe or untraceable commands.
Reservation Conflict Detection Under Concurrent Load
Why it was hard
Multiple agents can attempt to book the same vehicle for overlapping dates. Checking availability before inserting creates a race condition: both agents can see the vehicle as available and create conflicting reservations.
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
The authoritative transactional check prevents conflicting writes during tested concurrent booking scenarios while keeping the lock scope narrow.
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) run over HTTP/2. Each authenticated dashboard session opens one connection scoped to the agency. The NestJS SSE gateway subscribes to vehicle-state changes through an in-process event emitter and Redis pub/sub. It pushes changed positions instead of full fleet snapshots.
Result
Changed vehicle positions are pushed to authenticated dashboards without full-fleet polling, reducing repeated reads and stale UI state.
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 improvements come from issues 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
Concurrent reservation and immobilization need integration tests against a real test database because unit tests do not cover their transaction and safety boundaries.
Interested?
Let's talk about what I can build for you.
Available immediately for senior full-stack and product engineering roles, onsite or hybrid across Morocco, plus international remote contracts.