What a car rental platform taught me about data models
Building LocoAuto meant connecting a customer booking journey to an internal operations dashboard — and the data model is where the two meet.
LocoAuto started as a booking site and turned into an operations tool. That shift is common, and it is where most of the interesting engineering happens.
Two audiences, one schema
A customer wants to search cars, pick dates, and receive a confirmation. An administrator wants to know which vehicle is where, which chauffeur is assigned, and which reservation still needs a document. Both views read from the same tables.
Trying to serve those two audiences with separate models is tempting and almost always wrong: the moment they diverge, the data starts disagreeing with itself. One schema, two projections, is easier to keep honest.
Documents are derived data
Receipts are generated from reservation data rather than stored as free text. If a reservation is corrected, the document that describes it should follow automatically. Anything a human retypes is something that can drift.
Assignment is a relationship, not a field
The first version of the chauffeur assignment was a column on the reservation. It worked until a delivery needed two people, and until a chauffeur needed a history. Modelling the assignment as its own relationship — with a start, an end, and a status — solved both cases and several I had not thought of yet.
The lesson
Interfaces are easy to change. Data models are not. Time spent on the model before the first screen is the cheapest time in the whole project.