This is the next step after the basic guide.That one builds a one-page site that only shows things. This one builds a page that saves what visitors write into a database, a guestbook. By the end you will understand the three things that make a page come alive: the backend API, the cloud database, and environment variables. Again you talk to Claude in plain language the whole way, pasting 11 prompts.
Time needed: 3 - 5 hoursBase cost: Claude Pro USD 20 / month (Supabase and Vercel are free)You need: A desktop computer (Mac / Win)Level: the basic guide first
A real example: I actually built this guestbook, deployed it, and posted a real comment to confirm it lands in the database. Every prompt and every step below comes from that build, not from imagination, and the screenshots are the real screens.
Prerequisites: this page assumes you already have the basics down: Claude Code installed, GitHub and Vercel accounts, and a feel for pushing and deploying. If not,go through the basic guide firstto build the muscle memory, then come back. It will go much more smoothly.
How is this different? Three new things
The page in the basic guide is dead. Once it is built it sits there and visitors can only look. The page here is alive. Visitors can send data in, it gets stored, and it is still there next time. Three things make that difference:
Capability
Basic guide (static)
This page (with a backend)
Show text and images
✓
✓
Visitors send data in
✕ not possible
✓ comment form
Store the data
✕ no database
✓ saved into Supabase
Keep keys safe
not needed
✓ environment variables
Backend APIbackend
Everything in the basic guide runs inside the visitor's browser. A backend API is code running on a cloud server. It takes the comment in, decides whether to store it, and talks to the database. The browser cannot see what is inside it, so anything sensitive, touching the database or using a key, is handed to it.
Databasedatabase
Where the data lives. This page uses Supabase (free and easy to pick up). Every comment a visitor leaves becomes a row in the database, stored permanently, still there after a refresh or on another device.
Environment variablesenvironment variables
Connecting to a database takes a key. The key must not be hard-coded, and definitely must not be pushed to GitHub, which is the same as publishing it. Environment variables put the key in a file that never gets uploaded. This is the security mistake AI makes most often when writing code, and this page shows you the right way.
Before you start: one more account, Supabase
Claude Code, GitHub and Vercel carry over from the basic guide. There is only one new account here, Supabase (your cloud database).
0-1Create a Supabase account
Supabase is a free, easy cloud database platform. The fastest way to sign up is to log in with your GitHub account.
Go to supabase.com, then click the top-right Start your project
Choose Continue with GitHub (same as the Vercel sign-up, just authorize it)
Once inside, click New project, give it a name (say my-guestbook), set a database password (generate a random one and save it, this page barely uses it), and pick a region near you (Singapore, say)
Wait a minute or two and the project is ready
Prep checklist: ☐ Claude Code responds when you type claude ☐ you can log in to GitHub ☐ you can log in to Vercel ☐ you can open Supabase and see the project you just made. All four ticked → keep going.
11 prompts: talk a data-saving web page into existence with Claude
Same as the basic guide. Paste each prompt into Claude Code in order, press Enter when it finishes, then paste the next one. Every prompt has a copy button in its top right. First, in Terminal, move into the folder where your projects live (say cd ~/Projects) and type claude.
STEP 1Start the project (1 prompt)
The basic guide used plain HTML. This one needs a backend, so it uses Next.js, a framework that covers both front and back and that Vercel supports natively. You do not need to understand it, one sentence is enough.
Prompt 1 Create the guestbook project
Create a Next.js project called my-guestbook. I want a visitor guestbook: a comment form, and after you submit, the comment is saved and shown below. For now just get the project created and running on my machine.
What Claude does: uses create-next-app to create the project, installs the packages, and tells you to run npm run dev and open localhost:3000 locally. The screen is still empty at this point, which is normal.
STEP 2Connect the database (2 prompts)
Connect the project to the Supabase you just created, then open a table to hold the comments.
Prompt 2 Install the Supabase tooling
Install the official Supabase package @supabase/supabase-js. I am going to use it to save comments into the database.
What Claude does: runs npm install @supabase/supabase-js, the official Supabase client.
Prompt 3 Create the comments table
My Supabase needs a table called guestbook for comments, with columns for name, message and created time. Give me the SQL so I can paste and run it in the Supabase SQL Editor. Turn on RLS (Row Level Security) and add policies for "anyone can read, anyone can insert".
What Claude does: hands you SQL like the block below. Copy it, open SQL Editor in the Supabase left-hand menu → paste → hit Run. The table is created.
create table guestbook (
id bigint generated always as identity primary key,
name text not null,
message text not null,
created_at timestamptz not null default now()
);
alter table guestbook enable row level security;
create policy "anyone can read" on guestbook
for select using (true);
create policy "anyone can insert" on guestbook
for insert with check (true);
What RLS is and why it matters: Row Level Security is the door policy on your database. Turning on RLS without writing a policy locks the whole table, and nobody gets in.So you always pair it with a policy that says who can do what. For a guestbook we open up reading and inserting for everyone, but not deleting or editing , so nobody can change or remove a comment. That is security lesson one: lock everything by default, then open one door at a time.
Once it exists, every comment a visitor leaves lands as a row in the Supabase guestbook table, and this is real data from my own run.
STEP 3Environment variables: hide the keys (2 prompts)
This is the most important part of the page, and the part AI most often gets wrong. Connecting to the database takes two things: your Project URL and an anon key. We put both into a file that never gets uploaded.
First, grab those two from Supabase
In your Supabase project, bottom left, open Project Settings → API (some versions call it Data API / API Keys), where you will see:
Copy Project URL and anon public key and nothing else. The one below, service_role , is a secret key. This page does not use it, so leave it alone.
Prompt 4 Set up the environment variable file
Create a .env.local file in the project root with two environment variables, SUPABASE_URL and SUPABASE_ANON_KEY. Use placeholder values for now, I will paste the real ones in myself. Also confirm .gitignore excludes .env.local so it never gets pushed to GitHub.
What Claude does: creates .env.localand confirms .gitignore contains .env* (Next.js has it by default, so your keys are excluded from the start).
Then you paste in the two values you just copied, so.env.local looks like this:
SUPABASE_URL=https://your-project-ref.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJI...(the long string you copied)
This is where AI most often slips: plenty of people, and plenty of AI, take the shortcut of hard-coding the key and pushing it to GitHub, which is the same as taping your key to a public wall. The right way is always: keys live in .env.local, confirmed excluded by .gitignore , and the code only reads them through names like process.env.SUPABASE_URL .Before you paste, you can ask Claude "could my keys end up on GitHub?" and have it check once more.
STEP 4Backend and front end (2 prompts)
The backend touches the database, the front end shows and collects. Have Claude write them separately.
Prompt 5 Backend API (read and write comments)
Write me a backend API: one part adds a comment (writing the name and message into the guestbook table in Supabase), one part reads all comments back, newest first. Read the key from the environment variables, keep this code server-side only, and never send the key to the browser. Also do a basic length check on the name and the message so they cannot be blank or too long.
What Claude does: creates an API route (say app/api/guestbook/route.ts), reads the key with process.env , connects to Supabase to insert and query, and rejects blank or overlong input.
Prompt 6 Front end (form and comment list)
Build the guestbook screen: a form at the top (name, message, submit button) that calls the API we just wrote, clears the fields and refreshes on success, and below it every comment listed newest first with name, message and time. Keep the style clean and simple, a warm cream background with gold accents, and make it look good on a phone.
What Claude does: builds the form and the comment list and wires up the API. Your local screen now looks like the shot below.
Running locally at localhost:3000 . The form sits on top, the comments below, clean and simple. This is my real screen.
STEP 5Local test (1 prompt)
Before going live, confirm on your own machine that it really saves.
Prompt 7 Run it and test one comment
Start the site on my machine and tell me which address to open. I want to post a test comment, then refresh the page and confirm the comment is still there, which means it really went into the database.
What counts as passing: post a comment, then refresh the page and the comment is still there , which means it really reached Supabase. You can also open the Supabase Table Editor and look at the guestbook table, where the comment will be sitting. If it disappears on refresh something is not wired up, so screenshot the screen for Claude and say the comment is not being saved.
It works locally, so push it to GitHub and deploy to Vercel. There is one key step here the basic guide never had, you have to set the environment variables again on Vercel.
Prompt 8 Push to GitHub
Upload this project to GitHub, name the repo my-guestbook. Before uploading, check one more time that .env.local is not included.
What Claude does: initializes git, creates the repo, pushes. Because .env.local is in .gitignore , the keys arenotuploaded. Go look on GitHub, and if you cannot find .env.local , it worked.
Prompt 9 Deploy to Vercel
Connect my-guestbook on GitHub to Vercel, deploy it, and give me the URL.
What Claude does: connects Vercel, deploys, and hands you an xxx.vercel.app address.Opening it now may break, or comments may fail, because the keys were never uploaded and the cloud does not know where your database is.The next step fills that in.
Prompt 10 Set the environment variables on Vercel
Remind me to set the environment variables on Vercel. In the Vercel project I need Settings → Environment Variables with SUPABASE_URL and SUPABASE_ANON_KEY, the same values as my local .env.local, environment set to Production, and a redeploy once they are saved.
What you do: open the Vercel project → Settings → Environment Variables, paste in the two variable names and values (choose Production), and save.
The Vercel environment variables panel. Your local .env.local never gets uploaded, so you paste the values again here in the cloud. They are stored Encrypted and nobody else can read them.
Why set them twice?Your local .env.local is deliberately left out of the upload, which is what keeps the keys safe, so Vercel in the cloud never receives it. You have to tell it again in the Vercel dashboard. This is where beginners get stuck most often: works locally, breaks live is nine times out of ten a missing environment variable on Vercel, or a redeploy you forgot after setting them.
Prompt 11 Redeploy and verify live
The environment variables are set, so redeploy, then open the live address. I want to post a comment and confirm the live version really saves it into the database.
What counts as passing: after the redeploy, open the live address, post a comment, refresh and it is still there = done. Your page is alive now, and anyone on any device can leave a comment that lands in your cloud database.
The site live on Vercel. I posted a real comment to check that the live version writes into the cloud database.
The security traps this page steers you around
Once a page has a backend and a database, security is in play. AI is very good at making things run, and often makes them run without being safe. The approach here bakes in three correct habits for you:
Keys stay out of version control
Keys live only in .env.local, excluded by .gitignore , so they never appear on GitHub. The code only reads the names through process.env .
The database is locked by default, then opened minimally
RLS locks everything first, then opens only read and insert, never delete or update. Nobody can alter or remove your data.
The secret key stays on the backend
The code that touches the database runs server-side only, so the key never reaches a visitor's browser. The real super key (service_role) is not used anywhere on this page, and should never go near the front end.
Further reading: what AI can write on its own and what you have to watch yourself is collected in What is Vibe Coding?. The closer you get to members and payments, the less you can rely on chatting with AI alone.
What to do when you get stuck
With a backend in play, the sticking points differ from the basic guide. These are the common ones:
Works locally, breaks live: nine times out of ten the environment variables are missing on Vercel, or you forgot to redeploy after setting them. Go back to Prompt 10 in STEP 6.
Submitting a comment does nothing, or it will not save: usually RLS is on but there is no insert policy, which locks the whole table. Paste the error into Claude and say the comment will not write, ask it to check the RLS policies.
Red text in Terminal: copy the whole thing into Claude and say "I'm stuck here".
Not sure whether a key leaked: ask Claude to confirm your keys are not hard-coded in the code and were not pushed to GitHub.
The all-purpose rescue prompt:
Here is what I am seeing:
[paste the screen / error message here]
It works on my machine, the problem is live / at this step.
Help me work out the fix, step by step.
Rather not do it yourself
Need a site with a database, an admin panel, or members?
Guestbooks, sign-up forms, membership systems, an admin panel taking orders. Sites with a backend are more involved than a one-pager, and both the spec and the security need checking. Tell me what you have in mind and I will work out the best way to build it.
The basic guide builds a one-page static site: text, images and buttons, no database. This one adds three things, a backend API, a database and environment variables, so comments left on your guestbook stay there permanently, which a static page cannot do.
Q: Do I need to know how to code first?
No, you still just talk to Claude in plain language. It does help to finish the basic guide first and get used to the Claude Code / GitHub / Vercel flow, because this one has more steps and a bit of muscle memory makes it much smoother.
Q: Does Supabase cost money?
The free plan is enough for a guestbook and personal projects. It gives you a PostgreSQL database plus enough traffic and storage, and a build this size will not use it up. Only heavy usage, a commercial product, needs an upgrade.
Q: What are environment variables and why do they matter?
They pull secrets like keys and passwords out of your code and into a separate file that never gets uploaded. They matter because once a key is pushed to GitHub and someone sees it, the key to your database is public. One of the most common mistakes AI makes when writing code is hard-coding keys.
Q: Can I add member login and payments after this?
Yes. The backend, database and environment variables here are the foundation for login and payments, and Supabase has member login built in. The more complex the feature, the higher the security risk, so get a person to check it rather than relying on chat with AI alone.
Q: Can I follow along on a phone?
No, like the basic guide it needs a desktop computer (Mac / Windows). A phone cannot run the Claude Code command line or npm / git / vercel.