How to Build Apps with Claude Code: A Complete Workflow Guide
“Build me a complete full-stack application.”
That was my prompt to Claude Code on Day 1. By Day 2, I had messy, inconsistent code that barely worked. By Day 3, I was humbled and realized I had been using Claude Code completely wrong.
The problem wasn’t Claude Code. The problem was my approach.
The One-Shot Fallacy
Many developers fall into the same trap. They treat Claude Code as a magic wand that can conjure complete applications from a single prompt. This fails for predictable reasons:
+------------------+ +------------------+| Large Prompt | ---> | Context Gets || "Build entire | | Diluted || application" | | |+------------------+ +------------------+ | | v v+------------------+ +------------------+| Claude Tries to | | Quality Degrades || Handle Everything| | As Codebase Grows|+------------------+ +------------------+ | | v v+------------------+ +------------------+| Inconsistent | | Problems Compound || Decisions Made | | Without Review |+------------------+ +------------------+I expected Claude to understand my entire vision from one prompt. It couldn’t. No AI can.
The Right Approach: Mid-Level Engineer Mindset
The breakthrough came when I read a comment on Reddit that changed everything:
“Treat Claude Code like a mid-level engineer who is onboarding - give incremental tasks.”
This reframed my entire approach. When I onboard a mid-level engineer, I don’t hand them a 50-page PRD and say “build this.” I:
- Explain the architecture
- Set up their environment
- Give them small, well-defined tasks
- Review their work
- Iterate
Claude Code needs the same treatment.
The Incremental Development Workflow
Phase 0: Specification Before Code
Before writing any code, I create a CLAUDE.md file. This file contains:
| Section | Purpose |
|---|---|
| Architecture Decisions | Technology choices and rationale |
| Constraints | What NOT to do |
| Coding Patterns | Style guidelines and conventions |
| Project Structure | How files should be organized |
This file acts as the “onboarding document” for Claude Code. Every time it starts a new session, it reads this file and understands the project context.
Phase 1: Foundation Layer
I start by building the skeleton, not the features:
foundation/ ├── project structure and configuration ├── database schema and migrations ├── core utilities and helpers ├── authentication/authorization foundation └── basic API skeletonThis foundation layer gives Claude a consistent base to build on. Without it, every new feature would reinvent the wheel differently.
Phase 2: Vertical Slices
This is the key insight that changed my results. Instead of building horizontally (all models, then all APIs, then all frontends), I build vertically:
+--------------------------------------------------+| Horizontal Approach (WRONG) |+--------------------------------------------------+| Step 1: Build ALL data models || Step 2: Build ALL API endpoints || Step 3: Build ALL frontend components || Result: Everything is half-baked |+--------------------------------------------------+
+--------------------------------------------------+| Vertical Approach (RIGHT) |+--------------------------------------------------+| Slice 1: User feature || - User data model || - User API endpoints || - User frontend components || - User tests || Slice 2: Post feature || - Post data model || - Post API endpoints || - Post frontend components || - Post tests |+--------------------------------------------------+Each vertical slice is a complete, working feature. I can test it, review it, and iterate on it before moving to the next.
Phase 3: The Development Cycle
For each slice, I follow this cycle:
+-------------+ +-------------+ +-------------+| Prototype | --> | Architecture| --> | Implement || (Explore) | | (Design) | | (Build) |+-------------+ +-------------+ +-------------+ ^ | | v+-------------+ +-------------+ +-------------+| Refine | <-- | Review | <-- | Test |+-------------+ +-------------+ +-------------+Prototype: I ask Claude to explore the problem and suggest approaches. This often produces throwaway code, but it clarifies the solution space.
Architecture: Based on the prototype, I have Claude design the proper architecture. This goes into CLAUDE.md as documentation.
Implement: Claude writes the actual code following the architecture.
Test: I run tests and check for issues.
Review: I review the code for quality, patterns, and potential improvements.
Refine: Based on the review, I iterate on the implementation.
Why This Works: The Compound Effect
Quality Multiplication
When I build incrementally, patterns established early propagate correctly:
First slice: Defines patternsSecond slice: Follows patterns (easy)Third slice: Follows patterns (easy)...When I build all at once, inconsistencies compound:
Model A: Pattern XModel B: Pattern Y (inconsistent!)Model C: Pattern Z (also inconsistent!)API A: Pattern Q (completely different!)Predictable Progress
Vertical slices make progress measurable:
| Approach | Day 1 | Day 2 | Day 3 |
|---|---|---|---|
| Horizontal | ”Built 10 models" | "Built 10 APIs" | "Nothing works yet” |
| Vertical | ”User feature works" | "Post feature works" | "Ready for production” |
Early Problem Detection
Each slice is a checkpoint. Problems caught early don’t compound:
Horizontal: Find bug on Day 10 -> Fix 10 layers of codeVertical: Find bug on Day 1 -> Fix 1 slice of codeCommon Mistakes I Made
Mistake 1: The Kitchen Sink Prompt
WRONG: "Build me a complete blog platform with users, posts, comments, admin panel, analytics, and notifications"
RIGHT: "Let's start by building the user authentication. Here's the CLAUDE.md with our architecture decisions."Mistake 2: No CLAUDE.md
I used to start coding immediately. Now I never start without a CLAUDE.md that specifies:
- What database to use and why
- What frontend framework and why
- Coding conventions
- What NOT to do
Mistake 3: Skipping Review
I used to let Claude run without reviewing. Now I review every slice before starting the next. This catches issues when they’re small.
Mistake 4: Horizontal Slicing
Building all models, then all APIs, then all frontends creates a coordination nightmare. Everything depends on everything else, and nothing works until everything is done.
Mistake 5: No Milestones
I used to work without clear milestones. Now I define what “done” means for each slice before starting.
A Real Workflow Example
Here’s how I built a feature recently:
Step 1 - Foundation Check: Does the project have CLAUDE.md? Yes. Does the database schema support this feature? Yes.
Step 2 - Prototype: I asked Claude to prototype the feature. Got a quick implementation in one file.
Step 3 - Architecture: Reviewed the prototype, identified what needed to be split up. Updated CLAUDE.md with decisions.
Step 4 - Implement Vertical Slice: Claude built the model, API, frontend, and tests for this single feature.
Step 5 - Review and Test: Ran tests, reviewed code patterns, made small adjustments.
Step 6 - Commit: Only after the slice was complete and tested.
Step 7 - Next Slice: Started on the next feature, building on the patterns from the first.
Summary
In this post, I showed how to build applications with Claude Code using an incremental, vertical-slice approach. The key point is treating Claude Code like a mid-level engineer: give it clear specifications, build foundation layers first, then iterate through complete vertical slices rather than horizontal layers.
The workflow that works is: prototype, design, implement, test, review, refine. Each cycle produces working code. Each slice is a deliverable. Problems stay small because they’re caught early.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments