I'm building on:

One idea.
One weekend.
Browser in, terminal out.

By Sunday night you'll have a small, working app that you designed, scoped, and built — with Claude doing the typing and you doing the thinking. Along the way you'll see how developers actually work: plan, mock, build, test, repeat.

Two surfaces, one project. You'll plan and design in the Claude web chat (the part you already know), then build and test in Claude Code (the part this guide teaches you). Each step below is badged with where it happens.

BROWSER claude.ai chat TERMINAL Claude Code 1 Project 2 Define 3 Mockup 4 Scope 5 Install 6 Git 7 Handoff 8 Build 9 Test ✓ Ship v1
Browser — claude.ai, where you plan Terminal — Claude Code, where you build

The weave is the point. Developers move between "thinking space" and "building space" constantly. This weekend, so will you.

BEFORE YOU START 5 minutes

What you need, and what this actually is

Read this first — you're putting an AI on your computer

Claude Code is not a website. It's software you'll install that can read files, write files, and run commands on your machine — that's exactly what makes it useful, and exactly why it deserves respect. Every action goes through a permission prompt that you approve, but approving means real changes happen to your real computer, and an AI can be confidently wrong.

Only proceed if you understand that and still want to. If you do, the discipline this guide teaches — read the prompts, review the changes, commit your save points — is how you stay in control the entire time. The discipline is the product; the app is the souvenir.

This guide assumes exactly two things:

  • A paid personal Claude account (Pro or higher) — Claude Code isn't available on the free plan.
  • A computer you're allowed to install software on. Your personal machine is ideal — this is a personal project on your personal account.

That's the whole list — a stock operating system with no developer tools is the assumed starting point. Everything else (Git, Claude Code, even Python if your project ends up wanting it) gets installed during the guide, one approved step at a time.

You do not need to know how to code — and if you already do, you'll simply move faster through the middle. What you need is to know what you want, be willing to read what Claude shows you, and be willing to say "no, not like that" — which, if you've ever worked a support queue, you're overqualified for.

Dev mindset № 1 — Why we're doing this

The goal isn't to turn you into a developer by Monday. It's to give you the developer's-eye view: how an idea becomes a spec, a spec becomes a mockup, a mockup becomes code, and code becomes a thing that breaks in interesting ways. Once you've lived that loop once, you'll start noticing it everywhere software gets made — and what you do with that is up to you.

Ground rules — read these once, they apply all weekend

Keep it personal. No work data, no work credentials, nothing that belongs to your employer or their clients goes into your personal Claude account or this project. Build something for you.

No secrets in chat or code. Never paste passwords, API keys, or license keys into a chat or a code file. If your app ever needs one, we'll handle it properly (step 7 covers this).

Read before you approve. Claude Code asks permission before it runs commands or changes files. Those prompts are not clickwrap — actually read them. It takes three seconds and it's the entire safety model.

STEP 1 Browser

Create a Project in claude.ai

A Project in claude.ai is a workspace with memory: it holds custom instructions and files that every chat inside it can see. Instead of re-explaining your app idea in every conversation, you write it down once and every planning chat starts already briefed.

  1. Go to claude.ai and sign in to your personal account.
  2. In the left sidebar, click Projects, then New project.
  3. Name it after your app idea — even a working title like shift-swap-tracker is fine. You can rename later.
  4. Open the project's instructions (look for "Set project instructions" or similar) and paste in the starter below, filling in the blanks.

Roughly what you'll see — the exact layout shifts as claude.ai updates, but Projects lives in the left sidebar.

📷 Illustrations like this one approximate the real UI, which shifts as claude.ai updates — trust the labels over the pixels.
Paste into your project instructions

I'm building an app this weekend. My hands-on coding experience: none / a little / decent, just new to this workflow. Talk to me like a smart colleague, not a beginner tutorial. My idea: one sentence describing your app. My platform: Windows / Mac / Linux. Keep recommendations simple — fewest moving parts that does the job. When I ask for plans, give me something concrete I can react to rather than lists of options.

Stuck on an idea?

The best weekend apps solve a small annoyance you personally have. A tip calculator is a tutorial; a tracker for whose turn it is to buy coffee in your household is an app. Good shapes: a tracker, a calculator with your rules, a randomizer/picker, a simple dashboard for something you check often, a converter, a checklist that resets. Small and yours beats big and generic.

STEP 2 Browser

Define what you're building — goals first, features second

Developers don't start with features; they start with what the thing is for. Open a new chat inside your project and work through this with Claude. Be honest about what matters and what doesn't — half the value of this step is discovering that your idea has a smaller, better core than you thought.

First chat in your project

Help me turn my idea into a one-page plan. Ask me one question at a time until you can fill this out:

1. The job: what problem does this solve, for whom, in one sentence?
2. The moment: when do I open this app? What am I holding / doing / annoyed by?
3. Must do: the 2–3 things it absolutely has to do for v1.
4. Won't do (yet): tempting features we're explicitly cutting from v1.
5. Done looks like: how I'll know v1 works.

Then write the finished plan back to me as a short document.

Dev mindset № 2 — Scope is a decision, not a discovery

That "won't do (yet)" list is the most professional artifact you'll produce all weekend. Every shipped product is mostly a list of things it deliberately doesn't do. Somewhere behind every app you've ever used sits a list exactly like yours — and a v1 that had to ship.

When the plan feels right, ask Claude to save it as a file or artifact named PLAN.md and keep it handy — you'll feed it to Claude Code in step 7.

STEP 3 Browser

Get a mockup you can poke at

Before any real building, make Claude show you the app. In the web chat, Claude can build a live, clickable mockup as an artifact — a working preview that renders right next to the conversation. This is where "I'll know it when I see it" becomes a legitimate design method.

Ask for the mockup

Based on PLAN.md, build me an interactive mockup of this app as an artifact. Focus on layout and flow, not real functionality — fake data is fine. Make it look clean and modern. I'll give you feedback and we'll iterate.

The feedback loop in action. Notice the tone: specific, blunt, reactive. That's not rude — that's useful.

Show, don't describe — upload images

Claude reads images, and it's often the fastest way to get an idea out of your head. Drag pictures straight into the chat: a screenshot of an app whose layout you like ("make it feel like this"), a photo of a napkin or whiteboard sketch ("this is roughly what I mean"), or a screenshot of the mockup itself with the problem circled in any paint tool. One marked-up image routinely replaces three rounds of "no, the other button." Screenshot shortcut on your machine: Win + Shift + S, then paste or drag the capture in.⌘ + Shift + 4 saves a capture to your desktop — drag it in.usually PrtSc or your desktop's screenshot tool — then drag the file in.

Iterate until the mockup matches the picture in your head. Three to six rounds is normal. Then ask Claude to describe the final mockup in words — layout, screens, colors, behaviors — and save that as MOCKUP.md alongside your plan.

Dev mindset № 3 — Feedback is a skill, and specificity is the whole skill

"I don't like it" makes an AI (or a developer) guess. "The button is too small and I don't know what 'sync' means" gets fixed in one round. You're practicing the exact skill that makes bug reports valuable: what I did, what I expected, what actually happened.

STEP 4 Browser

Pick the shape and language — the low-lift menu

Here's the honest conversation a senior dev would have with you. Almost every good weekend app fits one of three shapes, and the shape picks the language for you:

ShapeLanguageBest forHonest limitations
Single-file web page HTML / CSS / JavaScript Trackers, calculators, pickers, dashboards, checklists — anything with buttons and a screen. The default recommendation for a weekend app. Runs in your browser only. Data lives on that one machine, and clearing browser data can wipe it. "Sharing" means sending someone the file. No logins, no syncing between devices.
Small script / command-line tool Python Renaming or sorting files, crunching a spreadsheet, generating reports, automating a chore — work that processes stuff rather than displays stuff. No pretty interface — you run it and read text output. Anyone else who wants to use it needs Python installed. Great engine, no dashboard.
Real web app Python or JavaScript + a server + a database Anything with user accounts, data shared between people, or access from your phone and laptop. Not this weekend. Servers, databases, hosting, and authentication each add real complexity — and auth done casually is a security hole, not a feature. This is the v2/v3 path, and your v1 will teach you what v2 should even be.

Don't let "needs Python installed" scare you off row two — remember the starting assumption: stock OS, no dev tools. When a shape needs a tool you don't have, Claude Code will install it with your approval when the moment comes. Pick the shape that fits the idea, not the one that fits what's already on your machine.

If your ambitions point at row three, that's great — build row one first anyway. A single-file version of your idea is the fastest way to find out what the real version needs, and nothing about it is wasted: the layout, the logic, and the lessons all carry forward.

Lock it in

Given PLAN.md and MOCKUP.md, recommend the simplest shape for v1 — single-file web page or Python script — and tell me plainly what that choice can't do, so I'm not surprised later. Then update PLAN.md with the decision.

Dev mindset № 4 — Simple isn't the compromise, it's the strategy

Every dependency, framework, and server you add is something that can break at 2 a.m. When developers seem hesitant about a shiny addition, they're usually just counting moving parts. Fewest moving parts that does the job — that's not timidity, that's the craft.

STEP 5 Terminal

Install Claude Code

Time to open the terminal. Claude Code is the same Claude you've been planning with, but living on your machine — it can read files, write code, and run commands, always asking your permission first. The install is one command. Make sure the OS picker at the top of this page matches your machine.

5a. Install Git for Windows first

Git is the version-control tool developers use to snapshot their work (step 6 explains why you'll love it). On Windows, installing it first also gives Claude Code a better shell to work in.

Open PowerShell (press Win, type powershell, hit Enter — no administrator mode needed) and run:

PS> winget install --id Git.Git -e

If winget isn't available on your machine, download the installer from git-scm.com and click through with the defaults.

Close PowerShell and open a fresh one (new installs aren't visible to already-open windows), then confirm:

PS> git --version
git version 2.5x.x.windows.1

5b. Install Claude Code

PS> irm https://claude.ai/install.ps1 | iex

One quirk worth knowing: if you see 'irm' is not recognized, you're in the old Command Prompt, not PowerShell — the prompt should start with PS. Open PowerShell and try again.

5a. Open Terminal

Press ⌘ + Space, type Terminal, hit Enter. That black-and-white window is where the rest of the weekend happens. It's less scary than it looks: you type a command, press Enter, read the result.

5b. Install Claude Code

$ curl -fsSL https://claude.ai/install.sh | bash

Git note: macOS ships with Git. If it's somehow missing, running git --version pops a dialog offering to install Apple's Command Line Tools — accept it and you're set.

5a. Make sure Git is installed

You're on Linux, so you've probably met a terminal before. Check for Git and install it if needed:

$ git --version
# If not found — Debian/Ubuntu (curl comes along; the installer needs it):
$ sudo apt install git curl
# Fedora/RHEL:
$ sudo dnf install git curl

5b. Install Claude Code

$ curl -fsSL https://claude.ai/install.sh | bash

If claude isn't found afterward, close and reopen the terminal — the installer adds ~/.local/bin to your PATH, and a fresh shell picks that up.

5c. Sign in and verify

Confirm the install, then launch it and log in with your paid personal Claude account — a browser window opens for sign-in, then you're back in the terminal:

> claude --version
2.x.x (Claude Code)
> claude

Success looks like this: a welcome banner, the current model, your working directory, and a prompt waiting for plain English.

If anything fights you

The official quickstart at code.claude.com/docs/en/quickstart has current install commands and a troubleshooting section. And you can always ask the browser Claude — paste the exact error message in, it's genuinely good at unsticking installs.

STEP 6 Terminal

Let Claude Code set up your project folder — and meet Git

Here's your first taste of the magic: you don't need to memorize commands, because you can just tell Claude what you want. With Claude Code running (type claude if it isn't), say:

Say to Claude Code

Create a new folder for my app at a path you like, e.g. Documents/projects/my-first-app, initialize a git repository in it, and add a sensible .gitignore for a small web / Python project. Then tell me what you did and why each piece matters.

Watch what happens next, because it's the whole trust model in one moment: Claude proposes each command and waits for your approval. Read each one. You'll see something like mkdir (make directory), git init (start version control), and a file being created. Approve them one at a time.

The permission prompt. On day one, answer these one at a time — "don't ask again" is a convenience you earn later, not a default.

When it's done, exit Claude Code (type /exit), move into your new folder, and relaunch — Claude Code works best when it's started inside the project it's working on:

> cd (the path you chose, e.g.) ~/Documents/projects/my-first-app
> claude

On Windows that path looks like cd ~\Documents\projects\my-first-app — PowerShell understands ~ as your home folder.

Dev mindset № 5 — Git is a save system, and saves make you brave

Git snapshots your entire project every time you "commit." Think video-game save points: experiment wildly, and if it goes sideways, roll back to the last save. This is why developers can say "let's just try it" — they're never more than one commit away from safety. You'll commit after every working milestone this weekend, and each commit message is a one-line note to future-you about what changed.

STEP 7 Browser → Terminal

The handoff: scaffold the project properly

This is where the weave pays off. Your browser project holds the thinking — PLAN.md and MOCKUP.md. Now you hand that thinking to the builder.

  1. Browser: open your project chat and ask Claude to output the final PLAN.md and MOCKUP.md as complete documents you can copy.
  2. Terminal: in Claude Code (inside your project folder), say: "I'm going to paste my plan and mockup description. Save them as PLAN.md and MOCKUP.md." Then paste each one.
  3. Terminal: now the big ask — use the prompt below.
Say to Claude Code

Read PLAN.md and MOCKUP.md, then scaffold this project the simple, secure way:

1. Create a CLAUDE.md describing the project, my experience level (whatever you told the browser project — none / a little / decent), and our rules: simplest approach that works, no extra dependencies without asking me, explain changes in plain English.
2. Set up the minimal file structure for the shape we chose — no frameworks, no build tools unless truly necessary.
3. Confirm .gitignore covers anything sensitive, and never put secrets (passwords, API keys) in code — if we ever need one, use an environment file that git ignores, and tell me.
4. Build the first working version matching the mockup, with fake starter data where useful.
5. When it runs, make a git commit, and tell me exactly how to open and try it.

Claude will work through this in front of you — creating files, writing code, asking permission along the way. Approve, read the explanations, ask questions whenever a term is new. "What does this file do?" is always a fair question and it always gets a real answer.

What "secure scaffold" means at this scale

Secrets stay out of code and out of git. The .gitignore plus environment-file pattern isn't bureaucracy — it's the exact discipline that prevents the "credentials committed to a public repo" incidents you've seen in the news.

Fewer dependencies, smaller attack surface. Every library you pull in is code someone else wrote running on your machine. A single-file app with zero dependencies has a beautifully boring security story.

You review everything. Claude proposes, you approve. That's not a limitation of the tool — it's the safe pattern for using AI to build anything, this weekend and beyond.

Dev mindset № 6 — CLAUDE.md is a briefing document

That CLAUDE.md file gets read by Claude Code at the start of every session — it's how your project "remembers" its rules between sittings. Developers do the same with README files and team conventions: write the context down once so nobody (human or AI) has to rediscover it.

STEP 8 Terminal

Build in loops: run it, react, repeat

Claude will tell you how to open your app — for a web app, usually double-clicking an index.html in File Explorer or letting Claude open it for you;for a web app, usually double-clicking an index.html in Finder or letting Claude open it for you;for a web app, usually opening an index.html in your browser; for a Python tool, a one-line run command. Open it. Click around. It will be imperfect. That's not failure — that's the starting gun.

Now run the same loop you practiced on the mockup, but on the real thing:

  1. Try it like you'd actually use it, not like a demo.
  2. Tell Claude Code what's wrong, specifically: "When I click Add with an empty box, a blank row appears. It should do nothing and highlight the box instead." For anything visual — misaligned layout, wrong colors, overlapping text — take a screenshot and paste it straight into Claude Code with Ctrl+V (yes, Ctrl, not ⌘, for images in the terminal), or drag the image file into the terminal window. Claude sees exactly what you see, which beats describing a layout in words every single time.
  3. Approve the fix, try again.
  4. When something works and you like it: commit. Just say "commit this" — Claude handles the git commands and writes the message.
Don't go full vibe code

"Vibe coding" is the fashionable term for letting the AI generate whatever, approving everything unread, and shipping code nobody understands. It's a fun party trick and a terrible habit. A little vibe is fine — that's the fun part — but the line that keeps you the builder instead of the bystander is this: read the permission prompts, skim every change, ask "what does this do?" until you could explain it to someone else, and commit at every known-good point. Cross that line and you're no longer building the app; the app is happening to you. Everybody knows you never go full vibe code.

Prompts that keep the build healthy

"Before you change anything, tell me your plan in two sentences." — keeps you in the driver's seat on bigger changes.

"What's the simplest way to do this?" — the magic words whenever a suggestion sounds heavyweight.

"Explain what you just changed like I'm a colleague from another department." — free education with every edit.

"Roll back to the last commit." — the eject handle. Because you committed, you can always pull it.

Dev mindset № 7 — Iteration isn't the backup plan; it's the plan

No developer types out a finished app top to bottom. Everyone — junior, senior, AI — builds a rough version, sees what's wrong, and fixes it in passes. If you've ever wondered why software "isn't done yet," the honest answer is usually "it's mid-loop." You now know that from the inside.

STEP 9 Terminal

Test like a user, break it like a tester

Working-when-you're-careful and working are different things. Spend thirty minutes deliberately trying to break your own app — this is the most transferable skill in the whole guide:

  • Empty everything. Submit blank forms, click buttons with nothing selected.
  • Weird input. Paste a paragraph into a name field. Type letters where numbers go. Try -1, 0, and something absurdly large.
  • Do things out of order. Delete an item you're mid-edit on. Click the end of a flow before the start.
  • Close and reopen. Is your data still there? Should it be? (Remember the single-file limitation from step 4.)

For every break, file a bug report — to Claude Code, in the professional format:

The bug report format (memorize this one)

Steps: what I did, click by click.
Expected: what I thought would happen.
Actual: what actually happened, including any error text, word for word.
Screenshot: if the problem is visible, attach one — paste it into Claude Code or drag the file in. A picture of the broken state is evidence; a description of it is a memory.

When it survives your abuse: final commit, and you're done. You have shipped v1.

Dev mindset № 8 — A good report is half the fix

Steps / expected / actual is what turns a complaint into something fixable, and now you've felt why: a vague report sends the builder guessing through the same loop you just ran, blind. You've also felt why "small, working, and shipped" beats "ambitious and stuck." File both observations away — they'll come in handy in places this guide is too polite to name.

AFTER THE WEEKEND The road stays open

Where this goes next

Your project folder is now a living thing. Every future session is the same loop: open a terminal in the folder, run claude, and CLAUDE.md briefs it on everything. Some natural next moves, in rough order of ambition:

  • Polish v1.1 — the small annoyances you noticed but didn't fix. Ask Claude Code to keep a TODO.md so ideas don't evaporate between weekends.
  • Revisit the "won't do (yet)" list from step 2 — some items will have earned their way in; most, satisfyingly, still won't.
  • Make the data durable — if losing data on a browser reset bugs you, ask Claude about saving to a file. That's a real architecture conversation, and you're ready for it.
  • Put the code somewhere — a free GitHub account gives your project an offsite backup and a shareable home. Claude Code can walk you through connecting it in about ten minutes.
  • Graduate the shape — when your single-file app genuinely needs accounts or shared data, that's the v2 conversation from step 4. Start it in the browser project, where all your context still lives.

One last thing: you've now planned, scoped, mocked, built, tested, and shipped. That loop is what developers do all day, on every piece of software you've ever used. Welcome to the other side of the ticket.

REFERENCE SHELF Keep learning

Own every line that ships

The fastest way to grow past this weekend: never let code into your project that you couldn't describe in one sentence. "Explain this file like I'm smart but new" is a prompt that costs nothing and compounds forever — Claude never gets tired of answering it, and every answer makes the next one land better. When something Claude wrote sparks curiosity, chase it here:

  • Claude Code docs & quickstart — install, commands, permissions, and troubleshooting, straight from the source.
  • Claude help center — Projects, artifacts, and account questions for the browser side of the weave.
  • MDN Web Docs — the reference for HTML, CSS, and JavaScript. If your app took the single-file shape, everything in it is documented here.
  • The official Python tutorial — if your project took the Python shape, this is the canonical on-ramp.
  • Pro Git — a free book; chapters 1–3 demystify every git command Claude ran on your behalf.
  • GitHub docs — for when your project is ready for an offsite home and a shareable URL.

None of this is homework. It's a shelf — pull something down when curiosity strikes. After this weekend, it will.