A field guide

Building apps with Claude, for people who don't code.

Most of what's on this site I built by talking to Claude, usually on my phone. The second half of this guide is how I actually do it. The first half is the setup I wish someone had walked me through.

If you get to the end you'll have a site with your name on it and a thing on it you made. Along the way: your idea checked for whether it's a good first build, a small app made in Claude, and the first rough version of your idea on your phone, reviewed and tested.

Breathe Wayfind Chant Die Loaded Cadence PlotCraft

Each of these started as a sentence typed to Claude.

What you need

• A phone is enough to start. You can build and try apps in the Claude app.
• You'll want a computer for two things: getting a shareable link for an app made in the Claude app (that button isn't in the phone app yet), and the one-time setup for your own website. A library computer works fine. Everything else works on a phone.
• Money: nothing to start. Your own website needs Claude Pro, $20 a month. The rest is free.

How long it takes

Reading the whole guide takes 20 to 40 minutes. Making your first app takes about 30 minutes. Setting up your own website takes an hour or two the first time, more if something snags, and it's fine to split it over two sittings. There's a You can stop here note wherever that's true. Your ticks and your idea are saved on the device you're reading on, so if you start on your phone and finish on a computer, you'll retype your idea once.

Anything shown like this is something to type to Claude, in those words or your own. Quotes marked From my history are real messages I've sent Claude, with typos fixed.

Background

Is your idea a good first build?

The easiest apps are the ones that need the least from outside your own device. Try your idea against this quiz. No idea yet? Skip the box, or pick one later from the starters in First session.

Making something for other people, like a class or a club, doesn't make it red by itself. What matters is whether the app holds their details. A spelling quiz with no pupil names in it is green. The same quiz keeping each child's scores on their own device is still green. One that collects every child's scores in one place is red.

The three tiers

What decides the tier is where the data lives.

What is an LLM?

An LLM (large language model) is the kind of AI that Claude, ChatGPT and Gemini are: a program trained on a huge amount of text, including a lot of code. When people say "AI" in this guide, this is what they mean. It's trained to guess the next word. It turns out that if it gets really good at that, it can also explain, plan and write software.

Two things worth knowing:

• Each new session starts fresh unless something is written down for it. Projects keep a plain-text notes file for this, called CLAUDE.md. Claude writes it for you.
• It makes mistakes, and it only knows what you tell it. Vague asks get generic results, and a confident answer isn't proof. Give it your own word list, your own rules, and then use what it built.

Getting set up

The four services

To start, you only need Claude. Most of the finished apps on this site use the first three.

What this actually costs

I pay for Claude and a server for one game. Everything else I use is on a free plan.

Checked October 2026 against Claude's pricing, GitHub's pricing and Netlify's docs. Prices change, so check again.

To cancel Claude Pro: Settings, then Billing. It stays on until the end of the month you paid for.

Getting set up

Your first session, one screen at a time

There are two levels. Level 0 takes about 30 minutes and needs only a Claude account. Level 1 gives you your own website. Do level 0 first, even if you're sure you want level 1.

The screens below are drawings of what Claude, GitHub and Netlify will show you on their own sites. Nothing on this page is a form to fill in. The real screens have more on them and may look a little different; look for the highlighted part.

Level 0: make something in the Claude app

No GitHub, no hosting, and the free plan works. You get a working app and a link you can send people.

1. Pick what to make. Your own idea, or one of these. Small is good. You can grow it later. Your idea, in one sentence
2. Open Claude in the app or at claude.ai, and start a new chat. Sign up with your email if you haven't.

   What Claude shows youclaude.ai

   example

   Make a tip calculator I can use on my phone…

   Reply to Claude…

3. Send this prompt. It already has your idea in it.

   Prompt · your first app

   Make [one sentence about your idea], the smallest version, as an interactive artifact I can use on my phone. Big buttons I can tap with one thumb. Use made-up example data, not real names.

   Copy

   "Artifact" is Claude's word for an app that runs inside the chat. "Made-up data" means no real people. Your own lesson content, a word list or a recipe, is fine to paste.

4. Watch it appear. The app shows up next to the chat. On a phone, tap it to open it. It works right away, so try it.

   What Claude shows youclaude.ai

   example

   Tip calculatorBill$48.0015%18%20%Split123$28.80 each

5. Mess with it. Change it by asking, and don't be careful about it. Try make it a game, make it look like 1995, add a sound when I tap, or make it for a 6-year-old. If you don't like a change, tell Claude undo that. Mine were all ugly at this point.
6. Share it, from a computer. Open the same chat at claude.ai, open the app and press Publish (it may say Share), then copy the link. Anyone can open it, no account needed. The phone app can't do this step yet. Anything in the app becomes public, so keep personal info out of it. To take it down later, the same button has an Unpublish option.

   What Claude shows youclaude.ai

   example

   My appPublish

   Anyone with the link can use it.claude.ai/public/…Copy link

Before you move on: what did you have to ask for more than once? Write it down. That's your first rule for a project's notes file.

An app made in chat usually can't remember anything between visits, and it lives inside Claude. When you want your own web address, or an app that grows over many sessions, move up to level 1.

You can stop here. You made an app.

Words you'll meet in level 1

Repository (repo)

Your project's folder on GitHub, with every version saved.

Pull request (PR)

A proposed change, waiting for you to accept it.

Merge

Accepting a pull request into the real project.

Preview

A link to a proposed change, so you can try it first. It's unlisted, not private: anyone with the link can open it.

Checks

Tests that run by themselves on every change. Green means they passed, a red X means something failed.

Deploy

Putting the latest version live.

Two-factor login

A second check when you sign in, like a code from an app on your phone.

Level 1: your own site

This needs Claude Pro ($20 a month, or $200 a year, and it renews until you cancel it in Settings, then Billing). GitHub and Netlify are free and don't ask for a card. Seven steps, an hour or two the first time. Steps 1 and 2 one day and the rest the next works fine. Most of the clicking only happens once, and next year you just open Claude Code again and carry on.

1. Make a GitHub account (about 10 minutes). GitHub is where your project's files are kept. Go to github.com/signup. Type your email, a password and a username (it shows up in your project's address, so pick something you're happy with), then press Continue. Or press Continue with Google or Apple instead.

   What GitHub shows yougithub.com/signup

   example

   Sign up for GitHubEmailyou@example.comPassword••••••••••Usernameyour-nameContinueor continue with Google / Apple

   What you'll see

   • A short puzzle to check you're a person. Follow its instructions.
   • An email from GitHub with an 8-digit code. Type it in. If it isn't there in a minute, check spam.
   • Maybe a few questions about how you'll use GitHub. You can skip them.
   • Your GitHub home page. Done.

   What GitHub shows yougithub.com

   example

   Enter codeWe sent a code to you@example.com4815027_Didn't get it? Check spam.

   Some time in the next few weeks, GitHub may ask you to turn on two-factor login: a second check when you sign in, using a code from an app like Google Authenticator, or a passkey on your phone. It takes about five minutes. Do it when asked, and save the recovery codes it gives you somewhere safe.

2. Make an empty project (2 minutes). GitHub calls a project a repository, or repo. Go to github.com/new. Type a name with no spaces, like my-first-app. Choose Private. Switch Add README on. Press Create repository. Ignore everything else on the page.

   What GitHub shows yougithub.com/new

   example

   Create a new repositoryRepository namemy-first-appVisibilityPrivateAdd READMECreate repository

   What you'll see

   • A page with your project's name at the top and one file, README.md. That's your repo.

   Private is free. Only you, and the apps you connect (Claude and Netlify), can see the files. The website you make from them can still be seen by anyone with its link. Private repos get 2,000 free minutes of automated checks a month, which is several hundred runs; see the costs table if you're curious.

3. Open Claude Code and connect GitHub (5 minutes). If you're on the free plan, upgrade first: in Claude, open Settings, then Billing, and pick Pro. Claude Code is a separate screen in the same app and site, where Claude works on the files in a repo instead of in a chat (your level 0 chat stays where it was). In the Claude app tap Code, or go to claude.ai/code. Press Connect GitHub, and on GitHub's page press Authorize.

   What Claude Code shows youclaude.ai/code

   example

   Claude CodeConnect GitHub so Claude can work on your projects.Connect GitHub

   Because your repo is Private, Claude also needs the Claude GitHub app. When it offers to install it (or go to github.com/apps/claude and press Install), choose Only select repositories, pick my-first-app, and press Install. That lets Claude see this one project and nothing else.

   What GitHub shows yougithub.com/apps/claude

   example

   Install ClaudeAll repositoriesOnly select repositoriesmy-first-appInstall

4. Ask for your first page (5 to 10 minutes of Claude working). Under the message box are two small menus. The first is your repos: pick yours. The second is the mode. Leave it as it is. (Plan mode makes Claude write a plan and wait for your OK before it touches anything, which is useful later but slower now.) Paste the prompt below and send it.

   What Claude Code shows youclaude.ai/code

   example

   Make a one-page…

   your-name/my-first-appAuto

   Prompt · your first page

   Make [one sentence about your idea] in this repo, as one page of plain HTML, CSS and JavaScript (no build step: just files a browser can open). It should fit on a phone screen with big, easy-to-tap buttons. Use made-up example data.

   Copy

   HTML, CSS and JavaScript are the three kinds of file a web page is made of. You don't need to know more than that; the line tells Claude to keep it simple.

   What you'll see

   • Claude's messages as it works: reading the empty project, writing files, sometimes checking its own work. You can close the app; it keeps going.
   • Maybe a permission question. Yes if it's reading or changing files in this repo, or running its own tests. Ask first if it mentions deleting, your account, other repos, installing something, or sending data somewhere.
   • When it's done: a short summary, a count like +214 −0 (lines of code added and removed), and a Create PR button.

   What Claude Code shows youclaude.ai/code

   example

   Done. I made index.html, style.css and app.js. It fits a phone screen and the buttons are 64px.

   +214 −0 3 filesCreate PR

5. Make it a pull request and merge it (3 minutes). Press Create PR. A pull request is the change, waiting for you to accept it. Claude shows a link to it; press that, and GitHub opens the pull request's page. Tap Files changed and skim: you should see only files that belong to your app. Then come back to Claude and say merge it. If it says it can't, use the green Merge pull request button on that GitHub page, then Confirm merge. Merge means accept it into the real project.

   What GitHub shows yougithub.com/…/pull/1

   example

   Add my first app #1Open · 3 files changedConversationFiles changedMerge pull requestthen Confirm merge

6. Put it online with Netlify (10 minutes). Go to app.netlify.com/signup and choose Sign up with GitHub, then Authorize. Choose Add new project, then Import an existing project, then GitHub.

   What Netlify shows youapp.netlify.com

   example

   Add new project ▾Import an existing projectStart from a templateDeploy manually

   What Netlify shows youapp.netlify.com

   example

   Deploy my-first-appBuild commandleave emptyPublish directoryleave emptyDeploy

   What you'll see

   • GitHub asks which repositories Netlify can see. Choose Only select repositories, pick my-first-app, and press Install.
   • Back on Netlify, a list with your repo in it. Pick it.
   • A settings page. Leave the build command and publish directory empty, and press Deploy (it may say Publish).
   • A progress page for a minute or two, then "Published".

   Netlify's free plan deploys private repos that belong to your own account. Repos that belong to a GitHub organization need a paid Netlify plan, so keep it in your own account.

7. Open it on your phone. Your address is at the top of Netlify's page for the project, something like my-first-app-1234.netlify.app. You can give it a nicer name later in the project's settings. Open it on your phone. That's your own site, and every change you merge from now on shows up there by itself.

   From now on, every new pull request gets a comment from Netlify with a Deploy Preview link. That's where you try a change on your phone before you merge it. The preview is a normal web link, so don't put real data in it either.

   Your site, on your phonemy-first-app-1234.netlify.app

   example

   Tip calculatorBill$48.0015%18%20%Split123$28.80 each

Stuck on a screen? Take a screenshot and send it to Claude in a regular chat with I'm setting up GitHub for the first time and I'm stuck here. What do I tap? Crop out anything personal first.

You'll see these. They're normal.

You can stop here. Your site is live. Honestly, most people should.

Getting set up

Staying safe

Here's what I'd want someone to tell me before I pasted a password into a chat. If your app is green and you never paste a key, the parts that matter most are 2, 3 and 5.

1. Keep secrets out of everything

A secret is anything that lets someone act as you. A password. An API key, which is a password a service gives your app so it can use that service. A token, which is the same thing for a login. Or a file named .env, where programmers usually keep all of those.

• Don't paste secrets into a chat. Claude doesn't need to see a key to set it up. Ask where it goes and paste it there yourself.
• Never put a secret in your project's files. Even in a private repo, it sits in the history of every version.
• Never put a secret in the app itself. Anyone can read the code of a web page. A key belongs in a server function: a small piece of code that runs on Netlify's computers instead of in the browser, where the key is stored in the project's settings (Netlify calls these environment variables, and you can mark one as secret so it's hidden in logs). Ask Claude to set this up. If the key is for an AI service, set a monthly spending cap on it at that service.
• If one leaks, replace it right away. Go to the service that gave you the key and make a new one, which turns the old one off. Deleting the file isn't enough, because GitHub keeps every past version.

Before I make this public, check the whole repo, including its history, for passwords, API keys, tokens, .env files and personal information. List what you find and where. Don't change anything yet.

2. Be careful with personal info

What you paste into Claude leaves your device and goes to Anthropic's servers. In Settings, then Privacy, there's a switch called Help improve Claude. On, your chats can be used to train future models and are kept for years. Off, they're kept for about a month and not used for training. Pick what you're comfortable with. Either way, some things don't belong in a chat or an app:

• Other people's information: names, addresses, phone numbers, messages, photos of them. Especially kids.
• Anything that could cost someone money or safety: health details, bank or card numbers, ID numbers, passwords.
• Screenshots with extra stuff in them. Crop out notifications, email addresses and account numbers before you send one.

When you need examples, use made-up ones. Tell Claude use fake names and numbers in the sample data. A published app, a public repo and a website can all be seen by anyone with the link.

3. Check its work

• It can be confidently wrong, about code and about facts. Use the thing and see.
• "I tested it" means it ran its own checks, not that it works on your phone. Open the preview yourself before you merge.
• It sometimes invents libraries that don't exist, and people have registered those made-up names to slip in harmful code. When it adds a library, ask is this library well known? Give me a link to its page. If it can't, say don't use it.
• Ask Claude to explain. Before a merge, send it What did you change, in plain words, and what could go wrong?

4. Know what it can touch

Claude Code can read and change every file in the repos you give it, run commands, and open and merge pull requests.

• Give it only what it needs. When GitHub asks which repositories to allow, choose Only select repositories.
• Say no to settings you don't understand. If Claude ever suggests turning off permission prompts, auto-merging, or "skipping checks" to go faster, say no.
• You can take access back. On GitHub, Settings, then Applications lists Claude and Netlify, with an Uninstall button each. On Netlify it's under Team, then Connected accounts.
• Watch for instructions hidden in content. A web page, file or comment can contain text written to steer an AI. This is called prompt injection. If Claude suddenly wants to do something you didn't ask for, like send data somewhere, install something unusual or change account settings, stop it and ask why.

5. Data that lives on a phone can disappear

An app that saves on the device (green tier) saves into the browser's storage. That's private, but it isn't permanent: clearing the browser's data wipes it, and iPhones can clear it themselves after a week without a visit. Two habits help. Have the app offer an Export button that saves a copy, and tell people to Add to Home Screen, which keeps it. If other people's children will use it: scores and progress with no names, on their own device, is still green. A name, a photo or anything else that identifies a child means the grown-ups need to know what it keeps. Collecting it all in one place is a different project (red tier).

Before anything goes public

• No passwords, keys or .env files in the repo or the app.
• No real personal info in the sample data, screenshots or text.
• You've used the preview yourself.
• If it collects anything from visitors, you know where that goes and who can see it, and you've told the people testing it.

Print this chapter

You can stop here. That covers the setup.

The process

From idea to shipped

Once you can get a page live, the rest is going around this loop. Claude drew the wheel from how my projects tend to go. I don't think of it as seven steps, but this is roughly it, and every lap goes live as soon as you merge it.

Following along with a different kind of app? The example through the next chapters is a chore chart for two kids on a tablet. Each stage also has a line for a quiz app, since that's the other thing people most often make first. Any phone or tablet works the same.

The process · 1

Let Claude interview you

Before you see how I do it, try it yourself. Your friend wants a chore chart for their kids. How would you ask Claude to make it?

That's the method. Describe your idea loosely and ask Claude to interview you with multiple-choice questions. It asks about things you wouldn't have thought to decide, and the options show you what's possible. You still make every call. When none of the options fit, type your own answer. I still do this for every project, and I still get surprised by question three.

What comes out is a short plan that opens with a table of your answers. The one for making this site installable as an app settled 25 decisions over two sessions. The first few:

Now do it with your idea

Paste this into Claude Code with your idea's repo picked.

I want to build [one sentence about your idea].

Before writing any code, interview me with multiple-choice questions to pin down the requirements: who it's for, what it does first, how it should look and feel, and what it should NOT do. A few questions at a time. When you have enough, write the requirements back to me as a short list for me to check. When I say it's right, save it as REQUIREMENTS.md in the repo.

You're done when a REQUIREMENTS.md you've checked, including what it should NOT do, is in the repo.

The process · 2

Look for what already exists

A lot of hard problems already have free code out there. Open source means code anyone can use, under a license that says how. A library is a packaged piece of it, like a physics engine, a map or an audio player, that your app can use. The license is the only part you need to care about. MIT, Apache and BSD are the names of the common ones that say "use this however you like, for free", and Claude checks this for you.

Have Claude research twice: right after the interview for the big pieces, and again whenever something turns out to be hard. Ask for libraries, techniques other people used, similar projects, and free data. Prefer small things that work offline without accounts, and projects people still maintain.

Before we build [one sentence about your idea], research what we can reuse. Look for:
- open-source libraries that do the hard parts
- techniques other people have used for the same problem
- similar projects worth learning from
- free public data or APIs we could use

Prefer permissive licenses (MIT, Apache, BSD), projects that are actively maintained, and things that are small and work offline without accounts. Give me a short ranked list with pros, cons and a link for each, and end with your recommendation.

You're done when you have a short ranked list, each with a link and a license, and you've picked one, or decided you don't need one.

The process · 3

Rough, but working

This is what good enough looks like on day one. Drag to compare:

Day oneToday

The first version should be ugly and work. For anything bigger than a weekend, have Claude make a plan first and work through it in chunks, checking each chunk before moving on.

Made-up data, no keys in the files. See Staying safe.

Build the smallest version of [one sentence about your idea] that actually works, using REQUIREMENTS.md. Plain and rough is fine. Just the core thing, nothing extra. Use made-up sample data. When it's done, open a pull request so I can try the preview on my phone.

You're done when the main thing works on your phone, from the preview link.

The process · 4

Refine in small asks

Use it on your phone from the preview link and notice what feels off. Then ask for one small, specific change at a time. Screenshots help a lot: attach one with the + (or paperclip) in the message box, same as in a chat.

First buildToday

When something is hard to describe, ask for a tool to describe it with. My monitor's dimmest settings didn't match the laptop's, so I asked: Can you put it on a slider so I can tell you which slider value corresponds with the native mac display. Then I just read the numbers off.

When you find yourself asking for the same thing twice, have Claude add it to CLAUDE.md, the project's notes file. Claude reads it at the start of every session. This site's says, among other things, "No emoji as graphics" and "Use relative URLs only."

Add this to CLAUDE.md so you follow it from now on: [your rule, e.g. "buttons are always at least 44px tall so they're easy to tap"].

You're done when you've made several small asks, and written at least one rule into CLAUDE.md.

The process · 5

Have Claude review it as a panel

Before anyone else sees it, ask Claude to review the work as several different people: a first-time visitor, someone who uses it every day, an accessibility expert, a picky designer. Each one uses the real app and comes back with a list of problems, worst first. Then you pick which ones to fix. They catch stuff you miss.

The reviewers can be famous people, too: a well-known designer or an expert in whatever your app is about. Chant's panel found a bug where pressing Another round quietly added 100 reps.

Do a multi-persona review of [the app / this screen / all the copy]. Pick 4-6 reviewers who'd see different problems, for example: a first-time visitor on a phone, someone who uses it every day, an accessibility expert, a security reviewer looking for leaked keys and personal data, and [an expert in this field: for a classroom quiz, a primary school teacher]. Have each one actually use it, then give me one combined list ranked by how much it matters. Don't fix anything until I've picked.

You're done when you've read the panel's list and picked which findings to fix.

The process · 6

Put it in front of people

Two kinds of testing. Real people, including you living with it every day. And automated checks that Claude writes, so that fixing one thing doesn't quietly break another.

When someone gets confused, that's your next ask. Write down what happened and give it to Claude.

I tested it with [who]. Here's what happened: [what they tried, where they got stuck, what they said]. Suggest the smallest changes that would fix this, as a list for me to pick from. Don't build anything yet.

Add automated tests that open the app in a real browser and check the main things still work: [list the core actions]. Run them on each pull request, and tell me in plain words if one fails. Keep the free minutes in mind: run only when the app's files change (not notes or pictures), cancel a run when a newer push replaces it, reuse installed packages between runs, and keep a run under two minutes. Tell me what a run costs in minutes.

After a test: what surprised you about watching someone else use it?

Then go around again

Back to refining, or back to the interview if what you learned changes what the app is.

You're done when someone else has used it, and you turned what you saw into asks.

The process · 7

It's live the whole time

With GitHub and Netlify connected, there's no launch day. Every change you merge (accept) is online a few minutes later. At that point you just send people the link.

Before you send the link: go through Before anything goes public.

After that it's the same loop, just slower. When something breaks, describe what you saw. Claude can read the check logs on GitHub itself; for a Netlify problem, paste in what Netlify shows you. If you want other people to add to it, they can: a public repo lets anyone suggest a change, and you still decide what gets merged.

Something's broken: [what you did, what you expected, what happened instead, on which device]. Find the cause, fix it, and add a test so it can't come back.

The last change made [what got worse]. Undo it, open a pull request for the undo, and tell me what it changed back.

You're done when you've been through the safety list and sent someone the link.

You can stop here. You've been all the way around the loop.

Pitfalls

What would you do?

When Claude interviewed me for this guide, it asked where people go wrong most. My answer:

Claude is fast enough that it's tempting to say "build it" and take whatever comes back. You'll get an app, but Claude made most of the choices. Messing around is fine. For something you mean to keep, get interviewed first.

Six situations you'll run into. Pick what you'd do.

Signs you're out of your depth

Checklist

The card

The whole guide on one card. Take a screenshot, or print it.

Print the card and checklist

Your checklist

Ticks are saved on this device only. On a shared computer, print it instead.

Clear my ticks

Look back

What did you keep asking for? What would you make next? Claude can help you see it:

Look back at this project's history and tell me, in plain words, what I kept asking for and what I learned. Suggest two or three rules for CLAUDE.md based on it.