如何零基础使用 Claude 构建你的第一个应用（完整教程）

I want to be very clear about something before we start.

Save this :)

I am not a developer. I have never been a developer. I do not have a computer science degree. I did not take a single coding bootcamp. I cannot read most code and tell you what it does.

But last weekend I shipped a working web application to the internet. Real users signed up. Real data was stored. Real features worked.

I built the entire thing with Claude Code in two days. And I am going to tell you the truth about what that experience was actually like. Not the curated version. The messy, frustrating, breakthrough-filled reality.

Because every "I built an app with AI" story online makes it sound effortless. It is not effortless. But it is very, very possible.

Saturday Morning: The Idea

I wanted to build a simple tool. A content calendar that lets you plan your posts across platforms, drag them between days, and mark them as published. Nothing revolutionary. But something I actually needed for my own workflow.

I opened Claude Code in my terminal for the first time at 9am on Saturday.

By 9:15am I had already made my first mistake.

Mistake #1: Starting Without a Plan

My very first prompt to Claude Code was:

Build me a content calendar app

Claude generated a bunch of files. Something appeared on the screen. It looked like a content calendar designed by someone who had never seen a calendar.

This is where 90% of people give up. They type a vague prompt, get a vague result, and conclude that vibe coding does not work.

The problem was not Claude. The problem was me. I had given it nothing to work with.

What I should have done:

I should have started in Plan Mode. Press Shift + Tab in Claude Code to switch from Act Mode to Plan Mode. In Plan Mode, Claude thinks before building. It asks questions. It maps out the architecture. It shows you what it plans to create.

I went back and did it properly:

I want to build a content calendar web app. Before writing any code, let's plan this.

The app needs:

• A weekly view with 7 columns (Monday through Sunday)
• The ability to add posts with a title, platform (Twitter, LinkedIn, Instagram), and status (draft, scheduled, published)
• Drag and drop to move posts between days
• A simple, clean design using Tailwind CSS
• Data stored in a local database so it persists between sessions

What tech stack should we use? What's the folder structure? Walk me through the architecture before building anything.

Claude came back with a detailed plan. Next.js for the framework. SQLite for the database. Tailwind for styling. A clean folder structure laid out file by file.

Lesson learned: Always start in Plan Mode. Always describe what you want in detail. The 5 minutes you spend planning saves you 2 hours of rebuilding.

Mistake #2: Trying to Build Everything at Once

After planning, I got excited. I told Claude to build the whole thing in one go.

The result was a mess. Some features worked. Others were half-implemented. The drag and drop was broken. The database was not saving correctly. I had no idea where to start fixing it.

What I should have done:

Build one feature at a time. This is the golden rule of vibe coding.

I started over and followed this order:

Session 1: Just the basic page layout. Seven columns. No features. Session 2: Add the ability to create a post (just a simple form). Session 3: Display saved posts in the correct day column. Session 4: Add drag and drop functionality. Session 5: Add the status feature (draft/scheduled/published). Session 6: Make it look good.

Each feature got its own conversation. Fresh context. Clear task. Clean result.

When I built one feature at a time, each one worked perfectly. When I tried to build everything at once, nothing worked.

Lesson learned: One conversation per feature. Never mix multiple features in the same Claude Code session.

Mistake #3: Not Creating a CLAUDE.md File

By Saturday afternoon I had a working basic layout and I was excited. But I kept running into the same problems:

Claude kept adding unnecessary complexity. It would create elaborate error handling systems when I just wanted a simple try-catch. It would add animation libraries when I just wanted a clean transition. It would restructure my entire folder system when I asked for one small change.

I was correcting the same things over and over.

Then I remembered reading about CLAUDE.md.

I created a file in my project root:

CLAUDE.md

Project Rules

• This is a simple content calendar. Keep everything minimal.
• Use Next.js 14 with the App Router
• Use Tailwind CSS for all styling. No other CSS frameworks.
• Use SQLite with Prisma ORM for the database
• Keep it simple. No unnecessary abstractions or design patterns.
• When I say "make it look good" I mean: clean spacing, readable fonts, subtle hover effects, rounded corners
• Never add new dependencies without asking me first
• Ask before refactoring any existing code

Code Style

• Simple, readable code. A beginner should be able to understand it.
• Clear variable names. No abbreviations.
• Comments only for non-obvious logic

After creating this file, the experience changed dramatically. Claude stopped over-engineering. It stopped adding random libraries. It stopped restructuring things I had not asked it to touch.

Every time Claude did something I did not want, I added a new rule to CLAUDE.md. By Sunday night this file had 30+ rules and Claude was following all of them perfectly.

Lesson learned: Create CLAUDE.md on day one. Update it constantly. It is the single most powerful tool in Claude Code.

Mistake #4: Not Using Screenshots

Saturday evening. The app works functionally but looks ugly. I typed this:

Make the design more modern and professional

Claude changed things. They looked different. Not better, just different.

I was trying to describe visual problems with words. That is incredibly inefficient.

Instead, I started taking screenshots of websites whose design I loved. I pasted them directly into Claude Code:

[screenshot of a clean calendar UI]

I want my calendar to look like this. Specifically:

• This exact shade of gray for the background
• These rounded cards for each post
• This amount of spacing between elements
• The way the active day is highlighted in blue

Claude matched the design almost perfectly. On the first try.

Then when something looked off, instead of describing it, I took a screenshot, circled the problem area, pasted it in, and said "this spacing is wrong" or "this font is too small."

Lesson learned: Screenshots are 10x better than words for visual feedback. Always paste images instead of describing what you see.

Sunday: It All Came Together

By Sunday morning I had a working app with clean design, drag-and-drop, persistent data, and a functioning database. I had built the whole thing without understanding most of the code.

But it only existed on my laptop. Time to deploy.

Mistake #5: Being Afraid of Deployment

Deployment sounded terrifying. Servers. Domains. DNS. Configuration files.

I almost stopped. I almost decided "running locally is good enough."

But I pushed through and asked Claude:

I want to deploy this app live to the internet. I want to use Vercel because I heard it's the easiest. Walk me through the exact steps.

Claude gave me seven steps:

1. Push the code to GitHub (Claude helped me set up Git)
2. Sign up for Vercel (free)
3. Connect Vercel to my GitHub repo
4. Set up the environment variables for the database
5. Click deploy
6. Wait 90 seconds
7. Get my live URL

I followed the steps. Three minutes later my app was live. I sent the URL to five people. They opened it. It worked.

Lesson learned: Deployment is not scary. It is just a checklist. Claude will walk you through every step.

The 12 Rules I Wish I Knew Before Starting

Everything I learned in two days, compressed into rules:

Rule 1: Start in Plan Mode every time. Shift + Tab. Think before building.

Rule 2: One conversation per feature. Fresh context is better context.

Rule 3: Create CLAUDE.md on day one. Every correction becomes a permanent rule.

Rule 4: Use screenshots for every visual issue. Circle the problem. Paste it directly.

Rule 5: Build the simplest version first. Add complexity only after the simple version works.

Rule 6: Describe what you want in detail. The more specific your prompt, the better the output. "Build a login page" gets trash. "Build a login page with email and password fields, a 'forgot password' link below, a blue submit button, and a redirect to /dashboard on success" gets exactly what you asked for.

Rule 7: Use /compact when conversations get long. Claude's quality drops when the context fills up.

Rule 8: Commit to Git after every working feature. Claude can help you do this. If something breaks, you can roll back.

Rule 9: When something breaks, copy the error message and paste it into Claude. Say "Diagnose the root cause before fixing anything." Claude almost always finds the problem instantly.

Rule 10: Do not try to understand every line of code. Understand what each file does and how they connect. That is enough to direct Claude effectively.

Rule 11: When Claude gets stuck in a loop fixing the same thing over and over, stop. Start a fresh conversation. Paste only the relevant file and a clear description of the problem.

Rule 12: Ship it before it is perfect. Version one does not need to be beautiful. It needs to work. You can always make it better in version two.

What I Built Since That Weekend

That was three weeks ago. Since then I have built:

• A client onboarding portal with login and file uploads
• An internal dashboard that tracks my content metrics
• A simple invoice generator that creates PDF invoices from a form
• A bookmark manager that saves and organizes links by topic

I still cannot read most code. I still do not understand 80% of what is happening in the files. But I can describe what I want clearly enough that Claude builds it. I can debug problems by showing Claude the error. I can deploy working products to the internet.

That is vibe coding. You are not the programmer. You are the product manager. Claude is the programmer. Your job is to know what to build and communicate it clearly.

Most people will keep telling themselves they need to learn to code before they can build anything.

The ones who open their terminal this weekend will have a working app by Monday morning. I know because that is exactly what happened to me.

Follow me @eng_khairallah1 for more AI courses, tools, and workflows. New content every week.

hope this was useful for you, Khairallah ❤️