How to Build an App with Claude

So you've seen the demos. Someone types a sentence into a terminal and twenty minutes later they've got a working app with a database, auth, and a deploy link. You want to know if that's actually real, and if it is, whether you can do it too without burning a weekend and $50 in API credits on something that falls apart the moment a real user touches it.

Here's the honest answer: yes, you can build a genuinely working app with Claude in 2026, and it's faster than at any point in the last two years. But almost every tutorial out there skips the parts that actually matter, the pricing traps, the rate limit walls, and the fact that most AI-generated code ships with security holes you won't notice until it's too late. This guide fixes that. I'm going to walk through exactly how to build an app with Claude Code (not the browser chat tool, that's a different thing and people mix them up constantly), what it costs as of August 2026, where it breaks, and how to know when you should just build the thing versus paying for the SaaS that already does it.

There are 9 steps below. Read them in order the first time, then bookmark this and skip around once you've built something.

1. Understand what "Claude" actually means here

This trips up more beginners than anything else. "Claude" is the chat assistant you might use in a browser tab, the one with Artifacts that can render a quick React component preview. That's fine for prototyping a UI idea or testing a snippet, but it's not what you use to build a real app.

Claude Code is the agentic CLI tool that runs in your terminal (or in VS Code/JetBrains via extension, or in a desktop app). It can read your entire codebase, write files, run shell commands, install dependencies, run tests, fix its own errors, and commit to git, all without you copy-pasting code back and forth. That autonomy is the entire point. When people say they "vibecoded" an app in a weekend, they mean Claude Code, not the chat window.

If you're going to build something real, install Claude Code first. It ships as part of the Pro plan and above, there's no separate purchase needed once you're subscribed. Don't waste time trying to build a full app inside the browser chat interface, it wasn't designed for that and you'll hit context and file-handling limits fast.

2. Pick your pricing tier before you start typing

This is the section most guides skip entirely, and it's the one that actually determines whether vibecoding saves you money or costs you more than the SaaS subscription you were trying to avoid.

As of mid-2026, here's what Anthropic actually charges:

• Pro: $20/mo month-to-month, or $17/mo if you pay $200 upfront annually. This is the entry point and includes Claude Code across terminal, web, and desktop, with access to both Sonnet and Opus models.
• Max 5x: $100/mo, for people running longer sessions or hitting Pro's limits regularly.
• Max 20x: $200/mo, for heavy daily use across multiple projects.
• Team Standard: $20-25/seat, but here's the gotcha: this tier does not include Claude Code. People buy this thinking they're getting the coding agent and end up confused when it's not there.
• Team Premium: $100-125/seat with a 5-seat minimum, this one does include Claude Code.
• Enterprise: custom pricing, unpublished, negotiated with API usage rates layered on top.

If you're a solo developer building a personal clone of some SaaS tool, Pro at $20/mo is almost certainly your starting point. Don't jump to Max unless you've actually hit Pro's limits (more on that in a second).

If you'd rather pay per token instead of a flat subscription, the API rates as of June 2026 are roughly $3/$15 per million tokens (input/output) for Sonnet 4.6, and $5/$25 per million for Opus 4.8. For context, Opus 4.8's output pricing is about half of GPT-5.5's $30/million output rate, so Anthropic is actually competitive on the high end right now. Claude Code automatically uses prompt caching too, and cached reads cost only 10% of the normal input price, which matters a lot once you're iterating on a large file repeatedly.

One more thing nobody warns you about: token bills can spike hard if you're not watching. There are real stories floating around of developers waking up to invoices in the tens of thousands of dollars because an unmonitored agent loop kept re-processing a large codebase overnight. If you're on the API instead of a flat subscription, set spending alerts before you start, not after.

3. Know the rate limits before they surprise you mid-build

Claude Code uses two overlapping caps: a rolling 5-hour window and a separate weekly cap. This matters because a full weekend build session, the kind where you're trying to clone a whole SaaS feature set in one sitting, can absolutely hit these walls.

The good news: Anthropic doubled the 5-hour rate limits for Pro, Max, Team, and Enterprise plans back in May 2026, and removed the old peak-hour throttling that used to slow things down during busy periods. There was also a temporary 50% weekly limit bump that ran from May through July 2026, seemingly a direct response to competitive pressure from OpenAI's Codex. That bump was automatic, no billing change required.

Community estimates put a Pro plan at roughly 90 prompts per 5-hour window after the doubling. Sounds like plenty, until you factor in that a heavy Opus session with extended thinking on a large codebase can burn through that in about 15 prompts. If you're building something with a lot of interdependent files (think: a scheduling app with calendar sync logic, or a form builder with conditional logic trees), you will feel this limit.

Practical advice: if you're doing a serious build session, start on Sonnet for routine file edits and boilerplate, and reserve Opus for the genuinely hard architectural decisions. Switching models mid-session is normal and it stretches your usage window considerably further.

4. Set up your project scaffold before you prompt anything

Don't open Claude Code and just say "build me a Trello clone." You'll get something, but it'll be generic and you'll spend more time correcting its assumptions than if you'd scaffolded things yourself first.

Here's a workflow that actually works:

Start with a plain-English spec file. Write a SPEC.md in your project root describing exactly what you're building: the core entities (users, tasks, boards, whatever), the key user flows, and what's explicitly out of scope. This single file does more to keep Claude Code on-rails than any amount of clever prompting. Claude Code reads project files automatically when it starts a session, so this becomes its source of truth.

Pick your stack up front and say so explicitly. If you want Next.js with a Postgres database via Supabase, say that in your first prompt. Left to its own judgment, Claude Code will make reasonable choices, but "reasonable" might not match what you actually want to maintain long-term. For a personal-use clone that you want done fast, something like Next.js + Supabase + Vercel is a genuinely good default: managed auth, managed database, one-command deploys.

Ask for a plan before code. Literally prompt: "Before writing any code, give me a step-by-step plan for building this, broken into phases I can review." Claude Code (especially on Opus) will produce a sensible phased approach: schema first, then core CRUD, then auth, then the trickier bits like real-time sync or third-party API integration. Reviewing this plan for ten minutes saves hours of correcting direction later.

Build in phases, testing after each one. Don't let it run for two hours unsupervised. Have it build the data model and basic CRUD, check it, then move to the next phase. This also matters for rate limits: shorter focused sessions with clear checkpoints use tokens more efficiently than one long unstructured session where the agent has to re-read growing context repeatedly.

If you want a deeper walkthrough of this exact workflow with more prompting patterns, How to Vibe Code with Claude covers the model-picking and pricing side in more detail, and How to Vibecode a SaaS in 2026 walks through the full 10-step build process for a production-style app rather than a quick personal tool.

5. Understand which model to use when

This is where a lot of the recent model churn actually matters practically, not just as a spec sheet curiosity. As of August 2026, the lineage has moved fast: Opus went 4.5 → 4.6 → 4.8, Sonnet went 4.5 → 4.6 → Sonnet 5 (launched June 30, 2026), and there's now talk of a newer flagship model scoring around 95% on SWE-bench Verified in some benchmarks.

Here's what the numbers actually mean for you:

• Opus 4.5 scored 80.9% on SWE-bench Verified, beating GPT-5.1 and Gemini 3 Pro at the time, plus 37.6% on ARC-AGI-2, a benchmark specifically designed to test genuine reasoning rather than pattern matching.
• Opus 4.8 pushed to 88.6% on SWE-bench Verified, 69.2% on the harder SWE-bench Pro, and 74.6% on Terminal-Bench 2.1 (though one other source puts Opus 4.8 at 79.4% in a different comparison table, benchmark numbers genuinely vary depending on who's testing and how, so don't treat any single number as gospel).
• Sonnet 5 landed at 72.7% SWE-bench Verified and 76.1% on Terminal-Bench, a 20+ point jump over Sonnet 4.6's 55.4%. Anthropic is explicitly positioning it as "near-Opus performance at Sonnet pricing," and for most personal app builds, that's genuinely true in practice.

The practical takeaway: at medium reasoning effort, Opus 4.5 matched Sonnet 4.5's top score while using 76% fewer output tokens. At high effort, Opus beat Sonnet by 4%+ while still using roughly half the tokens. That efficiency gap is why Opus is worth reaching for on genuinely hard problems (complex state management, tricky auth flows, gnarly data migrations) even though it costs more per token. For everyday CRUD work, form generation, styling, and routine bug fixes, Sonnet 5 is not just adequate, it's often the smarter economic choice given how close it's gotten to Opus-level output quality.

A rough rule that works in practice: default to Sonnet, escalate to Opus explicitly when you hit something that requires actual architectural reasoning, like designing a database schema for a multi-tenant app or debugging a race condition in async code.

6. Build the core CRUD loop first, always

Whatever you're cloning, whether it's a scheduling tool, a form builder, or a lightweight project tracker, the fastest path to something usable is to nail the core create-read-update-delete loop before touching anything fancy.

Here's what that looks like in an actual session. Say you're building a personal Kanban board (a stripped-down Zenkit-style tool for your own task management). Your first real build session should focus entirely on:

1. Database schema: boards, columns, cards, with basic relationships
2. A working UI to create a board, add columns, add cards, and drag them between columns
3. Persistence, so refreshing the page doesn't lose your data
4. Basic auth, even if it's just a single hardcoded user for personal use

That's it for session one. Don't ask for real-time collaboration, don't ask for team permissions, don't ask for six different view types. Claude Code is genuinely good at producing working CRUD apps fast, this is squarely in its comfort zone and matches what these models have been trained and benchmarked against most heavily. Where things get slower is the moment you introduce state that has to stay consistent across multiple simultaneous users, or third-party integrations with flaky external APIs.

Once the core loop works and you've tested it yourself (actually clicking through it, not just trusting that it compiled), then layer in the next feature. Ask for one thing at a time. "Now add due dates to cards and a way to filter by them" is a good prompt. "Now make this look and function exactly like Trello" is not, it's too vague and invites the model to guess at scope.

7. Take security seriously, because the data says you shouldn't skip it

This is the part almost every "build an app with Claude" tutorial either buries in a footnote or skips completely, and it's genuinely the biggest risk in this whole workflow.

The numbers are not subtle. OX Security found that 62% of AI-generated code ships with vulnerabilities. Georgetown's Center for Security and Emerging Technology found an 86% failure rate specifically on XSS defense mechanisms in AI-generated code. Georgia Tech's "Vibe Security Radar" tracked CVEs traceable back to AI coding tools growing from 6 in early 2025 to 74 by March 2026, that's more than a tenfold increase in about a year.

It gets more specific and more alarming the closer you look. CodeRabbit analyzed 470 open-source pull requests in December 2025 and found AI-co-authored code carries a 2.74x higher security vulnerability rate than human-written code, and 1.7x more major issues overall. Veracode tested over 100 different LLMs and found 45% of AI-generated code samples failed OWASP Top-10 security tests, even though syntax correctness was above 95%. That gap matters: the code runs fine, it just isn't safe. And scaling up to bigger, smarter models doesn't fix this on its own, Veracode's pass rates stayed stubbornly stuck around 55% regardless of model size.

Escape.tech scanned over 1,400 vibe-coded production apps and found 65% had security issues, with 58% carrying at least one critical vulnerability. They found more than 400 exposed secrets and 175 instances of exposed personally identifiable information sitting in code that had already shipped. Tenzai tested 15 apps built across 5 major AI coding tools in December 2025 and found every single one lacked CSRF protection and proper security headers, and every tool tested introduced SSRF vulnerabilities somewhere in the build.

There's also a newer risk that most people building personal apps haven't even heard of: prompt injection against agentic coding assistants. A meta-analysis published in January 2026 covering 78 studies on tools like Claude Code found that adaptive attack strategies succeed over 85% of the time, and most published defenses block less than half of those attempts. This mostly matters if your agent is pulling in content from external sources (scraping a webpage, reading an uploaded file) while it works, but it's worth knowing the attack surface exists.

None of this means don't build with Claude Code. It means: if your app touches real user data, handles payments, or stores anything sensitive, don't just deploy and walk away. Explicitly prompt for security review as its own phase: ask Claude Code to check for CSRF protection, proper security headers, input sanitization, and exposed secrets in your .env handling. Run a tool like npm audit or a basic OWASP scanner before you consider anything "done." For a purely personal, single-user tool that never touches anyone else's data, the stakes are much lower, but the moment you're thinking about sharing it or handling other people's information, treat security as a mandatory phase, not an afterthought.

8. Deploy, test with real usage, then decide if it was worth it

Once your core app works and you've done a security pass, deployment itself is usually the easy part in 2026. If you scaffolded with Next.js and Supabase, deploying to Vercel is close to a one-command process, and Claude Code can handle the config for you, setting environment variables, connecting your database, and wiring up your build pipeline.

But here's the step that actually matters and that most tutorials skip: use the thing yourself for a week before deciding whether the build was worth it. This is where the real cost comparison happens. Add up what you actually spent: your Claude subscription tier for the month you built it, plus hosting (often free on hobby tiers, but not always once you scale past them), plus your own time if you value that at all. Compare that honestly against what the SaaS you were trying to replace actually charges per month.

Sometimes this math clearly favors building it yourself. A personal scheduling tool replacing something like Zencal or YouCanBookMe for your own single-user use case, where you don't need multi-user routing or payment processing, is a genuinely good candidate: you'll spend maybe $20-40 in subscription costs and a weekend, and end up with something that does exactly what you need indefinitely with no recurring bill.

Sometimes it clearly doesn't. If you're trying to replace something like Zapier because you want its 9,000+ app integration catalog, or Zoom because you need enterprise-grade video infrastructure, you'll burn far more in time and API costs building a worse version of something that already works, and you'll be maintaining it forever. The honest answer in those cases is: build a small personal subset if you're curious and want to learn, but keep paying for the real thing if you actually depend on it.

This is genuinely the crux of the whole "vibecoding vs. paying for SaaS" decision, and it's the piece almost no tutorial actually addresses. Most articles stop at "here's how you build it" as if that's the finish line. It isn't. The finish line is knowing whether building it was the economically rational choice compared to just paying the $15/mo the SaaS charges, once you count your own time, the ongoing maintenance burden, and the security work you'll need to keep doing as dependencies update and models change underneath you.

Here's a real tutorial that walks through the build process end to end if you want to watch someone do this live rather than just read about it:

9. Maintain it, or accept that you won't

The last thing nobody tells beginners: a working app on day one is not the same as a working app in month six. Dependencies update. Supabase or Vercel change their APIs occasionally. Your Claude Code prompts from six months ago might not even work the same way against a newer model version, since Anthropic ships new models every 4-8 weeks now and behavior shifts subtly between them.

If you're building something you genuinely intend to keep using long-term, budget for occasional maintenance sessions, maybe an hour a month checking that things still work, updating dependencies, re-running a security scan. This is honestly where the "vibecoded app vs. paid SaaS" math shifts again: SaaS companies handle this maintenance burden for you as part of what you're paying for. When you vibecode your own version, that maintenance burden becomes yours, forever, or until you decide it's not worth it anymore and go back to paying for the tool you were trying to replace.

If you're not planning to maintain it, that's fine too, just be honest with yourself about it up front. A weekend project built to solve a specific personal problem right now doesn't need a five-year maintenance plan. Build it, use it, and if it breaks in eight months because an API changed, either fix it in twenty minutes with Claude Code's help or just let it go and move on. Not every vibecoded app needs to become a permanent piece of your infrastructure.

What actually works well right now

To summarize the parts of this that genuinely work in 2026: CRUD apps, personal dashboards, single-user tools, and anything that maps cleanly to a well-known pattern (a form builder, a simple scheduler, a note-taking tool, a habit tracker) are squarely in Claude Code's strike zone. You can realistically go from an empty folder to a working, deployed personal tool in a weekend, sometimes in an afternoon, especially now that Sonnet 5 has closed so much of the gap with Opus while staying cheaper per token.

What still actively hurts you if you try it

Real-time multi-user collaboration, complex third-party API orchestration (especially anything involving bi-directional calendar sync or payment processing), and anything requiring genuine infrastructure at scale (video processing pipelines, massive crawler systems, enterprise compliance) are still genuinely hard, and the security data above should make you cautious about deploying anything handling real user data without a dedicated review pass. Trust in AI-generated code has actually fallen even as usage has risen, down to roughly 29% by recent survey data, with 96% of developers saying they don't fully trust that AI-generated code is functionally correct, yet less than half always review before committing it. That gap between usage and trust is exactly where things go wrong for people who skip step 7 above.

FAQ

Is Claude Code free to use?

No. There's no free tier for Claude Code itself. You need at minimum a Pro subscription at $20/mo (or $17/mo billed annually) to access it, or you can pay per token through the API at roughly $3/$15 per million tokens for Sonnet 4.6, or $5/$25 per million for Opus 4.8. Team Standard plans at $20-25/seat notably do not include Claude Code at all, which trips up a lot of people who assume any Claude subscription gets them the coding agent.

What's the difference between Claude the chatbot and Claude Code?

Claude the browser chat tool (with Artifacts) is good for quick prototyping, testing a UI idea, or generating a single component you'll copy-paste manually. Claude Code is the agentic CLI tool that runs in your terminal, reads your whole project, writes and edits files directly, runs shell commands, installs packages, and fixes its own errors across a multi-step build. If you're building a full app rather than a single snippet, you want Claude Code, not the chat window.

How long does it actually take to build an app with Claude Code?

For a simple single-user CRUD app (a personal task tracker, a basic form builder, a scheduling tool for yourself only), a weekend is realistic, sometimes just an afternoon if you scaffold well and keep scope tight. For anything involving real-time multi-user features, third-party API integrations, or payment processing, expect weeks of focused work, not hours, and budget for genuine debugging time around the trickier integrations.

Is code built with Claude Code safe to deploy for real users?

Not automatically, and this is the part most tutorials skip. Independent research in 2025-2026 found that 58-65% of scanned vibe-coded production apps carry critical security vulnerabilities, and AI-generated code overall shows a vulnerability rate roughly 2.74 times higher than human-written code in comparable pull requests. If your app only serves you personally and handles no sensitive data, the risk is low. If it touches other users' data or payments, you need an explicit security review pass (CSRF protection, security headers, input sanitization, secrets management) before you consider it deployment-ready.

Should I use Sonnet or Opus when building an app with Claude?

Default to Sonnet 5 for routine work: CRUD scaffolding, styling, standard bug fixes. Sonnet 5 scores 72.7% on SWE-bench Verified and has closed most of the performance gap with Opus while costing significantly less per token. Reserve Opus 4.8 (88.6% SWE-bench Verified in most benchmarks) for genuinely hard architectural decisions: database schema design for complex relationships, tricky async state bugs, or anything requiring deep multi-step reasoning. Switching models mid-session is normal and helps you stretch your rate limit window further too.

Will I hit rate limits building a full app in one sitting?

Possibly, yes, especially on the Pro tier during a long, intensive session. Claude Code enforces both a rolling 5-hour cap and a separate weekly cap. Community estimates put Pro at roughly 90 prompts per 5-hour window after Anthropic's May 2026 doubling, but a heavy Opus session with extended thinking on a large codebase can burn through that in as few as 15 prompts. Structuring your build into shorter, checkpointed phases rather than one marathon session helps you use your allotted usage more efficiently and avoid an unexpected wall mid-build.

Is it actually cheaper to vibecode an app than to pay for the SaaS it replaces?

Sometimes, but not always, and this is the question most tutorials never actually answer. For simple, single-user tools where you don't need the SaaS's multi-user features, integrations catalog, or compliance infrastructure, building your own version for the cost of a $20/mo subscription and a weekend of your time is often genuinely cheaper long-term, since you avoid the recurring bill entirely. For anything requiring ongoing infrastructure, third-party integrations at scale, or enterprise-grade reliability, the math flips: you'll spend more in time, API costs, and ongoing maintenance building a worse version of something you could just pay $15-30/mo for. Always run the real comparison, subscription cost plus hosting plus your own maintenance time, before assuming vibecoding automatically wins.