Case published with the client kept anonymous.
How a weekly car rental operator went from a master spreadsheet that kept degrading itself to a system that knows which car makes money, who owes what, and what the shop needs — with a separate app for the mechanic.
The Context
The master file that told him how much he was owed had #REF! errors in its cells. That is not an anecdote: it is a revenue-generating asset business run on document tools. A tab per car, a separate cost book per vehicle, and the state toll agency file off on its own. Every new car added administrative work instead of diluting it.
The root cause: a rentable-asset business managed with document tools, not data tools. Every new car multiplied the administrative work instead of diluting it.
The master file was degrading on its own
#REF! formulas, invalid dates. The information holding the business together was deteriorating with every edit.
No fleet-wide view
Impossible to see at a glance which car is rented, which is in the shop, and which is free.
Profitability was impossible in practice
Calculating it per vehicle required manual work — so in practice, it never happened.
The mechanic's access dilemma
He needed to know which cars to service, but there was no way to give him that without also opening up the business numbers.
The Solution
Migration and reconciliation of every existing file into a relational structure with the vehicle as the central node, followed by two separate applications on top of the same database.
Phase 1 — Weeks 1–3
The database and the money
Migration and reconciliation of all existing files into a 12-table relational structure with the vehicle as the central node. Automatic calculation of what each renter owes: expected rent, billable tolls, extra charges and credits. Per-vehicle profitability — operating cost, operating and lifetime results, ROI against what the car cost.
Phase 2 — Weeks 4–5
The two applications
Fleet Command for the owner: a dashboard showing who owes what, which car needs service, and which part is missing; weekly billing in under 15 seconds per renter; a 360° view of every vehicle. Mechanic Workstation: which cars are in the shop, what they need, and a log of work done and parts used — with zero access to a single financial number. Toll import: the state agency file is uploaded and the system processes it on its own — deduplicating, matching each toll to the right car, and attributing it to whoever had that car that day. 1,380+ records reconciled.
Shop & Maintenance
This is the part that makes per-vehicle profitability real instead of a promise. When the mechanic logs a job from his phone:
Logs the odometer reading at the time of service
Adds the parts pulled from the shelf — just part and quantity, never prices
Stock goes down on its own
Those parts' cost flows into the service, added to labor or an outside invoice
The service cost flows into that car's profitability
And when a part hits its reorder point, it shows up on its own on the owner's shopping list. The mechanic does one thing — log the work — and the system handles inventory, costing, and the restock alert. No one updates a stock sheet by hand.
🛣️ The odometer keeps itself current
Each car's mileage comes from the highest reading the system has ever seen, wherever it came from: a handoff, a return, the weekly reading logged at billing, or a service record. No one updates it by hand.
🗓️ Maintenance schedules
Two separate calendars coexist: oil changes run on mileage, inspections run on date. The system calculates how many miles remain and marks each car as current, due soon, or overdue. A car can be current on one and overdue on the other.
📋 Each car's punch list
Every vehicle has its own list of things to fix, ranked by priority. The mechanic adds what he notices — a noise, a leak, a light — from his phone, and the owner sees it without a single phone call. Once resolved, it gets checked off and disappears from the list.
📁 Every car's documents, one click away
Each vehicle has its own Google Drive folder, opened with one button from its record: title, registration, insurance, photos, shop paperwork. The system also tracks whether the title is in hand, the registration renewal month, and whether the car has its emergency kit.
Key Design Decisions
🔧 A dedicated app for the mechanic, not permissions
Restricting access table-by-table requires an expensive enterprise plan. A dedicated interface on the same database achieves the same isolation for a fraction of the cost. The mechanic sees what he needs; the money simply does not exist on his screen.
🏷️ The stable key
Matching tolls by the transponder tag ID, not the license plate. Plates rotate between cars. The tag is the stable key — without that decision, the system bills the toll to the wrong renter, and the error stays invisible until someone disputes it.
💰 Calculated prepaid billing, not captured
The system knows how much each renter should have paid as of today. No more creating a weekly row per client — only what actually comes in gets recorded.
🧾 Every charge is a dated entry, not an overwritten cell
Damage, a fine, a credit for a day lost in the shop: each one is its own line with a date and a note. The balance still explains itself three months later.
📦 Inventory is calculated, not typed in
Stock = starting count + purchases − consumption ± adjustments. No one edits the number by hand, and every adjustment carries its own note. It's the same rule as the charges, applied to the shelf: log movements instead of overwriting totals.
🚦 Statuses are inferred, not typed in
No one marks a car as rented. The system infers it: an open rental means the car shows as rented; if the mechanic flags it as in the shop, it switches on its own. And opening a new rental only offers available cars, so the same car can never be double-booked.
The system was designed around one underlying rule: numbers are never overwritten, they're built from dated movements. That holds equally for the money a renter owes and for the parts left on the shelf.
"Before, I had to calculate whether a car was making me money.
Now the system calculates it for me —
and I see it before deciding whether to keep it or sell it."
Operating system delivered by Metacube Studio · Q3 2026
Tech Stack
The system went into production in Q3 2026, migrating 25 active vehicles and reconciling the full toll history from day one. Designed to scale to 50–100 cars without adding administrative work.
If you manage vehicles, equipment, or rental properties and don't know which one is actually making you money, we can build the system that tells you.
Book a Clarity Session30 minutes. We look at how your business runs today and you leave with a concrete proposal: what to build, in what order, and what it costs.