AI made writing the code easy. Running it in production is still hard.

Prod Forge is an open-source reference that shows how to build and operate a production-ready system: AI-assisted development, quality gates, CI/CD, infrastructure, observability, migrations, and rollback.

The implementation is based on a simple Todo API, but the architecture follows patterns used in real production systems at scale.

Every major technical decision is documented and explained.

---

Project structure

Repository	Description
Frontend	React Web and React Mobile apps + Design System
Backend	NestJS API - the main guide
Infrastructure	Terraform on AWS

Stack

Layer	Tools
Web Client	React · Vite · Redux Toolkit · Tailwind CSS · NX
Deploy	AWS S3 · CloudFront · ECR · ECS
Backend	NestJS · Prisma · PostgreSQL · Redis · Docker
Infrastructure	AWS · RDS · ElasticCache
Observability	Prometheus · Grafana · Loki · Promtail
Quality	ESLint · Prettier · Husky · Commitlint · CI/CD

Table of contents

• 1. Repository Strategy
  • Why Frontend Projects Use a Monorepo
  • What Gets Shared Across Clients
  • What Belongs in a Frontend Monorepo
  • Structure

• 2. Architecture Decisions
  • Choosing the Right Architecture
  • Frontend Architecture
    • Feature Sliced Design
    • Feature-based Approach

• 3. Development Workflow
  • Task Management
  • Git Flow
    • Branch Naming Convention
    • Commit Conventions
  • Feature Workflow
  • Bug Fixing Workflow
  • Code Review
  • Squash Merge Strategy
  • Squash Merge Workflow
  • Why This Matters

• 4. AI-Assisted Development
  • Quality Gates First
  • Architecture Before Generation
  • Workflow
    • Input Modes
    • Plan, Then Implement
    • Save Your Prompts
  • Project Knowledge Files
    • MEMORY.md
    • REVIEW.md
    • docs/
    • Skills
  • Pre-Hooks
    • Protected files (Edit|Write)
    • Blocked commands (Bash)
  • Task Decomposition
  • Common AI Problems
  • Cost Optimization
  • Quality Control
    • Commit Frequently
    • Validate Edge Cases
    • Mandatory Code Review
    • Never Trust AI Blindly
  • Recommended Workflow

• 5. Code Quality
  • Layer 1. Code Formatting And Consistency
  • Layer 2. Static Analysis With ESLint
  • Layer 3. Pre-commit Protection
  • Layer 4. Commitlint Configuration
  • Layer 5. Continuous Integration Checks
  • Layer 6. Dependency Locking

• 6. Styles Management
  • Design Tokens
  • Storybook
  • Tailwind CSS
  • Accessibility

• 7. Assets Management
  • When this Matters
  • How it Works
  • Local Development
  • What Belongs in Assets

Package scope

All packages use the @prod-forge-todolist-frontend/ scope:

• @prod-forge-todolist-frontend/core
• @prod-forge-todolist-frontend/ui-web
• @prod-forge-todolist-frontend/design-tokens
• @prod-forge-todolist-frontend/web-client (private, not published)

NX

This monorepo uses NX for task orchestration (build caching, dependency-aware task ordering). Each package has a project.json that declares its targets.

# Run a specific target in one project
npx nx test core
npx nx storybook ui-web
npx nx build web-client

# Run a target across all projects
npx nx run-many -t test

TypeScript path aliases

tsconfig.base.json at the root defines path aliases so TypeScript resolves workspace packages:

{
  "@prod-forge-todolist-frontend/core": ["packages/core/src/index.ts"],
  "@prod-forge-todolist-frontend/ui-web": ["packages/ui-web/src/index.ts"]
}

Vite configs in each package add matching resolve.alias entries so Vite resolves the same paths during dev and test.

---

Contributing

We welcome any kind of contribution, please read the guidelines:

CONTRIBUTING

The MIT License

LICENSE