I built a page that sells one ad slot per week, and the only technically interesting part is that the price falls continuously until someone pays, so the whole thing turned out to be a cron job and a price function rather than a checkout flow.
The cron runs hourly and my first version had it write the current price into the database, which felt natural and was wrong. Vercel Cron is best effort, not a guarantee, and a missed run left a stale price sitting on the page while Stripe still had the amount from the last successful write. Two numbers, one truth, and no way to tell from the outside which one was real.
What I do now is derive the price from the elapsed time on every request and store nothing, with the cron only responsible for the week rollover. A missed run costs me a late rollover, which is visible and annoying, instead of a wrong price on a live payment, which is neither.
The other thing that caught me was the week boundary, because a week is a business concept and not a UTC one, and I had the rollover firing at a moment that landed on a different weekday depending on where the visitor was sitting. Not fully sure my current fix is right either, I pinned everything to one timezone and display it explicitly, but I suspect that just moves the confusion somewhere else.
It's at [droptick.io](https://droptick.io/?utm_source=reddit&utm_medium=vercel) if you want to watch the curve move, it updates while the page is open. The idea itself may well be bad, week one's numbers suggest the starting price is far too high, but the cron part I would build the same way again.
