(Draft for dev.to — edit anything that doesn't sound like you, then publish. Suggested tags: #ai #nextjs #supabase #buildinpublic)
Ten days ago I couldn't have told you what a webhook was. Last night I
published quidkit — a Next.js + Supabase + Stripe starter kit with
working auth, subscription billing, and documentation — and this
morning I'm writing this from holiday.
I study business management. I'm not a CS student. I can't really
"code" in the way that word usually means. What I can do, it turns
out, is manage a very fast, very literal developer that lives in my
terminal — and that changed what's buildable for someone like me.
This is the honest write-up: what I built, how the AI workflow
actually looked, every bug that nearly got me, and what it cost.
quidkit is a starter kit for developers building subscription apps.
The pitch: before anyone can pay you monthly for your app idea, you
need the boring foundation — accounts and login, taking payments,
knowing WHO paid, emails that send themselves, security so users
can't see each other's data. That's 2–4 weeks of tedious work that
isn't your idea. quidkit is that foundation, pre-built: clone it,
rename it, build your thing on top.
Stack: Next.js 16, React 19, Tailwind v4, Supabase (auth + database
with row-level security), Stripe (checkout, customer portal, webhook
sync), Resend (email). Live demo at demo.quidkit.dev — you can sign
up and "pay" with Stripe's test card and watch the whole pipeline
work.
£29. Because the established kits are £200–£300 and I'm literally
the target market: someone without that kind of money.
People imagine "AI builds your app" as one magic prompt. It's not.
It's closer to being a project manager with one extremely capable,
extremely literal employee:
I wrote specs, not code. Every session started with me pasting
a detailed brief into Claude Code — what to build, what NOT to
build, constraints like "never downgrade versions to fix an
issue." The quality of what came back tracked the quality of the
brief almost perfectly.
Claude Code wrote essentially all of the code. Auth flows,
Stripe webhook handlers, database migrations, the UI. I have
read very little of it. What I did instead was test everything
like a user: sign up, pay, cancel, break it.
I did the dashboards. AI can't click around Stripe, Supabase,
Vercel, and DNS settings for you (mostly). Honestly? The account
setup and configuration was where most of my time — and ALL of my
suffering — went. Keep that in mind whenever someone says the code
is the hard part.
A second AI kept me honest. I ran the plan, the pricing, the
marketing decisions, and every "should I do X" through Claude in a
long-running chat that had context on the whole project. It talked
me out of paid ads, out of fake crossed-out pricing, and out of
several 1am decisions that would have been bad.
Every one of these shipped-in-silence bugs got caught only because I
tested the deployed product like a stranger. If you're building with
AI, this list is the value of this article:
1. Every auth email pointed to localhost in production. The code
built URLs from the request's Origin header — which isn't guaranteed
on server actions. Locally: fine. Deployed: every confirmation link,
magic link, and password reset silently pointed at localhost. Fix:
one env var (NEXT_PUBLIC_SITE_URL) as the single source of truth.
2. The .env.example file wasn't in the repo. It was gitignored by
the .env* rule and had never been committed. Anyone cloning the kit
would have had no idea what variables to set. The scariest bugs
don't error — they just aren't there.
3. The production webhook endpoint didn't exist. Stripe webhooks
worked perfectly on my machine through the CLI listener. Deployed?
My test payment went into the void — paid in Stripe, free plan in
the app — because the CLI listener isn't a production endpoint. You
have to create one in the dashboard, with its own signing secret.
4. Emails landed in spam, then stopped sending entirely.
Supabase's built-in email sender rate-limits at 2–4 emails per hour,
which my testing burned through instantly. Fix: custom SMTP through
Resend, then domain verification so mail comes from your own domain.
5. Re-signups fail silently on purpose. If a user already exists,
Supabase returns a clean 200 and sends nothing (so attackers can't
probe emails). Great for security, maddening at midnight when you
don't know it.
None of these are exotic. All of them are invisible until a real
deployment meets a real stranger. AI wrote code that worked; the gap
was everything around the code.
Zero. I published last night and went on holiday, which I'm told is
not the recommended launch strategy. The realistic plan was never
"launch and get rich" — it's six weeks of showing up: posts like this
one, Reddit, my university's dev society and using the kit to
deliver freelance work faster. I'll write a follow-up with real
numbers either way — including if the number stays zero.
quidkit is at quidkit.dev if it's useful to you — £24 with code
LAUNCH24 this week. But honestly, the bigger takeaway is the
workflow: if a business student can ship this in ten days, the thing
you've been putting off is probably buildable.
Questions welcome — I'll answer everything in the comments (timezone
permitting; there's a pool involved).