Build a Full-Stack App with Claude Code

Full-stack apps are where Claude Code’s power and its limitations both show up most clearly. The power: it can generate a working backend API, a typed frontend client, and the glue between them faster than any solo developer working manually.

The limitation: full-stack apps span more decisions, more failure modes, and more integration surfaces than any single component project.

The workflow that works is phased and sequential: architecture first, backend second, frontend third, integration fourth. Teams that prompt everything at once get code that looks complete but fails at the seams.

A full-stack app built with Claude Code is only as coherent as the architecture plan you bring to the first session. Claude Code cannot make your architectural decisions. It can execute the decisions you have already made with speed and accuracy.

Architecture planning before prompting

What to decide before opening Claude Code

Architecture decisions made during prompting produce inconsistent code. Decisions made before prompting produce coherent code.

Spend thirty minutes to an hour on these before your first Claude Code session.

Technology choices:

Backend: Language and framework (Node/Express, Python/FastAPI, Ruby/Rails).
Frontend: Framework (Next.js, React with Vite, SvelteKit).
Database: PostgreSQL, SQLite, or MongoDB.
Authentication: JWT, sessions, or a third-party provider like Clerk or Supabase Auth.
Hosting: Vercel + Railway, Fly.io, or Render.

Application structure:

The data entities and their relationships (draw or write an ERD).
The primary user flows (three to five, maximum).
The API contract between frontend and backend (REST or tRPC).
The authentication and authorization model (who can access what).

Write this in a CLAUDE.md file at your project root. This file is not just documentation. It is the context document Claude Code reads at the start of every session to understand the current state of the project.

The CLAUDE.md guide explains how to structure it effectively.

What CLAUDE.md should contain

CLAUDE.md serves as cross-session memory for Claude Code. A useful CLAUDE.md includes:

Tech stack. Each choice and why it was made.
Data model. Entities and their relations.
Build phase. The current phase and what is complete.
Decisions made. Key decisions already made, do not re-litigate these in new sessions.
Known issues. Deliberate tradeoffs to be aware of.

Update CLAUDE.md at the end of every build session. The next session starts with Read CLAUDE.md and tell me what you understand about the current state of the project before any code is generated.

The phased build workflow

Phase 1: Backend first

Build the backend before the frontend. The backend is the source of truth for your data model, your API contract, and your business logic.

Building the frontend first creates a situation where the frontend invents assumptions about the API that the backend then has to match.

Start with the database schema. Generate migrations, verify them against your ERD, and run them before any application code is written.

The schema is the foundation. Get it right before building on it.

Next, generate your API routes one resource group at a time (users, projects, items). Test each route group with a REST client before moving to the next.

A broken route caught at this stage is a ten-minute fix. The same bug discovered after frontend integration is a two-hour archaeology project.

Add authentication last in the backend phase. Once the data routes are working, add auth middleware, protect the routes that need protecting, and test auth flows end-to-end before proceeding to the frontend.

The guide on authentication implementation covers the patterns for JWT, sessions, and OAuth in depth.

Phase 2: Frontend

Start the frontend by generating a typed API client from your backend routes. If you are using tRPC, the client is generated automatically.

If you are using REST, ask Claude Code to generate a client module that wraps each endpoint with proper TypeScript types matching your API response shapes.

This typed client is the contract between frontend and backend. When a type in the client does not match what the backend returns, you find out at compile time instead of at runtime.

Build UI in this sequence:

Layout and navigation, the shell every page lives in.
Authentication UI, login, registration, and session handling.
Data display pages, list views, detail pages, dashboard overviews.
Interactive forms and mutations, creates, edits, and deletes.

Each layer builds on the previous. Data display pages require working auth. Interactive forms require working data display.

Phase 3: Integration

Integration is where full-stack projects hit the most unexpected friction. The frontend and backend work in isolation, but together they surface mismatches. The most common integration issues in Claude Code-generated projects:

CORS policy rejecting frontend requests to the backend.
Cookie sameSite and secure flags misconfigured for the deployment environment.
Auth token not being sent in frontend API requests.
Error response shapes inconsistent between routes.

Run the frontend and backend together for the first time as a deliberate integration step, not as a by-product of adding a feature. Claude Code fixes all of these quickly once they are identified.

The key is surfacing them deliberately rather than discovering them later.

Phase 4: Deploy

Deploy early, even if the app is incomplete. An incomplete app deployed to production surfaces environment-specific issues (environment variables, database connection strings, HTTPS requirements) before you have thousands of lines of code to debug.

For containerized deployments, the Docker and Kubernetes guide covers how to generate production-ready container configuration.

Deploy the backend first. Verify it responds correctly to health checks and authenticated requests from an external REST client.

Then deploy the frontend, configured to point to the deployed backend URL. Run the same integration tests you ran locally.

Managing state across sessions

The session continuity problem

Claude Code does not retain memory between sessions. Every session starts fresh.

For a project that takes days or weeks to build, this creates a real problem: Claude Code does not know what was built yesterday, what decisions were made, or what the current state of the codebase is.

The solution is explicit context management, not relying on Claude Code’s memory.

CLAUDE.md as the project brain

Update CLAUDE.md at the end of every session with:

Completed work. What was built in this session.
Next steps. What comes next.
Decisions made. Any choices or tradeoffs accepted.
Open issues. Any known issues left unresolved.

Start every session by having Claude Code read CLAUDE.md. This gives it the context to work from the current state rather than inventing assumptions.

Git commits as session checkpoints

Commit at the end of every build session, even if the feature is incomplete. Commit messages serve as a timeline of what was built and when.

A session that goes wrong can be rolled back cleanly. More importantly, the git history gives you a recoverable record of the project state at every session boundary.

Ask Claude Code to suggest a commit message at the end of each session. The message should describe what was built, not just the files changed.

What Claude Code handles vs. what needs human judgment

Task	Claude Code handles	Human judgment required
Boilerplate and scaffolding	Generates accurately and quickly	Verify structure matches your architecture plan
CRUD routes and endpoints	Generates idiomatic, testable code	Review business logic edge cases
Database schema generation	Produces correct schema from entity descriptions	Validate relations, indexes, and constraint ordering
Authentication implementation	Generates standard patterns correctly	Choose the auth strategy and security model
Frontend component generation	Accurate for common patterns	Review UX decisions and accessibility
TypeScript type definitions	Generated types are generally accurate	Review for excessive `any` or missing generics
Test stubs and scaffolding	Good structure, needs human assertion logic	Write realistic test scenarios and assertions
Security architecture	Generates baseline patterns	Security threat modeling is a human decision
Performance optimization	Does not audit bundle size or query performance	Profile the running app, optimize bottlenecks
Data migration strategy	Can generate migrations from schema diffs	Review migration safety for production data
Deployment configuration	Generates accurate config for known platforms	Validate environment-specific settings
Error handling	Covers common cases	Define and handle your domain-specific error states

Frequently asked questions

Should I build the frontend and backend in the same repository or separate repositories?

A monorepo is easier to manage with Claude Code. Having both in the same repository means CLAUDE.md covers the full project, TypeScript types can be shared between frontend and backend (via a packages/shared directory), and the integration testing workflow is simpler.

Separate repositories make sense for large teams or when the frontend and backend have significantly different deployment cadences.

How do I handle database migrations safely with Claude Code?

Always review generated migrations before running them against any database with real data. Claude Code generates correct migrations for schema creation, but complex migrations (renaming columns, changing types, splitting tables) require human review for data safety. Test migrations against a copy of production data before running them in production. The automated testing guide covers how to set up test coverage that catches migration regressions.

Use tRPC for automatic end-to-end type safety with minimal configuration. If you prefer a REST architecture, create a packages/types package in your monorepo that exports shared TypeScript interfaces, and import them in both the backend and frontend. Claude Code generates both patterns cleanly when you specify your preference.

How do I keep Claude Code on track during a multi-week build?

Three practices keep multi-week builds on track:

Update CLAUDE.md at the end of every session.
Commit at every session boundary.
Start every session with Read CLAUDE.md and summarize the current state of the project before any new code generation.

This ritual takes two minutes and prevents the session drift that derails longer builds.

Ready to build your full-stack app?

Full-stack apps are the most ambitious thing you can build with Claude Code, and the most rewarding when the workflow is right. The phased approach (architecture, backend, frontend, integration, deploy) keeps the build coherent. CLAUDE.md and git commits keep it recoverable. Human review at the schema, security, and integration phases keeps it production-worthy.

The teams that ship full-stack apps with Claude Code in weeks rather than months are the ones who plan the architecture before the first prompt, build in phases, and treat every session as a checkpoint with a commit and an updated CLAUDE.md. The teams that struggle are the ones who prompt randomly and wonder why the pieces do not fit together.

Path one: do it yourself. Write your CLAUDE.md today with your tech stack, data model, and the three primary user flows your app supports. Start with the backend: schema first, then routes, then auth. Commit after each phase. The discipline of the phased approach is the technique. For a guided walkthrough of the full-stack workflow and common pitfalls, the Claude Code Course is the structured starting point.

Path two: work with Phos AI Labs. If you want a senior engineering team running your full-stack build from architecture through production deployment, Phos AI Labs runs structured development engagements for exactly this kind of project. Thirty minutes, no deck. Start here.

How to Build a Full-Stack App with Claude Code

Architecture planning before prompting