Building With AI

There are dozens of tools. You need four, and three of them are free.

Claude Design — for branding and screens. Before any code exists, you decide what the thing looks like. Doing this first is not vanity; it is the cheapest moment to change your mind. Moving a button in a design costs nothing. Moving it after three screens are built costs an afternoon.

VS Code, with Claude Code installed — for building. Free, and the editor most tutorials assume, so when you get stuck the answers you find will match what is on your screen.

A word on Cursor. People will tell you to use Cursor instead. I would not, for a beginner. Cursor is a fork of VS Code with AI built in, which means you are learning a modified editor rather than the standard one, and it charges a subscription for something you can add to VS Code for free. Learn the normal tools. Add the AI to them.

Vercel — for putting it on the internet. Free tier, connects to your GitHub, and every push deploys automatically. You will not touch a server.

Supabase — for your database, accounts and file storage. Free tier, Postgres underneath, and it handles sign-in for you. Authentication is the single most dangerous thing to write yourself; let someone else do it.

The whole setup, start to finish:

# 1. VS Code — code.visualstudio.com, then install Claude Code
npm install -g @anthropic-ai/claude-code

# 2. A project
npx create-next-app@latest myapp --typescript --tailwind --app
cd myapp

# 3. Point Claude at it
claude

# 4. Supabase client
npm i @supabase/supabase-js

Then .env.local, which never goes near git:

NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
# SUPABASE_SERVICE_ROLE_KEY — server only. Never in a component.

Check .gitignore contains .env* before your first commit. Committing a service-role key is the mistake that ends projects, and GitHub will email you about it roughly four minutes after you push.

What this costs to start: nothing. Claude has a paid tier and it is worth it once you are working daily, but everything else on that list has a free plan that will carry a real product with real users.

What you do not need, despite what you will be told: a domain on day one, a designer, a CI pipeline, Docker, Kubernetes, a "tech co-founder", or a course costing $99 a month.

Open Claude and describe the business before you describe the software. The mistake is asking for a screen. Ask for an identity first.

Prompt 1 — the brand. Give it the real business, not a category:

I run a mobile car valeting business in Hertfordshire. Customers book a slot, I come to them, I take payment after. Most bookings come from phone calls I miss while I'm working.

Create a brand identity: a colour palette with hex values, two typefaces from Google Fonts with the reason for each, and a short description of the tone of voice. It should feel trustworthy and local rather than corporate. Give me the palette as CSS custom properties I can paste into a stylesheet.

Two things make that prompt work. It describes a real problem (missed calls), and it asks for a specific output format (hex values, CSS custom properties). Vague prompts produce vague designs.

Prompt 2 — the screens. Now design against the brand:

Using that palette and those fonts, design the booking flow for the website: a landing page, a page for choosing a service and a time, and a confirmation page. Show them as artboards side by side. Mobile width, 390px, since most customers will be on a phone.

Prompt 3 — the mobile app, if you need one. Ask honestly first:

Given this business, is a mobile app justified or would a mobile website do the job? Answer honestly and tell me what an app would add that a website could not.

If the answer is that a website would do, believe it. Most of the time it is true, and you have just saved yourself months.

What you should have at the end of this lesson: a palette, two fonts, a tone of voice, and pictures of every screen. No code yet. That is correct.

You have designs. Now turn them into a project. This is the step people skip and then wonder why the AI keeps producing something that does not match.

Write the brief down first, in a file. Create PROJECT.md in an empty folder and put everything the AI needs to know in it:

# Valet booking site

## What it does
Customers book a mobile car valet. They pick a service, pick a time,
enter their address, and get a confirmation. I get a notification.

## Who uses it
Customers on phones, mostly aged 30-60, booking in under two minutes.
Me, on a phone, checking today's jobs.

## Brand
--brand:      #0F3D3E
--accent:     #F4A259
--ink:        #14171A
--paper:      #FBF9F6
Headings: Fraunces. Body: Inter.
Tone: local, plain-spoken, no jargon.

## Stack
Next.js, TypeScript, Tailwind. Supabase for data and auth.
Deployed on Vercel.

## Rules
- Mobile first. Design for 390px and scale up.
- No feature I have not asked for.
- Every price in pounds.

Why this file matters more than any prompt. The AI reads it at the start of every session. Without it you re-explain your project every time and get a slightly different interpretation each time. With it you get consistency for free. It is the single highest-return ten minutes in this entire track.

Then open VS Code, install Claude Code, and start with scaffolding rather than features:

Read PROJECT.md. Set up a new Next.js project with TypeScript and Tailwind in this folder. Configure the brand colours from PROJECT.md as Tailwind theme values and load the two fonts. Build nothing else yet — just the shell, and show me it running.

Run it. Look at it. Only when the shell is right do you ask for a screen. People try to get the whole app in one prompt and then cannot work out which part of the resulting mess is wrong.

This is the actual skill. Everything else is setup.

Working with AI is not writing a perfect prompt and receiving a perfect result. It is a loop, and once you internalise it you will build faster than you thought possible.

Plan → Build → Verify → Correct. Every cycle, on every feature.

Plan. Before it writes anything, make it tell you what it intends to do:

Before writing any code, tell me how you would build the service-selection screen: which files you would create, what the data shape would be, and anything you are unsure about. Do not write code yet.

Reading a plan takes thirty seconds. Reading two hundred lines of wrong code takes ten minutes and you have to undo it. If the plan is wrong, the code will be wrong — correct it here, where it is cheap.

Build. Now let it work, and keep the scope small:

That plan is right except the price should live in the database, not in the code. Build it that way.

Verify — and this is the step people skip. Never trust "I've implemented it". Ask for proof:

Run the dev server, open the booking page, and confirm the three services render with the right prices. Tell me what you actually saw, not what you expected.

An AI that has checked its own work will tell you when it failed. One that has not will tell you it worked, because that is the likely-sounding sentence. Insist on evidence. Screenshots, terminal output, the actual response — something that exists outside its own claim.

Correct. When something is wrong, say what is wrong, not how to fix it:

The confirmation page shows the time in American format. It should be UK.

Not: "change line 42 to use en-GB". You are describing the outcome; let it find the cause. If you prescribe the fix, you have to know the fix, and then what is it for?

The rule that saves the most time: one thing at a time. Ask for one change, verify it, commit it, then ask for the next. Ask for five things at once and when it breaks you will not know which of the five did it. This feels slower and is dramatically faster.

When to start a fresh conversation. Long sessions drift — the AI accumulates context and starts referring to decisions you reversed an hour ago. When you notice it repeating old mistakes, start a new chat. PROJECT.md means you lose nothing.

Supabase gives you a real Postgres database, sign-in, and file storage. You will do almost all of it through prompts, but you must understand the shape.

Create the project on supabase.com, choose the free tier and a region close to your users — London if they are British. Copy the project URL and the anon key.

Never commit your keys. Put them in .env.local, and make sure .gitignore contains .env*. The anon key is safe in a browser by design; the service_role key is not, and must never appear in front-end code. Anyone who has it owns your database.

Design the tables in conversation before creating any:

I need to store: services (name, price, duration), bookings (customer name, phone, address, chosen service, time slot, status), and me as the only admin user. Propose the table structure with types and relationships. Do not create anything yet — show me the design.

Then the part that actually matters — Row Level Security.

Supabase tables are exposed over an API. Without RLS, anyone who finds your URL can read every booking you hold: names, addresses, phone numbers. This is how amateur projects leak customer data, and it is the single most common serious mistake in this stack.

Enable Row Level Security on both tables. Customers should be able to create a booking and read only their own. Only the admin user should be able to read all bookings or change status. Write the policies, explain each one in plain English, then show me how to test that a customer cannot read someone else's booking.

Then test it as an attacker would, not as an owner:

Write a script that tries to read all bookings using only the anon key, as a stranger would. Run it. Show me the output.

If that returns data, you have a problem. Finding out now is free. Finding out from a customer is not.

Put it on GitHub first. Create a repository, push your code. This is your undo button and Vercel reads from it.

Connect Vercel. Sign in with GitHub, import the repository, add the environment variables from .env.local into the Vercel dashboard. Deploy. It takes about a minute and gives you a real URL on the internet.

Environment variables do not apply to existing builds. Add them, then redeploy. This catches everybody once, and the symptom is a site that works locally and breaks live.

git init && git add -A && git commit -m "First version"
gh repo create myapp --private --source=. --push

# Then on vercel.com: New Project → import → add env vars → Deploy

Every push now deploys automatically. Push to main and it goes live. Push to a branch and Vercel builds a preview URL you can send someone before it is real.

For a mobile app: Xcode and Claude remote. If you have gone the app route with React Native and Expo, most of your work stays in VS Code. Xcode is needed for the parts that touch Apple: signing certificates, provisioning, capabilities like push notifications, and the final upload.

The workflow that works: keep Claude in VS Code driving the code, and treat Xcode as the place you go to sign and submit. When Xcode produces one of its famously unhelpful build errors, paste the whole thing in:

Xcode build failed with this error. Explain what it means in plain English and what to change. Do not guess — if you need to see a config file, ask for it.

Claude Code can also run on a machine you connect to remotely, which is genuinely useful for Apple work: builds happen on the Mac, while you direct it from wherever you are. The important habit is the same either way — make it show you the actual build output rather than telling you it should work now.

Ship earlier than feels comfortable. A booking form that works beats a beautiful app nobody can use. You will learn more from one real customer than from three more weeks of building.

Being honest about the limits is what separates using this well from being surprised by it.

It writes plausible code that is subtly wrong. Wrong is easy to spot; nearly-right is not. A date that works until the clocks change. A total that rounds the wrong way on odd pennies. This is why the verify step exists, and why you test with real, awkward data rather than the neat example it invented.

It does not know your business. It does not know that Thursdays are your busiest day, that customers always ask about the van, that the price changes for anything over a certain size. That knowledge is yours, and putting it in PROJECT.md is how the software ends up matching reality.

It is confident when it is wrong. There is no tone difference between certainty and guessing. Treat "this should work" as a hypothesis and go and look.

It will happily build the wrong thing beautifully. It has no opinion about whether your idea is any good. That judgement stays with you, and it is the part that actually matters.

What you still need to learn. You do not need a computer science degree, but you do need enough to read what it writes and notice when it is odd. Follow along, ask what a line does when you do not know, and after a few months you will be reading code fluently without having sat a single exam.

And the thing nobody says: the hard part was never the code. It is knowing what to build, finding the first person who will pay for it, and keeping it running once they do. AI collapsed the cost of the middle bit. The two ends are still yours.