Pricey Pro: Dynamic Pricing That Can Explain Itself
Amish Country Lodging is 75 listings — cabins, lodges, A-frames, treehouses. Every one of them needs a price for every night of the next year, and the right answer moves constantly: July 4th week is not a random Tuesday in March, a Saturday is not a Wednesday, and a lone open night wedged between two bookings is worth less than a night that starts a wide-open week.
Pricing that portfolio by hand is a full-time job. Automating it is easy to get wrong in a specific way: you end up with software that spits out a number and can't tell you why. When a guest books a cabin at $219 and the owner asks "why $219?", "the algorithm said so" is not an answer I was willing to give.
So the one non-negotiable requirement for Pricey Pro was this: every price must be able to explain itself.
An engine you can read
The pricing engine is a pipeline, and every stage writes its work down. A night starts at the listing's base price. Seasonality adjusts it — recurring date ranges like "fall foliage weeks" carry their own factors. Day-of-week demand moves it again. Then customization rules apply: percentage adjustments, fixed prices, discounts for gap nights that would otherwise sit orphaned between bookings, premiums for far-out dates, tiers based on how full the calendar already is. Finally, safety rails clamp the result — a floor at 30% of base and a ceiling at 10x, so no rule combination can ever publish something absurd.
Every one of those steps is persisted per night, per listing. In the calendar you hover a date and see the whole chain: what the base was, which season touched it, which rules fired, what got clamped. Pricing disagreements stopped being arguments and started being lookups.
Rules that scale to 75 listings
Nobody wants to configure 75 listings one at a time. Rules live at three scopes — account, group, listing — and the more specific scope wins. Set a weekend premium once at the account level, override it for the treehouse group, pin one specific cabin's holiday week to a fixed price. Minimum stays work the same way, as profiles rather than single numbers: two nights in winter, three in summer, a week around holidays.
Publishing prices without fear
Computing prices is half the product. Publishing them to the property-management system — where they become real prices real guests pay — is the half that kept me careful. Every listing has a push mode: off, dry-run, or live. Dry-run computes the full payload, logs exactly what it would change, and never writes. New listings run a shadow week in dry-run before anyone flips them live. And the write path only works when a global environment kill-switch is also enabled — two independent keys, so no single mistake can publish prices by accident.
A scheduled watchdog runs the whole loop daily: import new reservations, recompute every calendar, publish for the listings that are live. Prices stay current whether or not anyone logs in.
A deliberately boring stack
Pricey Pro is vanilla JavaScript and Express with exactly one npm dependency — the Supabase client. No frontend framework: the dashboard, calendars, and rule editor are hand-written JS talking to a JSON API. Postgres on Supabase holds listings, rules, calendars, and explanations; Vercel runs the app and the cron. The engine itself is covered by 177 offline unit tests plus golden-fixture regression files, so I can refactor the pipeline and know instantly if any night's price moved when it shouldn't have.
Reservation data comes from a Supabase mirror of the property-management system that syncs hourly — reads are instant and never touch a rate limit. The integration layer that reads from external systems is a strict allowlist; the one module that can write calendars is a separate, auditable file. I built most of it by directing AI coding agents against a tight spec, with the test suite as the referee.
What I learned
Dynamic pricing isn't magic; it's a few dozen legible decisions applied consistently to thousands of nights. The value wasn't in inventing a clever algorithm — it was in making every decision inspectable, giving the rules a hierarchy that matches how a real portfolio is organized, and treating the publish step with the respect anything that touches revenue deserves.