Map
Claude Code for the Rest of Us
The Ultimate Playbook for Non-Coding Tasks and Workflows
by Krishna Veera Vanamali Y
Map Starter Kit
ESC
Start typing to search across all chapters
18 min read

PART 6: SHIP A REAL AI APP

Chapter 23: Ship a Real AI App

Everything before this chapter taught you individual moves. This chapter is a full game.

In one sitting, without writing a single line of code, you can build an AI chatbot with its own design, a live URL you can send to anyone, a working brain, and a database that remembers every conversation. Then give it an announcement banner you can update from one sentence, make it findable on Google, and wire in analytics so you know when people actually visit. This chapter walks that build step by step, with prompts you can paste as they are.

It is also a tour of the whole book in disguise. By the end you will have used CLAUDE.md, plan mode, two design skills, vision, rewind, git, an MCP, a custom skill of your own, and a handful of tools this book has not covered yet. There is a table at the end mapping every move back to the chapter that teaches it deeply. If you have been reading this book in order, this is where it all compounds. If you skipped straight here, that works too. Budget two to three hours at a relaxed pace.

The one rule

Describe what you want in plain words. Never describe how to build it. That part is Claude’s job.

You will notice every prompt in this chapter is specific about the outcome (“a box at the bottom where I type”) and completely silent about technology. That is deliberate. The moment you start guessing at the how (frameworks, file names, technical approaches) you take responsibility for decisions you are not equipped to make, and you get worse results. Stay in your lane, which is the what, and this whole thing feels like a conversation instead of a coding session. Chapter 4 covers why this works; this chapter is the proof.

What you need before you start

Fifteen minutes of account setup, all free to open:

  1. A GitHub account (github.com). This is where your app’s code lives.
  2. A Vercel account (vercel.com, sign up with “Continue with GitHub”). This puts your app on the internet.
  3. A Google account, for Firebase, the database that gives your app memory.
  4. An API key from an AI provider (Anthropic, OpenAI, or Google). You will set this up in Step 8, not now.
  5. Claude Code installed and signed in.

Make a new folder for the app. Name it something simple without spaces; my-ai-app is perfect. Spaces in folder names trip up some tools later.

Open your terminal, go into the folder, type claude.

Step 1: Set the working relationship

Paste this first. It establishes how you and Claude work together, and gives you a diary of everything that happens, which you will love reading later.

As a Claude prompt:

Before we start: create a CLAUDE.md for this project that remembers three
things about working with me.
1. I'm not a developer. Explain what you're doing in one or two plain
   sentences as you go, no jargon.
2. You make the technical decisions. I describe what I want in plain
   language; you choose how to build it, and keep everything as simple as
   possible. If something I ask is ambiguous, pick the simplest sensible
   option instead of asking me to choose.
3. Keep a diary: after every task, append an entry to BUILD-LOG.md with
   the time, what I asked, what you did, and any problems. Never skip it.
Set that up and confirm.

That CLAUDE.md file is Claude’s long-term memory for this folder (Chapter 3, in miniature). Every session you open here starts already knowing the rules. The BUILD-LOG is for you: at the end of the day it reads like a project journal someone else kept while you talked.

Step 2: Make Claude interview you first

Here is a habit that separates people who ship things they love from people who ship things that are fine: before the first build, make Claude question you.

You have an app idea in your head right now. It is fuzzier than you think. The cheapest mistakes in any build are the ones caught before anything is built, and the fastest way to catch them is an interview. Three ways to run one; pick whichever matches your mood:

The built-in way: plan mode. Press Shift+Tab until you are in plan mode, then describe your app. In plan mode Claude can think, research, and ask, but cannot touch anything. It will come back with a plan and its open questions. Answer them, approve the plan, and only then does building start. (Plan mode is covered properly in Chapter 4.)

The no-setup way: just ask for it.

As a Claude prompt:

Before you build anything: interview me about this app, one question at a
time, until you're confident you understand exactly what I want. Push back
on anything vague. Then play back a short summary for my sign-off.

The full treatment: a grilling skill. Matt Pocock, a well-known developer educator, publishes a free skill called /grill-me whose whole job is to interrogate you about a plan until every loose end is resolved. It is relentless in the best way. Install it once and it is available everywhere:

As Claude Code commands:

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock

Then type /grill-me and describe your app. Expect to be asked questions you had not thought about. That is the point.

Whichever flavor you pick, the interview will surface decisions you did not know you had to make: does the app need a login (this one does not), how often the banner will change, warm or corporate in tone. Five minutes of questions, and every answer shapes what comes next.

Step 3: Prototype three looks before you commit

Here is one of the best tricks in all of front-end work, and it costs one prompt. Never accept the first design; generate rivals for it.

As a Claude prompt:

Before we build the real thing, show me three different visual directions
for this chat app as three separate HTML files. Same layout in each
(banner on top, conversation in the middle, type-and-send at the bottom),
three genuinely different personalities. Open all three in my browser
side by side when done.

Now you are not evaluating “is this good?” You are evaluating “which of these is mine?” That is a much easier question, and the answer teaches Claude your taste faster than any description could. Pick the winner, tell Claude why in one sentence (“the second one: calmer, better fonts”), and have it delete the others. Chapter 5 goes deep on this compare-then-commit pattern; this is it in one move.

Step 4: The first real build

As a Claude prompt:

Build the real chat app now, in the visual direction we picked. A slim
announcement banner at the very top that says "Welcome!", the conversation
in the middle, and a box at the bottom where I type my message and hit
Send. When I send a message it should appear in the conversation. Don't
make it reply yet; the AI brain comes later. Open it in the browser when
done.

A minute later there is a working page in your browser. Type something, watch it appear. Notice the app does not answer yet: that is deliberate. Building the body before the brain keeps every step small enough to verify, and small verifiable steps are how non-developers stay in control of a build.

Along the way Claude will ask permission before creating files or running commands. That is the safety system from Chapter 1. Read the first few so you know what saying yes means, then relax.

Step 5: The design pass: one skill decorates, another audits

Your app works. Now make it designed, using two skills that play different positions.

First, the generator. Anthropic publishes an official design skill that dramatically raises the visual ceiling. Install it from the official marketplace (Chapter 5 has the full walkthrough), then:

As a Claude prompt:

Use the frontend-design skill to redesign my page. Keep my layout and the
banner. Warmer, more personality, still clean and light.

While you iterate, two power moves from earlier chapters earn their keep. Screenshot any website whose look you love and paste it straight into the terminal (Ctrl+V on Mac, Alt+V on Windows), then: “I like the feel of this. Take my page in this direction, but keep my layout.” Claude can see images (Chapter 15). And if you liked an earlier version better, double-tap Escape and rewind to it (Chapter 13). You cannot break anything permanently.

Then, the auditor. A generator flatters you; an auditor tells you the truth. This is where a second design skill earns its place: Impeccable, a free skill pack by Paul Bakaus built around critiquing and polishing rather than generating. Install it by asking Claude:

As a Claude prompt:

Install the Impeccable design skill for me: run "npx impeccable install"
in this project, then initialize it. Then run its critique on my page and
fix the real problems it finds.

Expect the audit to catch things you cannot see: body text contrast too low to read comfortably, a Send button that pretends to work when the box is empty. That is the difference between decorated and designed, and the two-skill pattern (generate with one, audit with another) is worth stealing for every visual project you ever do.

Step 6: Put it on the internet

A page on your laptop is a rehearsal. Hosting your code online is the show. This is the step with the biggest payoff-to-effort ratio in the whole build.

As a Claude prompt:

Let's put this on the internet. I have GitHub and Vercel accounts. Get the
code ready to go live, keep it private, and tell me what you're doing as
you go.

Claude sets up the code history (git) and creates a private GitHub repository, narrating in plain English as it goes. Then the one part you do by hand: go to vercel.com → Add New Project → import your repository → Deploy. Two minutes later you have a live URL. Open it on your phone. Send it to someone. It is a strange and excellent feeling.

From here on, one magic rule applies: every change pushed to GitHub goes live automatically in about a minute. So the sentence you will type most for the rest of this chapter is:

As a Claude prompt:

Save my changes and put them live.

Claude commits, pushes, and Vercel does the rest. Describe, build, put it live. That loop is the whole game.

Step 7: Connect Claude to your hosting

Right now Claude pushes changes and hopes the deploy worked. Give it eyes. This is your first MCP, a live connection between Claude and an outside service (Chapter 2 explains the concept; Appendix B catalogs the good ones).

In your terminal:

claude mcp add --transport http vercel https://mcp.vercel.com

Then type /mcp inside Claude Code and log in to Vercel through the browser window that opens. From now on Claude can check its own deployments, and when a deploy fails, it reads the error itself instead of asking you to go copy it from a dashboard.

Step 8: Give it a brain

Time for the AI. Your app needs an API key to access an LLM. Get one from whichever provider you prefer:

Create the key and copy it. Now, two ways to hand it to your app, in decreasing order of safety.

The safest way: the key never touches the chat.

As a Claude prompt:

Set up an empty .env file for my API key: put the variable name in with a
blank value, tell me exactly where the file is, and never read that file
yourself. I'll paste the key in by hand.

Claude creates the file with the format already in place (a line like GEMINI_API_KEY= waiting for a value). Open it in any text editor and paste your key after the equals sign. The “never read that file yourself” part matters: if Claude opens the file later to check it, the key lands in the conversation history anyway, which defeats the purpose. Then:

As a Claude prompt:

My API key is in the .env file. Wire up the chat so the bot replies to my
messages using my provider's cheapest fast model. Keep the key out of
anything public, and keep everything simple.

The key goes straight from the provider’s website to a file on your machine, and never enters the conversation at all.

The convenient way: paste it in the chat. Paste the same prompt with the key included (“Here’s my API key: …”). One honest caveat, which Claude itself will often point out: anything you paste into the chat is sent to Anthropic for processing and stays in your conversation history. It is not the safest.

Either way, watch what Claude does with “keep it out of anything public,” because this is the best security lesson in the book and nobody lectures you through it. Two things happen. The .env file gets fenced off so it can never be uploaded to GitHub. And the actual AI call moves out of your page into a separate small file in your project that runs behind the scenes instead of in the visitor’s browser: on your own machine while you test locally, and on Vercel’s computers once you push it live. Wherever it runs, the visitor never sees the key. You said safe; the model owned the how.

One manual step: the live site cannot read the .env file sitting on your laptop, so the key needs a second home for the live version. In Vercel: your project → Settings → Environment Variables → add the variable name Claude tells you, with your key as the value. That is what the behind-the-scenes file reads once it is running on Vercel’s computers. Then “save my changes and put them live”, open your live URL, and say hello.

It answers. Take a second with that. There is an AI on the internet, and you made it.

Key hygiene, if you pasted the key in chat: once the app is live, go back to your provider’s console, delete that key, and create a fresh one. Update it in Vercel’s Environment Variables and in your local .env file. The old key sitting in your chat history is now useless to anyone.

Step 9: Give it a database

Refresh the page. The conversation is gone. Your app has a brain but no memory, and the fix is a database, which sounds heavier than it is. A database is just a notebook that lives on the internet, where your app writes things down so they survive the page closing.

We will use Firebase, Google’s free one. The console clicks: go to console.firebase.google.com → Create project → open Firestore Database → Create database → start in test mode. Then Project settings → register a Web app → copy the config block it shows you.

Lost anywhere in that console? Use the rescue move: screenshot the screen, paste it to Claude, and say “I don’t know what I’m doing. Tell me exactly what to click next.” It will navigate you turn by turn. This works in every confusing dashboard you will ever meet, not just this one.

Prefer to skip the console entirely? Firebase has a command-line tool, the Firebase CLI, and Claude can drive it. Ask: “Set up Firebase for this app using the Firebase CLI: install it, log me in, create the project and the database, and give me the config.” You approve a browser login once, and Claude does the rest from the terminal. (Firebase also ships an MCP if you would rather give Claude a standing connection, like the Vercel one from Step 7.)

As a Claude prompt:

I want the app to remember conversations even after I close the page. I've
set up Firebase. Here's the config: <PASTE CONFIG>. Keep it simple.

Put it live, chat on the live site, refresh. Still there. Each visitor’s browser gets its own private thread, so your friends will not see your chats.

Step 10: Let Claude check its own work

Before you show anyone, run the inspection:

As a Claude prompt:

Take a look at my live site: open it, check for errors and anything
that's off on both desktop and phone sizes, fix what you find, and put it
live.

Expect it to find things you would never notice: an error quietly logged in the browser console, a missing browser-tab icon, a layout that squeezes badly on phones. Build, deploy, verify. Claude can close its own loop, and letting it do so should become a reflex at the end of every build session.

Step 11: The operator’s skill: /headline

That announcement banner from Step 4 is about to become the most useful part of your app. You will change it often: announcements, launches, offers. A thing you do often deserves a shortcut, and in Claude Code, shortcuts are skills you write yourself (Chapters 14 and 21).

As a Claude prompt:

Create a /headline skill for this project. When I run it with something
like "/headline 50% off this week", rewrite the announcement banner at the
top of my page to match my words, save everything, put it live, and
confirm the deploy worked.

Now try it: /headline We just launched, come say hi. Sixty seconds later your live site has new news. One sentence, live. You just automated your own routine, and that pattern (notice a repeated routine, turn it into a skill) is the single most useful habit in this whole book.

One boundary worth learning while you are here: skills are for routines; one-off tasks stay prompts. A launch post for LinkedIn is a one-off, so just ask for it directly: “Draft a short LinkedIn post announcing what I built today, in my voice, with the link.” If you catch yourself doing something for the third time, that is a skill. Once, it is a prompt.

Step 12: Get it found

Your app exists, but the internet does not know it yet. Two fixes: make the app introduce itself properly, and tell Google it exists. Both are one honest prompt and a few clicks.

First, the introduction. Right now, share your link on WhatsApp or LinkedIn and the preview is probably a bare URL with no image, because the page has no title, description, or preview card set. This basic self-description is what people call SEO hygiene, and Claude can do the entire pass in one go:

As a Claude prompt:

Do a full SEO pass on my app. Give it a proper page title and a one-line
description, a preview image and card so it looks good when the link is
shared on WhatsApp and LinkedIn, and a browser-tab icon. Then put it live
and show me what you changed.

Test it: paste your URL into WhatsApp and watch the preview card appear. That alone makes the link twice as sendable.

Second, Google. Go to search.google.com/search-console, add your site’s URL as a property, and when it asks you to verify ownership, choose the HTML tag method. Paste the tag to Claude: “Add this verification tag to my site and put it live.” Back in Search Console, click Verify. Then paste your URL into the inspection bar at the top and hit Request Indexing: that is you raising your hand and telling Google’s crawler to come look. Indexing takes days, not minutes, so do this once and forget it.

One more connector worth knowing: there is a Search Console MCP. Connect it and Claude can check your indexing status and search performance itself, without you opening the dashboard.

Step 13: Know your visitors

The last piece turns your app from a thing you made into a thing you run: analytics. After you share that LinkedIn post, this is how you find out what happened.

The workflow here is exactly as lazy as it sounds: get the tracking snippet from the analytics provider, paste it to Claude, and say “add this to my site.” That is the entire technique. Two good places to get that snippet:

The zero-effort option: Vercel’s built-in analytics. Your host already offers it. In the Vercel dashboard: your project → Analytics tab → Enable. Then:

As a Claude prompt:

Enable Vercel Web Analytics on my site by adding its plain-HTML tracking
script, then put it live.

Visitors and page views start appearing in that same Analytics tab. No account to create, nothing to configure.

The fuller option: PostHog. A popular analytics product that shows not just visits but what people actually did: clicks, sessions, journeys. Sign up at posthog.com, and during onboarding it hands you an HTML snippet pre-filled with your project key. Copy the whole block, then:

As a Claude prompt:

Add this analytics snippet to my site so it loads on every page, then put
it live: <PASTE SNIPPET>

Either way, give it a day, then look. There is a specific small thrill in the first stranger showing up in your analytics: someone you did not send the link to found your thing. That is when it stops feeling like a project and starts feeling like a product.

When something breaks

Three moves, in escalating order of power.

Show it. Screenshot the problem, paste it to Claude, and say what you expected to happen instead. That one sentence fixes most things.

Let it read the logs. You connected the Vercel MCP in Step 7. Use it: “Something is broken on the live site. Check the deployment and error logs on Vercel and tell me what went wrong, then fix it.” No copying error text out of dashboards; Claude reads the source directly.

Let it query the service. The same idea extends to everything your app touches. With the Firebase CLI or MCP connected, Claude can look inside the database itself and see what is actually stored, not what you think is stored. The general principle: when a connected service misbehaves, do not relay the error to Claude secondhand. Give Claude the connection and let it investigate firsthand.

Everything you just used

This is why I called this chapter a tour of the book in disguise. Every move above, mapped:

The move What it does in this build Where it’s taught
CLAUDE.md working agreement Sets the rules once; every session starts knowing them Chapter 3
Specific-but-simple prompting Every prompt here: exact outcome, zero tech-speak Chapter 4
Plan mode / interview-me / /grill-me Sharpens the idea before anything is built Chapter 4
Three prototypes before committing Choose a design by comparison, not guesswork Chapter 5
frontend-design skill The generator: raises the visual ceiling Chapter 5, Appendix A
Impeccable skill The auditor: catches what generators miss New here
Screenshot paste (vision) Show Claude the look you want instead of describing it Chapter 15
Rewind (double-Escape) Walk back a design direction risk-free Chapter 13
Git + GitHub + Vercel Private code history plus the push-to-live loop Chapter 5
Vercel MCP Claude checks its own deployments and reads its own logs Chapter 2, Appendix B
Custom skill: /headline Banner updates from one sentence Chapters 14 and 21
Secret-keeping (.env) The API key never touches public code New here
Firebase database (console or CLI) Conversations survive the refresh New here
Browser self-verification Claude inspects the live site and fixes what it finds Chapters 2 and 8
SEO pass + Search Console Link previews plus a formal invitation to Google New here
Analytics snippet Know when strangers arrive Chapter 5, and here
Debugging through connectors Claude queries the services for errors firsthand New here

Read that table again and notice what is missing: code. Seventeen moves, one shipped product, zero lines written by you.

The fine print

← Chapter 22: Running It WellChapter 24: Claude on Autopilot →