A demonstration
I asked an LLM to build a base-price dynamic pricing model — the kind that sits inside most short-term rental pricing tools. Here is the prompt, and here is the working model that came back. You can change the inputs.
This is the whole specification. Not an excerpt — the entire description of the model that prices calendars for a large share of this industry.
Ninety words. There is no step four.
The model below is running live. Move the base price and every one of the 365 nightly prices recalculates, because each one is a single multiplication away from it.
Note what the blue line does when you change the orange one: nothing. The market curve is not aware of you. It is an average of what other listings are charging, and your calendar is that same shape, scaled to your number.
| Month | Market avg | Avg factor | Your avg | Your peak night |
|---|
Pricing tools present a night as a stack of named effects — seasonality, day of week, local demand, an event. It reads like a receipt: four things measured, then added up.
That is not what happened. The price was one multiplication. The breakdown is reverse-engineered out of it afterwards: take the month's average factor, then the weekday's average within that month, and whatever gap remains gets a name.
"Local demand / event" is not a measurement. It is the remainder — the price minus everything already accounted for — and only then is it given a name.
The lines always sum exactly to the price. They cannot do otherwise: the last one is defined as the gap. Two tools could show different breakdowns of the identical price and both would be internally consistent.
This is not dishonest, and it earns its place in a product. A bare $568 invites the question "why?", and "it's the Fourth of July weekend, and it's a Saturday" is a real answer in language a host already uses. Just read it as an explanation of a market-derived price rather than as the model's arithmetic.
There is no data collection in this model, and that absence is the most useful thing on the page.
Every number above rests on one input: prices and availability for comparable listings, for every night, refreshed constantly. Real rows look like this —
— and getting them is the entire job. Seed lists of listings. Finding the endpoints behind the pages. Proxies, rate limits, backoff, retries. Endpoints that change shape on a Tuesday and take your prices down with them. Then again tomorrow, and every day after that, forever.
The arithmetic is a mean and a division. It has been stable for a decade and any competent analyst can reproduce it in a spreadsheet in an afternoon. The pipeline underneath is a permanent engineering commitment.
So this page is not an argument for building your own. It is an argument for knowing precisely what you are paying a vendor for — because if what you are buying is a maintained data pipeline, the fair next question is what the model sitting on top of it does with the data.
A language model can write any model you can describe. It still cannot get the one input that would make this model better.
Everything above flows from a single source: what other listings are charging. The model tracks the market's shape faithfully, and it has no concept of demand for your property. No booking pace. No occupancy feedback. No measure of how demand responds when you move a price. If the whole market underprices a high-demand weekend, this model underprices it in perfect lockstep — and reports that it is performing correctly, because matching the market is the only thing it knows how to do.
Which means the model cannot be anyone's edge. It is everyone's model, drawn from data everyone can reach. An edge has to come from something a competitor cannot collect, and there is exactly one candidate: how your listings actually book. Your conversion at each price. Your pace. Your response curve. Observable only by you, and invisible to a model that looks sideways at the market instead of down at your own results.
Feed those observations into the model rather than around it and the question it answers changes. Not "where is the market on this night," but "how likely is this night to book at each price I could ask, and which of those prices is worth the most?" A booking probability attached to every candidate price, an expected value computed from it, and the price chosen off that curve. Some nights that lands above the market. Some nights, well below it — because filling the night is worth more than holding out for a number the market will not pay.
That is not a better base price model. It is a different question, and answering it requires data no scraper can reach.
It is the model we build. It is also, not coincidentally, why we can afford to publish the one above.
Code is the commodity. Data access is the moat.