Car rental fleet app that replaced a spreadsheet

An off-road car rental business run by a single person. The cars come back from rough terrain, so they wear differently from a city fleet - and an off-roader has more to track than a regular car, because the whole four-wheel-drive system comes with it.

That was the first problem, before anyone even thought about software. Transmissions, axles, brakes, filters and fluids each carry two intervals at once: every so many kilometres or every so many months, whichever comes first. In a spreadsheet, that means someone has to manually check two numbers against reality for every single item.

The spreadsheet held up. It grew more tabs, got updated regularly, and technically contained everything. It just could not answer one question: which car can I hand over today.

Where we started

With the spreadsheet, not with screens. We went through it tab by tab, and for every column asked what it was for and when it was last actually useful. Some columns had been added for one situation and never removed - those fell out of scope before we built anything.

Two things came out of it that were not in the original brief:

• The owner does not need a fleet report. He needs one answer: what needs attention right now. Everything else can stay hidden.
• The worst-case scenario is not a missed service, it is handing over a car with something already overdue. For a car heading into the mountains for a week, that is not a paperwork issue.

The second observation shaped the whole app.

What we built

The fleet dashboard is the home screen. Every car has a card showing its readiness, mileage, and a count of critical items, warnings, and missing data. One glance is enough to know which car can go out today.

A single car’s card is a schedule grouped by system - four-wheel drive, brakes, cabin, cooling, wear parts. Every item carries its own interval and counts down both ways at once: how many days and how many kilometres are left until the next service. Entering a new mileage reading recalculates the whole list instantly, since mileage is the only thing that has to be entered by hand.

Next to the schedule, the car’s card also holds its registration details, insurance, and service history along with cost. Insurance has a due date exactly like a cabin filter, so it lives in the same place instead of a separate folder with a reminder in a calendar somewhere. The question “when was this last done” stopped requiring a search through email too.

Key decision: a car’s readiness is not a field you fill in, it is a result. Nobody marks a car as fit to drive - the app puts it in a blocked state itself the moment any item goes overdue. A warning can be clicked away and forgotten in a rush, especially with a customer standing at the desk. A calculated status takes that judgment call away from the person, and that is the entire difference between a spreadsheet and a system - a spreadsheet never calculates anything on its own.

Thresholds instead of fixed rules

Caution is a setting, not an assumption baked into the code. A warning fires a set amount of time ahead - separately in days and in kilometres - and a separate threshold decides how many items in a warning state a car can carry before it stops being marked ready and moves into service status.

That was a deliberate choice, so he would not have to come back to us every time his approach changed. A rental business in peak season and the same business in winter carry two different levels of risk, and both are set from the same screen.

Why a native Mac app, not a browser panel

This is a one-person business, and the owner has worked on a Mac for years. A web panel would have meant a server to maintain, a login account, and a dependency on an internet connection - three more things to worry about for a business that wanted fewer, not more.

The data stays local on his computer, and the whole database is a single file that gets copied to an external drive like any other document. Nothing leaves the machine, and there is no cloud database that would need protecting. With one user and a fleet this size, syncing across devices would solve a problem this business does not have.

How the rollout went

The first working version reached the client after a week - loaded with his real cars and dates copied from the spreadsheet, not test data. That was a deliberate choice: made-up records do not show whether the app answers the questions someone actually asks on a Wednesday morning.

The second week went entirely into fixes that came out of the first days of real use. After two weeks, the spreadsheet stopped getting opened.

What changed after launch

The most important change cannot be written as a number: the question “is everything actually up to date” disappeared. Before, answering it meant going through several tabs; now it is visible the moment the app opens.

To be honest about measurement: this is a one-person business that did not keep statistics before the rollout. So there is no “it used to take this long, now it takes that long” comparison here. The numbers below describe the state after launch, not savings calculated from the client’s own data.

We did not predict everything. The first version tracked the set of checks that could be read out of the spreadsheet - and in practice it turned out the owner was also keeping an eye on a few extra items he had never written down anywhere, because he simply kept them in his head. We added them after launch, and that was the biggest scope change in this project.

The lesson for next time is simple and costly: a client’s spreadsheet shows what someone wrote down, not what they actually keep track of. Next time, we ask about both.