I shipped my first AWS + Vercel product in 7 days during a Meta attribution crisis 👋

Developer Andres built Ad Engine, a 24/7 AI ad-ops monitoring tool for DTC telehealth brands, in seven days for the H0 hackathon. The project was motivated by Meta's February 14 enforcement of health-data restrictions that broke pixel-based conversion tracking, causing a single ad set to burn $4,200 without alert. Andres chose Amazon Aurora PostgreSQL Serverless v2 over DynamoDB for its support of multi-entity joins and time-series windowing.

Hi dev.to 👋 I'm Andres. Long-time builder, first-time dev.to poster. Pretty sure I should have done this years ago. Just shipped Ad Engine — a 24/7 AI ad-ops monitoring tool for DTC telehealth brands — in 7 focused days for the H0 hackathon. The build had teeth because there was a real reason for it: on February 14 this year, Meta enforced new health-data restrictions that killed pixel-based conversion tracking for the entire DTC telehealth space. At 11 PM the day it happened, I watched a single ad set at Bliss Health burn $4,200 with no alert. The tool I wanted didn't exist, so I built it. Amazon Aurora PostgreSQL Serverless v2 us-east-2, 0.5–1.0 ACU Next.js 16 — App Router, Server Components, Server Actions Vercel Fluid Compute + Cron — 15-min polling cadence on Meta + Google APIs Claude Sonnet 4.6 with schema-enforced structured output via Zod + AI SDK Output.object Drizzle ORM with postgres-js driver The juiciest engineering decision was rejecting DynamoDB for Aurora Serverless v2. The workload turned out to be multi-entity joins + time-series windowing for 7-day baselines, and DynamoDB's GSI-design tax made that worse than a relational engine's OVER ROWS BETWEEN 336 PRECEDING window function. Wrote the full decision matrix + schema + SQL + the postgres-js Fluid Compute connection-pool pattern prepare: false, max: 1 here: → Read the full decision matrix here https://dev.to/member 8be1f66f/why-i-replaced-dynamodb-with-aurora-postgresql-serverless-v2-for-an-ad-ops-monitoring-workload-b47 Three questions for the community — and I'd genuinely love feedback: For 24/7 polling workloads with bursty Claude diagnosis calls — would you reach for Vercel Fluid Compute or stand up a separate worker? Curious about the threshold where the answer flips. Anyone hit the postgres-js prepare: false + max: 1 Fluid Compute pattern? Worked great for my scale 1 cluster, ~96 polls/day . Curious if anyone has stress-tested it past that. What would you have built differently in a 7-day sprint targeting this kind of operational-monitoring shape? Open to the roast. Live: https://runadengine.com https://runadengine.com 2-min walkthrough: https://youtu.be/poFYDHB9WyU https://youtu.be/poFYDHB9WyU Happy to be here. 🚀