Fullstack Developer Consultant

A senior fullstack development agent covering complete feature delivery from database schema through API design to frontend UI, ensuring cohesive end-to-end solutions that work seamlessly across the entire stack.

When to Use This Agent

Choose Fullstack Developer when:

• Building features that span database, API, and frontend layers
• Implementing end-to-end user flows (signup, checkout, dashboards)
• Creating full CRUD operations from database to UI
• Integrating third-party services across the stack
• Prototyping full applications quickly with a single developer perspective

Consider alternatives when:

• Working on frontend-only changes (use a frontend agent)
• Working on backend-only changes (use a backend agent)
• Designing architecture without implementing (use an architecture agent)

Quick Start

Copy
# .claude/agents/fullstack-developer-consultant.yml
name: Fullstack Developer
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a senior fullstack developer. Deliver cohesive features
  spanning database, API, and frontend. Ensure consistency across
  layers: data models match API contracts match frontend types.
  Build end-to-end with proper validation, error handling, and
  testing at every layer.

Example invocation:

Copy
claude --agent fullstack-developer-consultant "Build a complete
  team invitation feature: database schema for invitations,
  REST API for sending/accepting/declining invites, email
  notification trigger, and React UI for managing invitations."

Core Concepts

Fullstack Feature Anatomy

Database Layer
  └── Schema: tables, indexes, constraints
  └── Migrations: versioned schema changes

API Layer
  └── Routes: endpoint definitions
  └── Validation: input schema (Zod/Yup)
  └── Business Logic: service functions
  └── Error Handling: consistent error responses

Frontend Layer
  └── API Client: typed fetch/axios calls
  └── State Management: React Query + local state
  └── Components: forms, lists, detail views
  └── Error UI: loading, error, empty states

Type Consistency Across Layers

Copy
// Shared types (or generated from schema)
// Database → API → Frontend must be consistent

// Database (Prisma schema)
model Invitation {
  id        String   @id @default(uuid())
  email     String
  teamId    String
  role      Role     @default(MEMBER)
  status    Status   @default(PENDING)
  expiresAt DateTime
}

// API validation (Zod)
const CreateInvitationSchema = z.object({
  email: z.string().email(),
  teamId: z.string().uuid(),
  role: z.enum(['ADMIN', 'MEMBER', 'VIEWER']),
});

// Frontend type (inferred from API)
type Invitation = z.infer<typeof InvitationSchema>;

End-to-End Feature Checklist

Layer	Requirement	Status
Database	Schema migration created and tested
Database	Indexes for common query patterns
API	Input validation with error messages
API	Authorization checks
API	Error handling with proper status codes
API	API tests (unit + integration)
Frontend	Loading, error, and empty states
Frontend	Form validation matching API validation
Frontend	Optimistic updates where appropriate
Frontend	Mobile responsive

Configuration

Parameter	Description	Default
backend_framework	Server framework	Express / Next.js API
frontend_framework	UI framework	React / Next.js
database	Primary database	PostgreSQL
orm	Database ORM	Prisma
api_style	API architecture	REST
validation_lib	Schema validation	Zod
state_management	Frontend state	React Query

Best Practices

1. Define the data model first, then derive everything from it. The database schema is the source of truth. API validation schemas should match database constraints. Frontend types should match API response shapes. When the data model changes, update all layers in the same PR. Type generation tools (Prisma generates types, Zod infers types) prevent drift between layers.

2. Implement validation at every boundary, but derive from one definition. The database enforces constraints, the API validates input, and the frontend validates before submission. But don't write three independent validation implementations. Define validation once (Zod schema) and use it in API validation, frontend form validation, and type generation. One source of truth, three enforcement points.

3. Handle every state in the frontend: loading, error, empty, and success. A component that only handles the success case creates a poor experience when data is loading, an error occurs, or the result set is empty. Design components to explicitly handle all four states. React Query's isLoading, isError, data pattern makes this natural. Users should never see a blank screen or unhandled error.

4. Test the integration between layers, not just each layer in isolation. Unit tests verify individual functions. Integration tests verify that the API correctly reads from and writes to the database. E2E tests verify that the frontend correctly calls the API and renders the response. The bugs that reach production usually live at layer boundaries, not within layers.

5. Build features incrementally: database → API → frontend. Start with the database migration and seed data. Then build the API endpoints and verify with curl or Postman. Then build the frontend against the working API. This bottom-up approach prevents building a frontend against assumptions about the API that turn out to be wrong.

Common Issues

Types drift between frontend and backend. The API returns { created_at: "..." } but the frontend type says { createdAt: "..." }. Use code generation to keep types synchronized: Prisma generates backend types, OpenAPI spec generates frontend API client types. When that's not feasible, create a shared types package in a monorepo. Manual type synchronization always diverges eventually.

Frontend validation allows data that the API rejects. This happens when frontend and backend validation are implemented independently. Share the validation schema: use Zod on both sides, or generate frontend validation from the OpenAPI spec. At minimum, ensure the frontend validation is a superset of the backend validation—the frontend can be more permissive (the backend catches errors) but should never be more restrictive (confusing UX).

Feature works in development but fails in production due to environment differences. Development uses localhost URLs, test databases, and permissive CORS settings. Production uses different API endpoints, connection strings, and strict security. Use environment variables for all environment-specific values, test with production-like configuration in staging, and verify CORS, CSP, and authentication in a staging environment before deploying.