Build a site with a backend and a database from 0

Advanced version · a real guestbook build · Next.js + Supabase + environment variables

黃志弘 Leo

Published 2026-06-26 · Updated 2026-10-07 · 1 readers

A guestbook that really saves what visitors write

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 hours Base 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. In October 2026 Supabase switched to a new key system, so I rewrote the part about getting keys and ran the commands again on my own machine. The terminal screens are real output from that day, the Supabase keys page and the Vercel environment variables are diagrams, and the other screenshots are the real screens from the original build.

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 first to build the muscle memory, then come back. It will go much more smoothly.

Three new things this time: a backend API, a database, environment variables

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.

Sign up for Supabase and create your first project

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 (or go straight to database.new), 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

If the button names don't match: Supabase changes the wording on its home page now and then, so look for the button that means sign up or create a project. On the free plan you can have at most 2 active projects, and a project with no activity for a week gets paused (the rules on Supabase's pricing page, checked 2026-10-07).

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 1Create the guestbook project with Next.js (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 and install the packages, and you get a line saying Success! Created my-guestbook. It then tells you to run npm run dev and open localhost:3000. The screen is still the default Next.js page at this point, which is normal.

If you get stuck: if you see npx: command not found, Node.js is not installed yet. Ask Claude to install Node.js, then paste Prompt 1 again.

Step 2Connect Supabase and create a table for comments (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, and the terminal prints something like added 8 packages (the number changes between versions; seeing "added" means it worked).

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), add policies for "anyone can read, anyone can insert", and explicitly grant read and insert to the anon role.

What you do: Claude hands you SQL like the block below. Copy it, open SQL Editor in the Supabase left-hand menu, paste, and hit Run. When the results area shows “Success. No rows returned”, the table is created (this SQL does not return any rows, so that is expected).

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()
);
grant select, insert on public.guestbook to anon;
alter table guestbook enable row level security;
create policy "anyone can read" on guestbook
  for select to anon using (true);
create policy "anyone can insert" on guestbook
  for insert to anon 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.

The extra grant line: without it, your RLS policies can be correct and the table can still refuse to be read or written. New tables used to get these permissions automatically, and Supabase's docs say that default is being changed, so adding it yourself is the safe choice. I ran this SQL once on a local Supabase and every line went through. If you later see 42501 or permission denied for table guestbook, the grant is missing; paste the error into Claude and it will add it.

The Supabase Table Editor showing the guestbook table with RLS enabled and four comment rows — 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 3Get the Project URL and publishable key into .env.local (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 a publishable key. We put both into a file that never gets uploaded.

Supabase has new keys: Supabase's docs say the legacy anon and service_role keys are being retired by the end of 2026, replaced by the publishable key (starting with sb_publishable_) and the secret key (starting with sb_secret_). The new keys are short strings. If a tutorial asks you to copy a long key starting with eyJ, it was written for the old keys; this page uses the key that starts with sb_publishable_.

Copy these two values from Supabase

Open your Supabase project. Either of these places has them, pick one:

Your project's Connect dialog: choose Next.js as the framework and it lists the Project URL and the publishable key, ready to copy.
Project Settings → API Keys: every key lives on this page, and the Project URL also shows in the Connect dialog. If a tutorial points you to "Settings → API", that page is gone; look on API Keys instead.

Diagram: Supabase keys come from the Connect dialog or the API Keys page in Project Settings; this guide uses the publishable key, does not need the secret key, and the legacy anon and service_role keys end in late 2026 — Copy the **Project URL** and the **publishable key** and nothing else. The secret key bypasses RLS; this page does not use it, so leave it alone. (Diagram based on Supabase's API keys docs)

If you get stuck: if the API Keys page only shows the legacy anon and service_role keys, the project has no new keys yet. Supabase's docs say to create a publishable key on that same page. The legacy keys keep working, and both sets can live side by side.

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_PUBLISHABLE_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.local and confirms .gitignore contains .env* (Next.js has it by default, so your keys are excluded from the start). To check yourself, type git check-ignore -v .env.local in the terminal. If it prints .env.local, the file is excluded:

Terminal: npm install @supabase/supabase-js shows added 8 packages; grep finds .env* on line 34 of .gitignore; git check-ignore confirms .env.local is excluded — Real output, run again on my machine in October 2026. The last line prints `.env.local`, so git will not push it to GitHub.

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_PUBLISHABLE_KEY=sb_publishable_...(the string you copied)

In Supabase's own examples, variables meant for the browser start with NEXT_PUBLIC_. This page only reads the key inside the backend API, so it has no prefix, and Next.js will not bundle it into the page.

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 4Have Claude write the backend API and the guestbook screen (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. Connect using the environment variables SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY, 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.

The guestbook running locally, cream background with gold accents, the comment form on top and three comments below in time order — Running locally at `localhost:3000`. The form sits on top, the comments below, clean and simple. This is my real screen.

Step 5Post a comment locally and confirm it saves (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.

To double-check the key and RLS: ask Claude for a small script that tries one insert, one read and one delete with the publishable key. On a local Supabase it came out like this: insert and read succeed, and RLS blocks the delete.

Terminal: inserting a comment with the publishable key succeeds, reading returns one comment, and the delete attempt removes 0 rows — 0 rows deleted is correct: the "no deleting" rule from Step 2 is working. (Real output from a local test Supabase, October 2026)

Step 6Push to GitHub, deploy to Vercel, then add the environment variables (3 prompts)

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, and pushes. Because .env.local is in .gitignore, the keys are not uploaded. 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_PUBLISHABLE_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, go to Settings → Environment Variables, paste in the two variable names and values (choose Production), and click Save.

Diagram: the Environment Variables page in a Vercel project's Settings with SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY for Production, then save and redeploy — Your local `.env.local` never gets uploaded, so you paste the values again here in the cloud. The names must match your local file exactly. (Diagram)

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. Vercel's docs also say changed variables only apply to new deployments. So the most common case is works locally, breaks live, and the cause is usually 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 if it is still there you are done. Your page is alive now, and anyone on any device can leave a comment that lands in your cloud database.

The guestbook live on Vercel with several comments, including one posted to verify the live version — 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, the secret key (called service_role in the old system), bypasses every RLS policy. This page does not use it anywhere, and it 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.

Fixes for "works locally, breaks live" and comments that won't save

With a backend in play, the sticking points differ from the basic guide. These are the common ones:

Works locally, breaks live: usually 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: read the error first. permission denied or 42501 means the grant is missing. No error but nothing saved usually means RLS is on with no insert policy, which locks the whole table. Paste the error into Claude and ask it to check the grant and the RLS policies.
Invalid API key: check that you pasted the string starting with sb_publishable_, with no extra spaces, and that the variable is named SUPABASE_PUBLISHABLE_KEY both locally and on Vercel.
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.

Free consultation →

FAQ

Q: How is this different from the basic guide?

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, with a 500 MB database per project. Two rules to know: the free plan allows at most 2 active projects, and a project with no activity for a week gets paused. Only heavy usage, a commercial product, needs an upgrade.

Q: I followed an older tutorial and copied the anon key. Does it still work?

It works for now, but Supabase says the legacy anon and service_role keys are being retired by the end of 2026. Create a publishable key under Project Settings → API Keys, swap it into both your local .env.local and Vercel, then redeploy.

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.

Tools used on this page

Claude Code (Anthropic's official CLI)　　claude.com/claude-code

Next.js (a full-stack framework, made by Vercel)　　nextjs.org

Supabase (free cloud database)　　supabase.com　Keys: official API keys docs

GitHub (free code hosting)　　github.com

Vercel (free web deploys; the free Hobby plan is for personal, non-commercial use)　　vercel.com

Follow and share

Join the LINE community Follow on Instagram @kanisleo328 Follow on Threads @kanisleo328