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 computed for an apparel brand from its public storefront alone, with no access to any internal system: 5,235 products and roughly 48,000 size variants, read and analysed in minutes.
754 styles have the largest size unavailable while the three smallest are all in stock. The mirror image, small sizes gone and the largest still sitting there, happens in 204. Size by size the stockout rate runs 22% at X-Small and 24% at XX-Large, so the curve is broadly sound. The lean is in the tail, and four to one is not chance.
Now notice what that finding is not. It cannot tell you what the gap cost, whether it repeats by product line, or which channel ran short, because none of that is visible from outside. Answering it needs your data. That is the entire reason the diagnostic exists.
A note on how this was produced, because it matters more than the number. The first pass reported a far more dramatic result. It was wrong: the catalogue paginates, the source returned an empty page instead of an error partway through, and the analysis silently ran on a seventh of the data. Checking the total against the source is what caught it. Any system that reads someone else's data will meet that failure, and a pipeline that cannot tell "no more data" from "no answer right now" will hand you a confident wrong number. Mine are built to fail loudly instead.
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.