Skip to content
Lesson 10 of 12

Full-Stack in a Session — Building Complete Features

8 min read

The Session as a Unit of Work

Traditional development breaks features into tickets, spread across days or weeks. A database change today, an API endpoint tomorrow, the frontend next week. This fragmented approach introduces coordination overhead, context loss between sessions, and integration bugs when pieces finally come together.

The 5.7x approach treats the session as the unit of work. One session, one complete feature -- from database schema to deployed UI. This is possible because AI handles the execution speed while you handle the architecture and review.

A single session can realistically produce:

  • A database migration with new tables and relationships
  • API endpoints with validation, error handling, and authentication
  • Frontend components with state management and styling
  • Tests covering the critical paths
  • Documentation updates
  • A commit and deployment to production

The session is not a marathon of coding. It is a focused period of directing, reviewing, and verifying. Most of the time is spent making decisions, not writing code.

The Session Blueprint

Every productive session follows a blueprint:

Step 1: Plan the Feature (5-10 minutes)

Before any code is generated, define the complete feature scope:

claude "/plan I need a user preferences system. Here is the full scope:

Database:
- New 'preferences' table: id, user_id (FK), theme, language,
  email_notifications, created_at, updated_at

API:
- GET /api/preferences — return current user's preferences
- PUT /api/preferences — update preferences (partial updates OK)
- Validation with zod, authentication required

Frontend:
- Settings page at /settings
- Toggle switches for theme and notifications
- Language selector dropdown
- Save button with loading state and success feedback

Infrastructure:
- Database migration with rollback
- Seed data for development
- Integration tests for API endpoints
"

This planning step catches scope issues before any code is written. It also gives AI the full picture, reducing the chance of inconsistencies between layers.

Step 2: Create the Task List (2-3 minutes)

Break the plan into an ordered task list with dependency awareness:

## Task List

### Independent (can parallelize)
- [ ] Database migration
- [ ] Zod validation schemas
- [ ] Settings page UI component (with mock data)

### Sequential (after dependencies)
- [ ] API routes (needs migration + schemas)
- [ ] Connect UI to API (needs API + UI)
- [ ] Integration tests (needs API)

### Final
- [ ] End-to-end verification
- [ ] Commit and deploy

Step 3: Execute Tasks

Start with independent tasks in parallel:

# Parallel execution of independent tasks
claude --background "Create the database migration for the preferences
       table. Fields: id (uuid, PK), user_id (uuid, FK to users),
       theme (enum: light/dark, default light), language (enum: en/es,
       default en), email_notifications (boolean, default true),
       created_at, updated_at."

claude --background "Create the zod validation schemas for preferences
       in src/lib/schemas/preferences.ts. Schema for GET response and
       PUT request body. PUT body should allow partial updates."

claude "Create the Settings page UI at src/app/settings/page.tsx.
       Use mock data for now. Include toggle switches for theme and
       notifications, language selector, and save button with loading state."

Then proceed with dependent tasks:

# After migration and schemas are ready
claude "Create the API routes for preferences at src/app/api/preferences/route.ts.
       Use the migration schema and zod validators. GET returns the
       current user's preferences. PUT updates with partial support.
       Both require authentication via getServerSession."

# After API and UI are ready
claude "Connect the Settings page to the real API. Replace mock data
       with API calls. Add loading states, error handling, and
       success feedback after saving."

# After API is complete
claude "Write integration tests for the preferences API. Test:
       GET without auth (401), GET with auth (200 + data),
       PUT with valid data (200), PUT with invalid data (400),
       PUT without auth (401)."

Step 4: Build and Verify (5-10 minutes)

Run the full build and test suite:

# Run migrations
npx prisma migrate dev

# Run tests
npm test

# Build to catch type errors
npm run build

# Start dev server for manual testing
npm run dev

Test the feature manually:

  • Navigate to /settings
  • Verify preferences load correctly
  • Change each preference and save
  • Refresh the page to confirm persistence
  • Test error states (network failure, validation errors)

Step 5: Commit and Deploy (2-3 minutes)

# Review all changes
git diff --stat

# Stage and commit
git add -A
git commit -m "feat: add user preferences with settings page, API, and tests"

# Deploy
git push origin main

Real Example: Dark Mode Across 19 Files

Here is how a real dark mode implementation played out in a single session:

Session duration: 45 minutes

Task breakdown:
1. Infrastructure (5 min)
   - Install next-themes
   - Create ThemeProvider component
   - Wrap root layout in ThemeProvider
   - Add dark mode Tailwind config

2. Component updates (15 min, parallelized)
   - Agent 1: Update Navbar, Footer, Sidebar (3 files)
   - Agent 2: Update Card, Button, Badge components (3 files)
   - Agent 3: Update page layouts and content sections (6 files)
   - Main: Update form components and modals (4 files)

3. Toggle and persistence (5 min)
   - Create ThemeToggle component
   - Add to Navbar
   - Configure localStorage persistence
   - System preference detection

4. Verification (10 min)
   - Test light mode across all pages
   - Test dark mode across all pages
   - Test system preference switching
   - Test persistence across page reloads

5. Commit and deploy (5 min)
   - Review diff (19 files changed)
   - Commit and push
   - Verify production deployment

Result: Complete dark mode across entire site.
Files changed: 19
Manual estimate: 3-4 hours

Managing Long Sessions

Some features require sessions longer than an hour. Here are strategies for maintaining effectiveness:

Context Management with /compact

As your conversation grows, Claude Code's context window fills up. Use /compact to summarize the conversation and free up space:

# After completing a major chunk of work
/compact

# Claude summarizes what was accomplished and what is remaining
# Now you have fresh context for the next chunk

When to compact:

  • After completing a task group (e.g., all API routes done, moving to frontend)
  • When you notice AI starting to lose context about earlier decisions
  • Before starting a completely different type of work within the same session

Checkpointing for Safety

Create git checkpoints at key milestones:

# After infrastructure is in place
git add -A && git commit -m "checkpoint: preferences infrastructure"

# After API routes work
git add -A && git commit -m "checkpoint: preferences API routes"

# After UI is connected
git add -A && git commit -m "checkpoint: preferences UI connected"

These checkpoints let you roll back to any milestone if a later step introduces problems.

The "Inbox Zero" Approach

Treat your task list like an inbox. Clear every item before ending the session:

## Session Task List
- [x] Database migration
- [x] Zod schemas
- [x] API routes
- [x] Settings page UI
- [x] Connect UI to API
- [x] Integration tests
- [x] Manual verification
- [x] Commit and deploy

Do not leave the session with half-finished work. It is better to reduce scope and ship something complete than to leave a partially implemented feature that requires context rebuild in the next session.

Real Example: 12 Portfolio Projects in One Session

Another single-session accomplishment: adding 12 new project entries to a portfolio site.

Each project required:
- Project card with image, title, description, tech stack tags
- Individual project page with detailed description
- GitHub and live demo links
- Proper categorization and ordering

Session approach:
1. Define all 12 projects in a structured list (10 min)
2. Create project data entries in parallel (3 agents, 15 min)
3. Verify rendering on the portfolio page (5 min)
4. Adjust styling and ordering (5 min)
5. Commit and deploy (5 min)

Total time: 40 minutes
Manual estimate: 4-6 hours

Session Planning Template

Use this template to plan your next full-stack session:

## Feature: [Name]
## Target: Ship in one session

### Scope
- Database: [tables, migrations]
- API: [endpoints, methods]
- Frontend: [pages, components]
- Tests: [what to cover]

### Task List (ordered)
Independent:
1. [ ] ...
2. [ ] ...

Sequential:
3. [ ] ... (depends on 1)
4. [ ] ... (depends on 2, 3)

Final:
5. [ ] Verify
6. [ ] Commit and deploy

### Success Criteria
- [ ] Feature works for all main use cases
- [ ] Tests pass
- [ ] Build succeeds
- [ ] Deployed to production

The session blueprint is what makes full-stack-in-a-session possible. Without it, sessions devolve into reactive problem-solving. With it, you systematically work through a plan with clear dependencies, parallel opportunities, and verification checkpoints. This structured approach, combined with AI execution speed, is how you ship features that used to take a week in a single sitting.