I build the system that makes those decisions with numbers instead of instinct, and I have one running in production right now across a fleet of 750 vehicles.
A rental fleet is a finite amount of inventory. Demand moves by date and by location. Every unit can go to one channel or another at a different margin. And someone has to set a price for each one, every single day.
An apparel brand has a finite production run. Demand moves with a calendar and with things outside your control. Every unit can ship to a wholesale account at one margin or sell on your own site at another.
Those are the same problem. Finite inventory, demand that moves on a schedule you can see coming, and an allocation decision with real money on both sides. Most companies answer it in a spreadsheet, once, and then live with the answer for a season.
Competitor rates, market signals, the calendar, whatever public data actually predicts your demand. Automated, every day, without anyone opening a browser.
Plain functions you can read and audit. No model guessing at arithmetic. If a number looks wrong you can trace exactly where it came from.
Per vehicle, per SKU, per location. Not a dashboard that leaves the thinking to you. An actual proposed number, with the reason attached.
Always. Nothing reaches a customer because software decided it should. The human gate is part of the design, not a safety net bolted on afterwards.
Two lessons from shipping this for real: never let a language model do the arithmetic, and never let it write to production without a person in between.
750 vehicles across 10 locations in Spain, including airport and city branches. Daily pipelines ingest competitor and market data, deterministic functions compute the demand and revenue signals, and a reasoning layer recommends a rate per vehicle. A person approves before rollout. It has been running all year.
The time is the smaller half of that. The weekly pricing round used to take two days of someone's week, so it was done the only way two days allows: in broad strokes, whole categories at a time, with the detail skipped because there was no room for it. Now it takes about two hours and it reaches every vehicle individually. The hours saved are nice. The decisions that nobody had time to make before are the actual win.
I am the only engineer on that platform: the pipelines, the AWS infrastructure underneath them, and the integration layer that keeps bookings, stock and pricing in sync with a legacy ERP that was never designed to share anything.
Here is one I computed for an apparel brand from its public storefront alone, in under an hour, without access to a single internal system.
| Size | Out of stock |
|---|---|
| X-Small | 13% |
| Small | 19% |
| Medium | 17% |
| Large | 20% |
| X-Large | 38% |
| XX-Large | 51% |
The reverse case, small sizes gone and the largest still sitting there, happened in 2 styles out of 750. That asymmetry is not noise. It is a size curve that does not match demand on roughly 40% of the line.
Notice what that finding is not. It does not tell you what the gap cost, whether it repeats by product line, or which channel ran short. Answering that needs your data.
That is the whole point. The interesting questions are always one layer below what is visible from outside, and one layer below is where the money is.
A fixed piece of work with a fixed price, so you can find out whether this is worth anything to you without hiring anybody.
The document answers three questions with numbers rather than impressions: where you are over and under producing, what discounting is actually costing you, and which units went to the wrong channel. Then it answers the one that matters most, which is what it would take to have those answers every week instead of once.
If what I find is not worth what you paid, you will tell me, and you will be right.
Some diagnostics end in a build, where I turn the finding into the system that answers it on a schedule. Some end in a retainer: a named day every week, a fixed monthly fee, and something concrete delivered every week so you never wonder what you are paying for. Most end right there with the document, which is a perfectly good outcome.
I do not sell hours. You are buying a decision that is better than the one you would have made, and how long it takes me to get there is my problem.
Carlos Blank. Six years building software, the last two owning an entire platform alone: product, data, AWS infrastructure, and the integrations between systems that were never meant to talk to each other. Before that, four years across e-commerce and Shopify, which is why the retail version of this problem is familiar rather than theoretical.
I am based in Spain and I work US Eastern hours deliberately, 10am to 3pm ET every weekday.