Architecture
Force a structured scale, team, timeline, and constraints interview before your agent recommends MVP, modular, or distributed architecture patterns.
Overview
Architecture is a journey-wide agent skill that structures scale, team, and constraint discovery before recommending MVP, modular, or distributed system designs—usable whenever a solo builder needs to choose a stack befo
Install
npx skills add https://github.com/davila7/claude-code-templates --skill architectureWhat is this skill?
- Mandatory context discovery: ask user about scale, team, timeline, domain, and constraints before any architecture sugge
- Five-tier question hierarchy (users, data volume, transaction rate, team shape, compliance)
- Project classification matrix mapping MVP, SaaS, and Enterprise to simple, modular, or distributed architectures
- Worked example YAML for MVP e-commerce (solo, fast market) with explicit requirement thresholds
- Pattern guidance: minimal vs selective vs comprehensive patterns by product class
- Five mandatory discovery dimensions: scale, team, timeline, domain, constraints
- Three-column classification matrix: MVP, SaaS, Enterprise
Adoption & trust: 515 installs on skills.sh; 27.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent suggests trendy architectures without knowing user scale, team size, or timeline, so you risk over-engineering an MVP or under-building a growing SaaS.
Who is it for?
Indie founders and solo developers deciding between monolith, modular monolith, or services when scoping a new product or major refactor.
Skip if: Teams with an approved architecture decision record and frozen stack who only need line-level implementation help.
When should I use this skill?
Before suggesting any architecture, stack, or distributed pattern to the user.
What do I get? / Deliverables
You get a classification-aligned architecture recommendation grounded in answered scale, team, domain, and constraint questions plus matrix-matched pattern depth.
- Answered scale, team, timeline, domain, and constraint profile
- Matrix-aligned architecture recommendation with pattern depth (minimal, selective, or comprehensive)
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Interview scale and timeline before locking a monolith versus services split for a paid beta.
Map a 1K–100K user SaaS profile to modular NestJS-style boundaries instead of premature microservices.
Re-run constraint questions when transaction rate spikes force read replicas or caching layers.
Classify enterprise compliance and legacy integration needs before proposing a distributed topology.
Clarify CRUD versus real-time domain complexity before estimating build cost for a new product idea.
How it compares
Use instead of free-form “design my system” prompts when you want enforced discovery questions and an MVP/SaaS/Enterprise matrix before patterns are named.
Common Questions / FAQ
Who is architecture for?
Solo and indie builders using Claude Code or similar agents who need disciplined architecture conversations before coding backends, APIs, or SaaS products.
When should I use architecture?
In Validate to scope stack and patterns; in Build when choosing modules or services; in Ship or Operate when scaling users or data forces a redesign; anytime before the agent proposes microservices or enterprise patterns.
Is architecture safe to install?
It is documentation and process guidance only; check this page’s Security Audits panel for package provenance, then review any generated designs before changing production infra.
SKILL.md
READMESKILL.md - Architecture
# Context Discovery > Before suggesting any architecture, gather context. ## Question Hierarchy (Ask User FIRST) 1. **Scale** - How many users? (10, 1K, 100K, 1M+) - Data volume? (MB, GB, TB) - Transaction rate? (per second/minute) 2. **Team** - Solo developer or team? - Team size and expertise? - Distributed or co-located? 3. **Timeline** - MVP/Prototype or long-term product? - Time to market pressure? 4. **Domain** - CRUD-heavy or business logic complex? - Real-time requirements? - Compliance/regulations? 5. **Constraints** - Budget limitations? - Legacy systems to integrate? - Technology stack preferences? ## Project Classification Matrix ``` MVP SaaS Enterprise ┌─────────────────────────────────────────────────────────────┐ │ Scale │ <1K │ 1K-100K │ 100K+ │ │ Team │ Solo │ 2-10 │ 10+ │ │ Timeline │ Fast (weeks) │ Medium (months)│ Long (years)│ │ Architecture │ Simple │ Modular │ Distributed │ │ Patterns │ Minimal │ Selective │ Comprehensive│ │ Example │ Next.js API │ NestJS │ Microservices│ └─────────────────────────────────────────────────────────────┘ ``` # Architecture Examples > Real-world architecture decisions by project type. --- ## Example 1: MVP E-commerce (Solo Developer) ```yaml Requirements: - <1000 users initially - Solo developer - Fast to market (8 weeks) - Budget-conscious Architecture Decisions: App Structure: Monolith (simpler for solo) Framework: Next.js (full-stack, fast) Data Layer: Prisma direct (no over-abstraction) Authentication: JWT (simpler than OAuth) Payment: Stripe (hosted solution) Database: PostgreSQL (ACID for orders) Trade-offs Accepted: - Monolith → Can't scale independently (team doesn't justify it) - No Repository → Less testable (simple CRUD doesn't need it) - JWT → No social login initially (can add later) Future Migration Path: - Users > 10K → Extract payment service - Team > 3 → Add Repository pattern - Social login requested → Add OAuth ``` --- ## Example 2: SaaS Product (5-10 Developers) ```yaml Requirements: - 1K-100K users - 5-10 developers - Long-term (12+ months) - Multiple domains (billing, users, core) Architecture Decisions: App Structure: Modular Monolith (team size optimal) Framework: NestJS (modular by design) Data Layer: Repository pattern (testing, flexibility) Domain Model: Partial DDD (rich entities) Authentication: OAuth + JWT Caching: Redis Database: PostgreSQL Trade-offs Accepted: - Modular Monolith → Some module coupling (microservices not justified) - Partial DDD → No full aggregates (no domain experts) - RabbitMQ later → Initial synchronous (add when proven needed) Migration Path: - Team > 10 → Consider microservices - Domains conflict → Extract bounded contexts - Read performance issues → Add CQRS ``` --- ## Example 3: Enterprise (100K+ Users) ```yaml Requirements: - 100K+ users - 10+ developers - Multiple business domains - Different scaling needs - 24/7 availability Architecture Decisions: App Structure: Microservices (independent scale) API Gateway: Kong/AWS API GW Domain Model: Full DDD Consistency: Event-driven (eventual OK) Message Bus: Kafka Authentication: OAuth + SAML (enterprise SSO) Database: Polyglot (right tool per job) CQRS: Selected services Operational Requirements: - Service mesh (Istio/Linkerd) - Distributed tracing (Jaeger/Tempo) - Centralized logging (ELK/Loki) - Circuit breakers (Resilience4j) - Kubernetes/Helm ``` # Pattern Selection Guidelines > Decision trees for choosing architectural patterns. ## Main Decision Tree ``` START: What's your MAIN concern? ┌─ Data Access Complexity? │ ├─ HIGH (complex queries, testing needed) │ │ → Repository Pattern + Unit of Work │ │ VALIDATE: Will data source change frequentl