How PromptQuick.ai Is Built With an AI Coding Agent

PromptQuick.ai looks like a simple site: a few pages, a sign-up form and a buy button. The code behind it is private, so you can't see how it works. This post shows what happens when you sign up for the free sample, when you buy the Rulebook, and when a change goes live. And who does what, since an AI coding agent now writes the code.

I built the first version in April 2025 with help from AI chat tools, and the full Rulebook went on sale that May. In September 2026 I rebuilt most of it, this time with Claude Code, Anthropic's coding agent, working in the project folder on my computer. Since 25 September, every change to the code names it as co-author.

What it runs on

The site is Next.js 16 with React 19 and TypeScript, styled with Tailwind CSS 4 and hosted on Vercel. The database is Postgres 17 on Supabase. A few services do the specialised work: Lemon Squeezy runs the checkout, Resend sends the email, Google reCAPTCHA checks the sign-up form for bots, Upstash limits how often one visitor can call the form and the counters, and Cloudflare hosts the PDFs.

When you sign up for the free sample

When you send the form, the server first checks the reCAPTCHA and your address. Then one database function does two things: it stores your address and adds a “send the welcome email” job to a queue. Both happen in one transaction, so a sign-up can't exist without its email.

You get the same answer whether your address is new or signed up before, so the form never tells anyone who's on the list. A repeat sign-up gets no second email.

Right after answering you, the site tries to send the email, so it usually arrives within seconds. That's only a shortcut. Every minute, the database's own scheduler calls a worker that sends whatever is still waiting. When a send fails, the worker tries again after 1 minute, then 2, then 4, up to 2 hours apart, 8 attempts in all.

It's the database's scheduler, not the host's, because it runs every minute on any Supabase or Vercel plan. Vercel's own scheduled jobs run once a day on its free plan.

Retrying email has a catch: you don't want two copies. So the first attempt saves the exact message, and every attempt sends that same message with the same idempotency key, a label that tells Resend “this is the email you may have seen already”. Resend sends it once. Resend remembers that label for a day, so if the worker still can't tell by then whether an email went out, it stops and leaves the decision to me instead of guessing. When an email fails for good, I get an alert.

This fixed a real gap. In the 2025 version the site made one attempt, after answering the form. If that failed, nothing tried again, and because a repeat sign-up gets no second email, that person never got the sample.

The saved message contains your address, so a daily job clears it 30 days later.

When you buy the Rulebook

Lemon Squeezy does the selling: the checkout, the payment, and the receipt email with the download link. The site never sees your card and never calculates a price.

After a purchase, Lemon Squeezy sends the site a notice, called a webhook. The site checks its signature first, a code only Lemon Squeezy and the site can compute from that exact message, and refuses anything that doesn't match. But a valid signature only proves who sent it. So the site also checks that the order is paid, not refunded, and for the Rulebook in this store. Only then does it record the buyer. If the same notice arrives twice, the second one changes nothing.

There's also a test copy of the site, which I'll get to below. Purchases there use Lemon Squeezy's test mode, and the site accepts a test order only when it's connected to a separate test database. A test purchase can't end up among the real buyers.

How a change goes live

Everything starts on my computer. The agent works against a local copy of the database and fake stand-ins for email, payments and the bot check. A guard refuses to run anything against a hosted database or a real provider, and the computer holds no keys to the live systems at all.

Changes reach the main branch through pull requests. Each one goes through five automatic checks: formatting, code style, types, unit tests and a full build; the database's own tests; browser tests that click through the site and run an accessibility check on every page; an audit of the packages the site depends on; and a scan of the whole history for leaked secrets. I merge once they pass.

When a change passes and lands on the main branch, staging updates by itself. That's the test copy: the same site with its own database. The live site at promptquick.ai only changes when I start a release by hand, and only from a change that passed the checks. In both, the database is updated first and the new code goes out after. If the database step fails, the code stays where it was.

Only promptquick.ai itself can show up in search engines. Staging and every other copy tell them to stay away.

One switch puts the site in maintenance mode. It pauses everything that needs the database, like the sign-up form and the counters, while the pages and the checkout stay up. I used it on 27 September to upgrade the live database from Postgres 15 to 17, after testing the switch on staging first.

I chose a partial switch over one maintenance page for the whole site. The checkout runs on Lemon Squeezy, so people can still buy. Only recording the buyer waits: I resend the purchase notices from that window from Lemon Squeezy's log afterwards.

Who does what

Claude Code writes the code, but it works inside rules I set, written in files it reads at the start of every session:

• A plan says where the project stands and what's next. Every session reads it first, takes one piece of work, and updates it before stopping.
• Tests follow the requirements, and it may never weaken a test to get a pass.
• Before it uses a library or a service, it looks up the current documentation instead of trusting what it remembers.
• It can't push code, deploy, or touch anything live. Those commands are blocked in its settings, and there are no keys on the machine to use anyway.

That way of working comes from the AI App Starter, which I wrote about in its own post.

My part is the rest. I decide what gets built and how it should look and behave, and those decisions go into a file the agent follows. I review the work, push it, and start every release. Everything on the live systems is mine too: setting up hosting and the scheduler, upgrading the live database, uploading the PDFs and sending the update emails.

Work on payments, on deleting data or on the live database gets a second look. A separate agent session reviews it without changing anything, and I decide what to do with what it finds.

Most of this never shows. You fill in a form and get an email, or you pay and get a PDF. What took the time is making sure that still happens when a step along the way fails.