Inspiration
I've watched small creators lose customers and damage their brand over something entirely preventable: overselling. A drop goes viral, a thousand people pile in at once, and the store sells the same unit three times. Then come the cancellations, the angry DMs, the refunds. The creator did everything right, built the hype, showed up, and the infrastructure let them down.
That felt like a solvable problem. And when I saw the Vercel and Aurora DSQL integration, I knew it was.
What it does
Cadence is a platform that lets creators run live, limited drops that never oversell and never show a stale price, even when thousands of buyers hit at once. An AI merchandiser runs the drop in real time, adjusting inventory releases, nudging price within guardrails the creator sets, managing the waitlist, and keeping the creator informed the whole way.
On the buyer side, the public drop page shows live stock, live price, and a checkout that either confirms the purchase or cleanly rejects it if the unit is already gone, no double-selling, no overselling, no exceptions.
On the creator side, a dashboard gives full visibility into what the agent is doing and why. Every price adjustment and inventory release shows up in an actions feed with the before and after state side by side, a plain-language line of the agent's reasoning, and a timestamp, so a creator can see exactly why the price moved from $80 to $85 or why 50 more units were released. Creators can also trigger an agent run manually if they want to see a decision happen on demand, which makes the system easy to demo and easy to trust, since nothing the agent does is a black box.
The stack is Next.js on Vercel, Aurora DSQL as the database, Claude as the AI behind the merchandiser, Replicate with Flux Schnell for AI-generated product imagery, and Stripe in test mode for the real checkout code path.
How I built it
I started in v0, scaffolding the two main surfaces: the public drop page and the creator console. From there I wired up Aurora DSQL through the Vercel AWS marketplace integration, which handled credentials and environment variables automatically.
The heart of the app is a single serializable transaction. Aurora DSQL uses optimistic concurrency control, so when two buyers race for the last unit, one commits and the other gets a conflict, retries, sees no stock, and is cleanly rejected. No oversell, by construction. I built the AI agent loop as a server action that reads live drop state, calls Claude with a defined tool schema, validates every action against hard guardrails in code, and writes approved changes back to DSQL as serializable transactions.
The creator dashboard reads from two endpoints, one for live metrics and one for the agent's action history, both polling every few seconds so the numbers and the feed stay current without the creator having to refresh.
Product imagery is generated automatically via Replicate's Flux Schnell model from the product name and description, so a creator can go from a text brief to a live, visually complete drop in seconds. Stripe handles checkout in test mode, the same production code path with test money. And I built a load test harness that fires 2,000 concurrent purchase attempts against 200 units and reports the exact outcome.
Challenges I ran into
The trickiest part was making the agent's live mutations safe alongside concurrent buyer purchases. Any time the agent changes a price or releases inventory, it touches the same rows buyers are racing for. Getting that right meant thinking carefully about transaction boundaries and price versioning so a buyer could never pay a stale price without being caught.
The second challenge was less interesting in theory but just as real in practice: shipping fast on a brand-new framework version against a brand-new database meant chasing bugs that looked like logic errors but weren't. Next.js 16 changed route params to a Promise, and one endpoint picked up the new pattern while a sibling endpoint didn't, which produced a "drop not found" error that had nothing to do with drops actually existing. I also hit a schema mismatch where my code assumed columns that were never created in Aurora DSQL, so the fix wasn't in the logic, it was in matching the code to what the table actually looked like. None of this showed up as a clean stack trace. It showed up as a feature that looked broken until I traced it back through the deployment, the route, and finally the schema itself.
The load test was humbling at first. 2,000 concurrent buyers against 200 units is a real stress test, and watching the sold counter land on exactly 200 every time was genuinely satisfying once everything was wired correctly.
Accomplishments that I'm proud of
The thing I'm proudest of is the load test result itself. Firing 2,000 concurrent purchase attempts at 200 units and watching the sold counter land on exactly 200, every single run, is the kind of result that's easy to claim and hard to actually deliver. No overselling by construction, not by careful UI logic or a lucky race condition that never got hit during testing.
I'm also proud of how far the agent transparency piece came together. An AI making live pricing and inventory decisions during a real sale is a hard thing to trust on faith, so building the actions feed, where every move the agent makes shows up with its before and after state and a plain-language reason, turned the agent from a black box into something a creator can actually watch and verify in real time. That mattered more to me than I expected going in.
And the whole thing holds together end to end. A creator can write a product brief, get AI-generated imagery, launch a live drop, watch an autonomous agent manage price and inventory, and have a buyer complete a real Stripe checkout, all in one working system, built and wired up in the time I had.
What I learned
The most interesting thing I learned is how the right database choice simplifies the whole problem. The conventional approach to surviving a flash sale is a stack of layers: a virtual waiting room, a Redis atomic counter, a queue, reconciliation logic. Aurora DSQL lets you collapse all of that into one consistent database, because correctness is built in rather than bolted on.
I also learned that an autonomous agent doing anything consequential needs its guardrails enforced in code, not trusted to the model. The agent proposes, the server validates.
What's next for Cadence
The next piece I want to build is deeper agent observability for creators. The actions feed already shows what the agent did and why, but the natural next step is letting creators tune the agent's guardrails directly from that same dashboard instead of editing code, and giving them a full audit trail they can export or look back on after a drop ends. The more visible and steerable the agent is, the more a creator can hand it real responsibility during a launch instead of just watching nervously from the sidelines.
Log in or sign up for Devpost to join the conversation.