Full-Stack Next.js Developer — SMS Marketing SaaS (Twilio + Stripe) — Spec & Designs Ready

ABOUT THE PROJECT I'm building a small SaaS product for supermarkets and grocery stores. Each store gets an NFC card and QR code at the checkout. A customer taps it and lands on a simple page with two options: see this week's specials flyer, or leave a Google review. On the specials page they can enter their phone number to get a text each week when a new flyer is posted. The store owner uploads their flyer image to a dashboard, confirms, and it goes out by SMS to their subscriber list. I run an admin console above all of it. This is a real product with paying customers planned, not an experiment. WHAT I ALREADY HAVE - A 14-page technical build brief: architecture, data model, page inventory, security requirements, and phased delivery plan - A complete 22-page front-end prototype (HTML/CSS/JS) you can click through, showing every screen in the system - A sales deck, brand colors, and all copy written You will not be guessing what to build. I'll send the brief and prototype to serious candidates before we talk. TECH STACK (not negotiable) - Next.js (App Router) + TypeScript in strict mode - PostgreSQL + Prisma - Tailwind CSS - Vercel for hosting - Twilio for SMS - Stripe Checkout + Customer Portal + webhooks - Cloudflare R2 or AWS S3 for image storage - Clerk or Auth.js for authentication If you'd push back on any of these for a good reason, tell me why in your reply — I'll listen. If you simply don't know one of them, this isn't the right project. SCOPE Three surfaces: 1. Public pages (no login) — store landing, specials, subscribe, confirmation, unsubscribe, privacy, terms 2. Store dashboard (owner login) — overview, upload flyer, past flyers, subscriber list with CSV export, billing, settings 3. Admin console (me only) — all stores, store detail, card inventory and assignment, billing overview, activity log Key requirements: - Strict tenant isolation. One store can never read or write another store's data. I want this enforced at the database layer, not just in application code. - Full SMS compliance: explicit unchecked opt-in, STOP/HELP handling, 8am–9pm local sending window, opt-out is a status change and never a delete. - A confirmation step before any broadcast, showing the flyer, the exact message text, and the recipient count. Sending must be idempotent — a double-click or a retry must never send twice. - Every card carries a permanent short code (taplist.app/c/A7K2) that I can reassign to a different store from the admin panel without reprinting anything. MILESTONES I pay per milestone, released when each is working on a live staging URL: 1. Foundation — auth, tenants, store CRUD, database schema, deployment pipeline 2. Public pages + subscribe flow + full SMS compliance handling 3. Flyer upload, confirmation step, and broadcast sending with delivery tracking 4. Stripe billing, admin console, card assignment, and handover Propose your own timeline for each. I'd rather have an honest six weeks than an optimistic three. WHAT I NEED FROM YOU - Communication in clear English, a few times a week minimum - Code in a GitHub repository I own, from day one - All third-party accounts (Twilio, Stripe, Vercel, database, domain) created and owned by me — you get invited as a collaborator - Short written handover at the end: how to deploy, how to run it, what to watch TO APPLY Please start your reply with the word "FLYER" so I know you read this properly. Then answer these four questions. Short, direct answers — I'm not looking for a sales pitch: 1. Link me to a live product you built with Stripe recurring subscriptions. What did you personally build in it? 2. Have you worked with Twilio A2P 10DLC registration? If yes, describe what the process involved. If no, say so plainly — it's not an automatic disqualifier. 3. In two or three sentences: how would you guarantee that Store A can never see Store B's subscriber list, even if there's a bug in my application code? 4. What's the first thing you'd want to change about the stack or plan above, and why? Applications that don't answer these won't get a reply.