NidamCar — SaaS Platform for Car-Rental Agencies

Overview

NidamCar is a multi-tenant SaaS platform I designed and built for professional car-rental companies, launching in November 2026. It manages fleets, reservations, rental operations, multiple agencies and vehicle costs from one system. It is designed first for the Moroccan market, with an architecture ready for wider markets and deeper integrations.

The problem

Most rental software is a reservation table with a status column. Real rentals are messier: customers extend, vehicles get swapped mid-rental, cars move between branches, deposits are held and released, and damage needs a trail. When software overwrites records instead of modelling these events, the business loses its history and its numbers become unreliable.

Organisations and agencies

The Organisation is the customer, the billable entity and the security boundary. One Organisation can run several agencies from the same account, without treating each branch as a separate tenant.

Organisation
├── Agency Casablanca
├── Agency Marrakech
└── Agency Agadir

Tenancy uses a shared database with strict Organisation scoping, designed to fail closed: if the tenant context is missing, no data is returned.

Layered authorization

NidamCar separates questions that SaaS applications often merge into one:

Organisation scope  →  whose data?
Permission          →  what can the user do?
Agency access       →  where can they do it?
Entitlement         →  what has the Organisation paid for?
Module flag         →  is the capability switched on?
Business rule       →  is this operation valid right now?

Permission to manage vehicles doesn't grant access to every agency's vehicles, and a UI permission doesn't unlock a premium feature the Organisation hasn't bought. Platform staff use a separate authentication context, so an Organisation owner is never a platform administrator.

Subscriptions by entitlement, not plan name

Plans, trials, entitlements and resource limits (agencies, users, vehicles) are modelled explicitly. Features check entitlements rather than plan labels like "Pro", so pricing can change without touching business logic. A downgrade keeps all existing data and only blocks new creation above the new limits.

The complete rental lifecycle

The rental domain models what actually happens, instead of overwriting the original reservation:

Reservation → Check-out → Active rental → Check-in → Deposit decision → Settlement
                              ├── Extensions
                              ├── Vehicle replacements
                              └── Damage and incidents

• Multi-agency rentals: pick up in Casablanca, return in Marrakech.
• Check-out and check-in: condition, mileage, fuel and actual dates are recorded at the physical handover, not inferred from a status change.
• Extensions: each one is kept as an immutable step, and availability is validated first.
• Vehicle replacements: the original vehicle and every swap are preserved, instead of overwriting a single vehicle_id.
• Deposits: held and released separately from payments, because a deposit is not revenue.
• Settlement: the final commercial state is frozen after return, rather than recalculated later from data that may have changed.
• Damage and incidents: a structured record with photos, status and resolution, not free-text notes.
• Transfers: vehicles move between agencies with a full history.

Operational control

A daily view answers the question a rental manager actually asks: what needs my attention today? Departures, expected and overdue returns, availability, and expiring vehicle documents all surface in one place.

Fleet economics

NidamCar follows each vehicle from acquisition to disposal: purchase method, financing contract terms, expenses (insurance, repairs, tyres, taxes), and finally sale, return or write-off. Disposed vehicles leave the bookable fleet but stay in the history.

A read-only economic view combines rental revenue and recorded expenses per vehicle: operating contribution, revenue and cost per rental day, and expense breakdowns. It is deliberately not presented as accounting profit. The rule is to show the economics the platform actually knows, instead of inventing precision from incomplete data.

Engineering principles

The design starts from business concepts, not CRUD screens. A few distinctions run through the whole codebase:

Organisation ≠ Agency          Maintenance event ≠ Expense
Permission ≠ Entitlement       Deposit ≠ Revenue
Financing terms ≠ Payments     Vehicle economics ≠ Accounting profit

Keeping these apart is what makes the history trustworthy and the reports correct.

Roadmap: designed, not yet built

The SaaS foundation, rental lifecycle, operational control and fleet economics are complete. Next on the roadmap:

• Reporting and dashboards: a metrics layer between the domains and the dashboards. Domains own the facts, reporting defines the measures, and dashboards present them.
• Public Booking API: lets rental companies connect their own websites, with a WordPress and Elementor plugin. Credentials resolve the Organisation server-side.
• GPS and telematics: a dedicated gateway in Go for long-lived TCP/UDP connections and binary device protocols (Teltonika, Concox), normalising telemetry through Redis before Laravel sees it. Go is chosen for the network workload, while Laravel keeps the business domain.
• Rental-aware telematics: the long-term goal. A GPS platform knows where a vehicle is. NidamCar will also know that it's rented, due back in Casablanca at 18:00, and currently near Marrakech.

My role

I own the product and technical architecture: SaaS and multi-tenant design, domain modelling, database design, subscriptions and entitlements, security and authorization, rental and fleet workflows, financial modelling, API and reporting architecture, infrastructure decisions, and the product roadmap.