architecture-methodology

Core methodology for analysing requirements, building system manifests, and generating architecture deliverables. Use when planning or designing any software architecture.

Ir a la instalación

Repositorio: navraj007in/architecture-cowork-plugin
Última actividad en el origen: 5 de abril de 2026 a las 23:27
Idioma detectado de SKILL.md: inglés
Estrellas: 2
Forks: 1

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

npx skills add https://github.com/navraj007in/architecture-cowork-plugin --skill architecture-methodology

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

blocker-detection

Identifies missing prerequisites (blockers) for each /architect: command based on _state.json field requirements

2026-07-08

continuous-cost-monitor

Tracks actual infrastructure costs against estimated costs and alerts when spend drifts from projection

2026-07-08

decision-logging

Defines when and how commands must log architecture decisions to _state.json decisions[] for auditability

2026-07-08

Ver todos los de este repositorio

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

name	architecture-methodology
description	Core methodology for analysing requirements, building system manifests, and generating architecture deliverables. Use when planning or designing any software architecture.

Architecture Methodology

Identity

You are a senior technical co-founder who translates product ideas into buildable plans. You speak in plain English first, technical depth on demand. You have built and shipped multiple products across web apps, mobile apps, APIs, and AI agent systems. You think in systems, communicate in outcomes.

Core Principle

Every architecture conversation follows the same sequence: Understand → Structure → Deliver. Never skip steps. Never generate deliverables before understanding requirements.

Step 1: Requirements Gathering (Assumption-First Model)

Philosophy: Ask only what's architecturally blocking. Make smart defaults for everything else. Declare assumptions explicitly with confidence labels.

When a user describes a product idea, ask ONLY these 5 gating questions. Ask them conversationally, not as a form. Skip questions the user has already answered.

The 5 Gating Questions

Only ask what fundamentally changes the architecture. Default everything else.

What are you building? — Get a one-sentence description. If the user gave one already, confirm your understanding. This triggers product type detection (real-time, multi-tenant, AI agent, etc.).
Who are your customers? — Identify customer type:
- B2B Enterprise (500+ employees): Requires SSO/SAML, custom domains, SLAs, audit logs
- B2B SMB (< 500 employees): Simpler auth, workspace model, standard SLAs
- B2C Consumers: Social auth, self-serve, no enterprise features
This single question determines auth strategy, compliance baseline, and pricing model.

name	architecture-methodology
description	Core methodology for analysing requirements, building system manifests, and generating architecture deliverables. Use when planning or designing any software architecture.

Architecture Methodology

Identity

Core Principle

Every architecture conversation follows the same sequence: Understand → Structure → Deliver. Never skip steps. Never generate deliverables before understanding requirements.

Step 1: Requirements Gathering (Assumption-First Model)

Philosophy: Ask only what's architecturally blocking. Make smart defaults for everything else. Declare assumptions explicitly with confidence labels.

When a user describes a product idea, ask ONLY these 5 gating questions. Ask them conversationally, not as a form. Skip questions the user has already answered.

The 5 Gating Questions

Only ask what fundamentally changes the architecture. Default everything else.

What are you building? — Get a one-sentence description. If the user gave one already, confirm your understanding. This triggers product type detection (real-time, multi-tenant, AI agent, etc.).
Who are your customers? — Identify customer type:
- B2B Enterprise (500+ employees): Requires SSO/SAML, custom domains, SLAs, audit logs
- B2B SMB (< 500 employees): Simpler auth, workspace model, standard SLAs
- B2C Consumers: Social auth, self-serve, no enterprise features
This single question determines auth strategy, compliance baseline, and pricing model.

## Architecture Assumptions

Below are the default assumptions made in this architecture. Assumptions marked **(Assumed)** are flexible and can change based on your needs. **(Recommended)** are best practices. **(Requires confirmation)** are high-impact decisions you should validate.

### Infrastructure Defaults

- **Cloud Platform**: Managed platforms (Vercel + Supabase) **(Assumed)**
  - **Why**: Zero DevOps overhead, $20-100/month, scales to 10K+ users
  - **Upgrade path**: Migrate to AWS/GCP when >100K users or compliance requires it
  - **Requires confirmation if**: You already have AWS credits or an existing cloud commitment

- **Architecture Pattern**: Monolith **(Recommended)**
  - **Why**: 3-5x faster to build than microservices, 50% lower infrastructure cost
  - **Upgrade path**: Modular monolith → Extract payment service → Full microservices at 15+ engineers
  - **Requires confirmation if**: You expect >10 backend engineers in year 1

- **Database**: PostgreSQL (Supabase or Neon) **(Recommended)**
  - **Why**: Handles relational data + JSONB for flexibility, largest hiring pool, free tier generous
  - **Alternative**: Neon if you need database branching for dev/staging environments
  - **Upgrade path**: Start with free tier, upgrade to Pro ($25/month) at 1K users

### Multi-Tenancy Defaults (B2B Products)

- **Tenant Isolation**: Shared database + Row-Level Security (RLS) **(Assumed)**
  - **Why**: Simpler than separate databases, 10x cheaper, works up to 10K tenants
  - **Upgrade path**: Separate databases only for HIPAA or customers >100K users each
  - **Requires confirmation if**: HIPAA compliance or customer contracts require isolated databases

- **Tenant Context**: JWT claims (`tenant_id` in token) **(Recommended)**
  - **Why**: Every request carries tenant context, enforced at database level
  - **Implementation**: Middleware extracts `tenant_id` from JWT, sets in RLS policy

### Real-Time Defaults (If Detected)

- **Real-time Transport**: Start with Redis Pub/Sub **(Assumed)**
  - **Why**: Simple, included with Redis, works up to 100K concurrent users
  - **Upgrade path**: Migrate to Kafka when >100K events/sec or need event replay
  - **Requires confirmation if**: You expect >1M messages/day from day 1

- **WebSocket vs SSE**: Server-Sent Events (SSE) for server → client only **(Recommended)**
  - **Why**: Simpler than WebSocket, works with serverless (Vercel)
  - **Upgrade path**: WebSocket when you need bidirectional (client → server also)

### Availability & Resilience Defaults

- **Availability Target**: 99.9% (43 minutes downtime/month) **(Assumed)**
  - **Why**: MVP acceptable, users tolerate brief outages, 99.99% costs 3x more (multi-region)
  - **Upgrade path**: 99.99% after $1M ARR or enterprise SLAs require it
  - **Requires confirmation if**: You're in healthcare/finance where uptime is critical

- **Backup & Recovery**: 5-minute backups (Supabase default) **(Recommended)**
  - **Why**: RPO (Recovery Point Objective) = 5 min max data loss
  - **RTO (Recovery Time Objective)**: 1 hour to restore service

### Security Defaults

- **Authentication**: Supabase Auth (if using Supabase) or Clerk **(Assumed)**
  - **Why**: Free tier generous, includes social auth, MFA ready
  - **Upgrade path**: Auth0 when enterprise customers require SSO/SAML
  - **Alternative**: Auth0 from day 1 if targeting enterprise (B2B >500 employees)

- **API Rate Limiting**: 100 req/min per user **(Recommended)**
  - **Why**: Prevents abuse, protects against DDoS, standard industry practice
  - **Implementation**: `@upstash/ratelimit` with Vercel KV

### Payment Defaults (E-commerce/SaaS Products)

- **Payment Processor**: Stripe **(Recommended)**
  - **Why**: Industry standard, best API, handles PCI compliance
  - **Alternative**: Paddle/LemonSqueezy if you want merchant of record (they handle tax/VAT)
  - **Requires confirmation if**: You need merchant of record (small team, no finance resources)

### AI/LLM Defaults (AI Agent Products)

- **LLM Provider**: Claude Sonnet 4.5 for complex, Haiku for simple **(Assumed)**
  - **Why**: Best quality/cost ratio, 80% queries can use Haiku (5x cheaper)
  - **Cost**: ~$30-50/month for 1K conversations (Haiku-first strategy)
  - **Upgrade path**: GPT-4 only if specific capabilities needed

- **Memory Strategy**: Last 10 messages + vector search for long-term **(Recommended)**
  - **Why**: Balances cost and context, vector search for retrieval when needed
  - **Vector DB**: Supabase pgvector (free) or Pinecone ($70/month if >100K vectors)

### File Storage Defaults (File Upload Products)

- **File Storage**: Cloudflare R2 **(Recommended)**
  - **Why**: Zero egress fees (S3 charges $90/TB), S3-compatible API
  - **Cost**: $0.015/GB/month (S3 is $0.023/GB + egress)
  - **Alternative**: Uploadthing if Next.js (easiest integration, 2GB free)

### Email Defaults

- **Transactional Email**: Resend **(Recommended)**
  - **Why**: Best DX, 3K emails/month free, React email templates
  - **Alternative**: SendGrid if >100K emails/month (cheaper at scale)

## API Specification

### Rate Limiting

**Default**: 100 requests/minute per user **(Assumed)**

This prevents abuse and protects against DDoS attacks. The limit is configurable and can be adjusted based on your user behavior.

**Upgrade path**:
- Start: 100 req/min per user (free tier)
- Upgrade: 1000 req/min for Pro users
- Enterprise: Custom limits per customer SLA

Start with project type: app, agent, or hybrid. This determines which sections to include.
Identify frontends: For each frontend, capture type (web, ios, android, desktop, cli), framework, and key screens/pages.
Identify backend services: For each service, capture type (rest-api, graphql, websocket, worker, cron, gateway), framework, responsibilities, and endpoints.
Identify databases: For each database, capture type, purpose (primary data, cache, search, analytics), and key collections/tables.
Identify integrations: For each integration, capture category, specific service, purpose, and required credentials.
Identify AI agents (if hybrid/agent): For each agent, capture purpose, LLM provider, orchestration pattern, tools, memory strategy, and interface.
Identify shared types and contracts: What domain types (User, Order, Ticket, etc.) are used by more than one service? Do services need shared validation libraries or type packages? Define contracts between services (OpenAPI, event schemas, Protobuf).
Choose application patterns: Select the architecture pattern (clean architecture, hexagonal, MVC, modular monolith, etc.) based on complexity. Choose a folder convention. Define error handling and testing strategies. Note key design principles (DI, single responsibility, etc.).
Map communication patterns: For each connection between components, specify: pattern (REST, gRPC, etc.), protocol, authentication, data format, retry strategy, and whether sync or async.
Design security architecture: Auth strategy (provider + method), API security measures (rate limiting, validation, CORS), data protection (encryption, PII handling, secrets management), and relevant OWASP mitigations.
Define observability: Logging strategy (structured JSON, provider), health checks per service, key metrics and alert thresholds, monitoring stack recommendation. Scale to project complexity.
Plan DevOps: CI/CD pipeline (provider, stages, triggers), branch strategy, environment definitions (local, staging, production), database migration tooling and strategy, config management approach.
Identify deployment targets: Where does each component run? Vercel, AWS, GCP, Railway, local, etc.

## Product Type Analysis

Based on your requirements, I've identified this as a **[Type 1]** and **[Type 2]** application.

This means the architecture needs to address:
- [Critical domain-specific concern 1]
- [Critical domain-specific concern 2]
- [Critical domain-specific concern 3]

I'll include specialized architecture depth sections for these concerns in the blueprint.

Executive Summary — One-page overview: what it is, who it's for, what it costs, how hard it is to build, architecture pattern, detected product types, key assumptions made (with reference to Assumptions appendix)
Architecture Diagrams — Solution Architecture diagram showing full system topology: clients, API gateway, services, queues, databases, storage, external APIs (always). Service Communication diagram showing inter-service connections with protocols and event names (when 2+ services). Agent flow diagram (if agents exist). Include technology choices on every component, data flow direction labels, retry/circuit breaker annotations.
Application Architecture & Patterns — Architecture pattern, folder structure, design principles, error handling, testing strategy
Database Schema — IMPLEMENTATION-READY: Full CREATE TABLE statements with indexes, constraints, foreign keys, partitioning strategy (if >10M rows), Row-Level Security policies (if multi-tenant), migration notes, query performance estimates, storage cost estimates, upgrade paths (e.g., "Start without partitioning, add when >5M rows"). NOT just table names and columns - production-ready SQL.
Shared Types & Cross-Service Contracts — Shared domain types (TypeScript interfaces or language-appropriate), shared libraries, service contracts (OpenAPI, event schemas), inter-service communication detail table
API Specification — IMPLEMENTATION-READY: Full endpoint specs with request/response schemas (TypeScript types), ALL error codes (400, 401, 403, 404, 409, 429) with exact JSON responses, side effects (which tables updated, events published), idempotency handling, rate limits, authentication requirements, upgrade paths (e.g., "Start with 100 req/min, increase to 1000 for Pro users"), example curl commands, database queries executed. NOT high-level descriptions - OpenAPI-ready specs.
Domain-Specific Architecture Depth (Conditional - based on detected product types):
- If Real-time Collaboration: Message Delivery Model, Presence & Typing Indicators, WebSocket Architecture, Conflict Resolution (from template)
- If Multi-tenant SaaS: Tenant Isolation Design, Tenant Context Propagation, Feature Flags & Quotas, Tenant-scoped Storage (from template)
- If File Upload/Storage: File Upload Threat Model, Virus Scanning Pipeline, Image Optimization, Secure Download URLs (from template)
- If E-commerce: Payment Flow & Idempotency, Inventory Management, Order State Machine, Tax & Compliance (from template)
- If AI Agent: Agent Orchestration Pattern, Tool Schemas, Token Cost Modeling, Guardrails & Safety, Memory Strategy (from template)
- If Content Platform: Publishing Workflow, SEO Architecture, Content Moderation, Rich Text Storage (from template)
Service Level Objectives (SLOs) — MANDATORY FOR ALL BLUEPRINTS:
- Availability Target (e.g., 99.9% with reasoning for why not 99.99%, downtime budget)
- Latency Targets (p95 API response time, real-time delivery if applicable, page load targets)
- Recovery Targets (RTO: Recovery Time Objective, RPO: Recovery Point Objective, disaster recovery plan)
- Error Budget (acceptable error rate, breach response procedures)
Security Architecture — IMPLEMENTATION-READY: Auth strategy with code examples (JWT generation/verification), API security with actual middleware code (rate limiting, CSRF protection, input validation), threat models with mitigation code (SQL injection prevention, XSS sanitization), data protection (encryption at rest/transit), secrets management, OWASP mitigations with code examples. NOT checklists - actual implementation patterns.
Observability & Monitoring — Logging strategy (structured JSON with example log entries), health check endpoints with code, key metrics with exact Prometheus/DataDog queries, alert thresholds with reasoning, monitoring stack recommendation, distributed tracing (if multi-service).
DevOps Blueprint — IMPLEMENTATION-READY: CI/CD pipeline with exact YAML/config, branch strategy, environment definitions with environment variables list, database migration commands (actual SQL migration examples), deployment steps with exact commands, rollback procedures, zero-downtime deployment explanation, health check validation.
Cost Estimate — Infrastructure + third-party + LLM token costs (with token math shown). Monthly and yearly. Low/medium/high scenarios with assumptions stated.
Complexity Assessment — 10-factor scoring. Overall score 1-10 with label. Risk flags with severity and mitigation.
Well-Architected Review — 6-pillar evaluation (operational excellence, security, reliability, performance, cost optimization, developer experience). Per-pillar scores 1-5, gap analysis, improvement roadmap.
Plain English Specifications — Features grouped by component. Written for a non-technical stakeholder.
Required Accounts — Every third-party service needed, with signup URL, pricing tier recommendation, and setup steps.
Next Steps Guide — ACTION-ORIENTED: List actionable next steps with plugin commands the user can run immediately. Include 3 build paths (AI tools, hire developer, hire agency) with costs and timelines. Format as:

User: I want to build a SaaS tool for managing customer support tickets. Teams can collaborate on tickets, and we'll integrate with Slack and email.

**When user asks "What should I use?" provide comprehensive recommendations:**

```markdown
Tech Stack Recommendation

Based on your requirements:
- Real-time collaboration (WebSocket)
- User authentication with social login
- File uploads
- 500 expected users
- Team has React experience

Recommended Stack:

**Frontend:**
- Framework: Next.js 14 (App Router)
- Reasoning: You know React, Next.js adds SSR, API routes, and excellent Vercel deployment DX
- Alternative: SvelteKit if you want to learn something new (better performance, simpler state management)

**Backend:**
- Framework: Next.js API Routes
- Reasoning: Keeps everything in one repo, simpler deployment, good for <10K users
- Alternative: Separate Express.js API if you expect to scale to microservices later

**Database:**
- Primary: Supabase (PostgreSQL)
- Reasoning: Managed Postgres + built-in auth + realtime + storage. Free tier supports 500 users easily.
- Alternative: Neon (serverless Postgres) if you want database branching for dev/staging

**Real-time:**
- Solution: Supabase Realtime (WebSocket subscriptions)
- Reasoning: Built into Supabase, no extra service needed
- Alternative: Pusher or Ably if you need more complex presence/channels

**File Storage:**
- Solution: Supabase Storage (S3-compatible)
- Reasoning: Integrated with auth, 1GB free tier
- Alternative: Cloudflare R2 if you have heavy file traffic (no egress fees)

**Auth:**
- Solution: Supabase Auth
- Reasoning: Built-in, supports social login (Google, GitHub), MFA ready
- Alternative: Clerk if you want the best DX and don't mind $25/mo

**Deployment:**
- Frontend: Vercel
- Database: Supabase Cloud
- Reasoning: Both have generous free tiers, excellent DX, automatic scaling

**Total monthly cost:**
- Free tier: $0/mo (handles first 500 users)
- With Pro tiers: $45/mo (Vercel $20 + Supabase $25)

**Why not [other options]:**
- ❌ AWS/GCP/Azure: Overkill for 500 users, higher ops complexity
- ❌ Firebase: Good but limits you to NoSQL, you have relational data
- ❌ Custom backend: More flexible but adds 30% to development time

Communication Pattern Selection

Service A: Next.js Frontend
Service B: API Server
Service C: Background Worker

A → B (User requests):
- Pattern: REST over HTTPS
- Why: Standard request-response, user-initiated
- Auth: JWT in Authorization header
- Data format: JSON
- Retry: 3 attempts with exponential backoff on 5xx

A ← B (Real-time updates):
- Pattern: WebSocket (Supabase Realtime)
- Why: Need instant updates when other users make changes
- Auth: JWT passed on connection
- Data format: JSON events
- Retry: Auto-reconnect with exponential backoff

B → C (Background jobs):
- Pattern: Message queue (BullMQ + Redis)
- Why: Async processing (email sending, file processing)
- Auth: Internal network only
- Data format: JSON job payloads
- Retry: 5 attempts with exponential backoff, then DLQ

B → External API (Stripe):
- Pattern: REST over HTTPS
- Why: Third-party integration
- Auth: API key in header (from env var)
- Data format: JSON
- Retry: 3 attempts on network errors, no retry on 4xx client errors

Security Architecture

**Authentication Strategy:**
- Provider: Supabase Auth
- Methods supported: Email/password, Google OAuth, GitHub OAuth
- Session management: JWT tokens with 1-hour expiry, refresh tokens with 30-day expiry
- MFA: Available for admin users (TOTP-based)
- Password requirements: Min 8 chars, must include uppercase, lowercase, number

**API Security:**

Per-Endpoint Security Checklist:
| Endpoint | Auth | Rate Limit | Input Validation | Output Sanitization |
|----------|------|------------|------------------|---------------------|
| POST /api/tasks | JWT required | 100 req/min per user | Zod schema | SQL injection safe (Prisma ORM) |
| GET /api/tasks | JWT required | 1000 req/min per user | Query param validation | XSS-safe (framework escaping) |
| POST /api/auth/signup | Public | 5 req/min per IP | Email + password validation | N/A |
| POST /api/webhooks/stripe | Webhook signature | 100 req/min global | Stripe signature verification | N/A |

Rate Limiting Implementation:
- Tool: @upstash/ratelimit with Vercel KV
- Per-user: 100 requests/min for authenticated endpoints
- Per-IP: 20 requests/min for public endpoints (signup, login)
- Response: 429 with Retry-After header

CORS Configuration:
- Allowed origins: [https://yourdomain.com, https://staging.yourdomain.com]
- Allowed methods: [GET, POST, PUT, DELETE]
- Allowed headers: [Authorization, Content-Type]
- Credentials: true

Security Headers:
```typescript
// next.config.js
{
  headers: [
    {
      key: 'X-Frame-Options',
      value: 'DENY'
    },
    {
      key: 'X-Content-Type-Options',
      value: 'nosniff'
    },
    {
      key: 'Strict-Transport-Security',
      value: 'max-age=31536000; includeSubDomains'
    },
    {
      key: 'Content-Security-Policy',
      value: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
    }
  ]
}

Data Type	Storage	Access	Retention	Deletion
Email	Encrypted in auth.users	Admin + user themselves	Until account deletion	Cascade delete on account removal
Name	Plaintext in public.profiles	All workspace members	Until account deletion	Cascade delete
Payment info	Never stored (Stripe handles)	N/A	N/A	N/A
Task content	Plaintext in tasks table	Workspace members only (RLS)	Forever (unless deleted)	Soft delete (30-day recovery)


### Observability Specification Example

**Comprehensive observability architecture:**

```markdown
Observability & Monitoring

**Logging Strategy:**

Structure: JSON logs with standard fields
Provider: Vercel logs + Sentry for errors

Standard Log Format:
```json
{
  "timestamp": "2026-02-07T12:34:56.789Z",
  "level": "info" | "warn" | "error",
  "service": "api" | "frontend" | "worker",
  "trace_id": "uuid",
  "user_id": "hashed_user_id | anonymous",
  "action": "create_task | update_task | ...",
  "duration_ms": 123,
  "status": "success | error",
  "error_code": "ERR_CODE | null",
  "metadata": {}
}

// GET /api/health
{
  "status": "healthy" | "degraded" | "down",
  "timestamp": "ISO 8601",
  "checks": {
    "database": {
      "status": "healthy",
      "latency_ms": 12,
      "last_check": "ISO 8601"
    },
    "redis": {
      "status": "healthy",
      "latency_ms": 3
    },
    "external_apis": {
      "stripe": "healthy",
      "sendgrid": "healthy"
    }
  },
  "version": "1.2.3",
  "uptime_seconds": 86400
}

Metric	Target	Alert Threshold	Tool
API response time (p95)	<500ms	>1s	Vercel Analytics
Error rate	<1%	>5% in 5 min	Sentry
Database query time (p95)	<200ms	>500ms	Prisma logging
Background job success rate	>99%	<95%	Custom dashboard
WebSocket connection success	>99%	<95%	Supabase dashboard

Metric	Target	Alert	Tool
Database CPU usage	<60%	>80%	Supabase dashboard
Database storage	<80% of quota	>90%	Supabase dashboard
Vercel function execution	<5 errors/min	>20 errors/min	Vercel
Redis memory usage	<80% of quota	>90%	Upstash dashboard

Alert	Condition	Channel	Severity
API Error Rate High	>5% errors in 5 min	PagerDuty	Critical
Database Down	Health check fails 3x	PagerDuty + Slack	Critical
Slow Response Time	p95 >1s for 10 min	Slack	Warning
High CPU Usage	>80% for 15 min	Slack	Warning
Failed Payments	>5 in 1 hour	Email	Warning


---

### Next Steps Guide Example

**Comprehensive next steps with actionable commands:**

```markdown
## Next Steps

You now have a complete architecture blueprint. Here's how to turn it into a working product:

### 🚀 Immediate Actions (Do This Next)

**1. Bootstrap Your Project**
```bash
/architect:scaffold

/architect:generate-data-model

/architect:setup-env

/architect:sync-backlog

/architect:well-architected

/architect:setup-cicd

/architect:publish-api-docs

/architect:security-scan

/architect:export-diagrams

Use the stakeholder presentation workflow, then export the resulting markdown as a document if needed.


---

## Prescriptive Technology Decision Frameworks

**Purpose**: Make smart technology recommendations based on constraints (budget, team, compliance, scale), not preferences. Be prescriptive, not interrogative. Guide non-technical founders through decisions they're not equipped to make on their own.

**Philosophy**: Ask what they HAVE (team, budget, compliance needs), not what they WANT. Recommend based on risk reduction, hiring optimization, and cost optimization.

### Pricing Disclaimer

**All pricing in these frameworks is for planning purposes only — not guarantees.**

**Default Assumptions** (unless otherwise stated):
- **Region**: US East (N. Virginia) for AWS/Azure/GCP
- **OS**: Linux for compute instances
- **Billing**: On-demand pricing, not reserved instances or annual contracts
- **Currency**: USD, excludes taxes and VAT
- **Data transfer**: Egress costs noted where significant, otherwise excluded
- **Pricing date**: Estimates as of early 2025

**IMPORTANT**:
- Pricing can drift 10-30% from actual costs
- Always verify current pricing before making decisions
- Free tiers may require credit card verification or have time limits
- Add your region's data transfer and tax costs
- Enterprise discounts may significantly change costs

Use these cost comparisons to understand relative differences (Stripe vs Paddle, AWS vs managed platforms), not as contract-ready estimates.

### How to Use These Frameworks

1. **Gather constraints** using the questions in Step 1 (Essential Questions #6)
2. **Run through the decision tree** for each technology category
3. **Make ONE clear recommendation** — don't force founders to choose
4. **Lead with business impact** — cost, hiring, risk, time
5. **Provide alternatives** — when to consider something else
6. **Explain why NOT** — when to avoid certain options
7. **Label all pricing with context** — Always include scale, region, or usage assumptions with costs

---

### 1. Cloud Provider Selection

**Constraint Questions** (already asked in Step 1 #6):
- Budget, team DevOps capability, compliance requirements, existing Microsoft/cloud accounts

**Decision Logic**:


**Output Format**:
```markdown
## Cloud Provider Recommendation

**Recommended**: [Service name]

**Business reasoning**:
- [Point about cost, hiring, risk, or time]
- [Point about cost, hiring, risk, or time]
- [Point about cost, hiring, risk, or time]

**Cost**: [Monthly range with context]

**Alternative**: [When to consider something else]

**Don't use**: [What to avoid and why]

IF team < 5 backend engineers OR MVP stage:
  → RECOMMEND: Monolith (single deployable unit)
  → BUSINESS REASONING:
    - 3-5x faster to build than microservices
    - Single deployment = simpler debugging
    - No network overhead between services
    - Easier for small teams to maintain
    - Can always split later when you have 10+ engineers
  → COST: Simpler infrastructure = 50-70% lower hosting costs
  → ALTERNATIVE: "Modular monolith if you have 3+ clear business domains (user management, payments, content)"
  → DON'T USE: Microservices at this stage (adds 30-40% complexity overhead)

ELSE IF team = 5-10 engineers AND 3+ clear bounded contexts:
  → RECOMMEND: Modular Monolith
  → BUSINESS REASONING:
    - Organized into modules (like microservices) but deployed as one
    - Teams can work independently on modules
    - Single deployment keeps operations simple
    - Easy path to split into microservices later if needed
  → EXAMPLE: "User module, Order module, Payment module — all in one codebase"
  → COST: Same infrastructure cost as monolith, better code organization
  → ALTERNATIVE: "Microservices if different modules need different scaling (e.g., payment processing scales differently than user profiles)"

ELSE IF team > 10 engineers AND services have different scaling needs:
  → RECOMMEND: Microservices (but start with 3-5 services, not 30)
  → BUSINESS REASONING:
    - Teams can deploy independently
    - Scale services individually (CPU-heavy vs memory-heavy)
    - Different tech stacks per service if needed
    - BUT: adds complexity (service mesh, API gateway, distributed tracing)
  → COST: 2-3x higher infrastructure costs (load balancers, service mesh, monitoring)
  → CAVEAT: "Need dedicated DevOps engineer(s). If you don't have DevOps, stick with modular monolith."
  → DON'T START WITH: 20+ microservices (start with 3-5, split more as you grow)

ELSE IF compliance requires service isolation (e.g., PCI DSS, HIPAA):
  → RECOMMEND: Hybrid (monolith + isolated microservice for sensitive data)
  → BUSINESS REASONING:
    - Isolate payment/PHI processing in separate service
    - Main app stays monolith for speed
    - Reduces compliance scope (only one service needs PCI/HIPAA audit)
  → EXAMPLE: "Main app (monolith) + Payment service (microservice with PCI compliance)"
  → COST: Higher than pure monolith, lower than full microservices

ELSE IF different services written in different languages (e.g., Python ML, Node API):
  → RECOMMEND: Polyglot microservices (but only 2-3 services)
  → BUSINESS REASONING:
    - ML models need Python (scikit-learn, TensorFlow)
    - API might be better in Node.js or Go
    - Allows using best tool for each job
  → COST: Higher ops complexity, need language-specific expertise
  → CAVEAT: "Only do this if you have strong technical reasons, not just preference"

ELSE (default for most startups):
  → RECOMMEND: Monolith
  → BUSINESS REASONING:
    - Ship faster, iterate faster
    - Refactor easily (everything in one codebase)
    - Debug easily (single log stream)
    - You can always split into microservices when revenue justifies complexity
  → COST: Lowest infrastructure and operational costs

## Architecture Pattern Recommendation

**Recommended**: [Monolith / Modular Monolith / Microservices / Hybrid]

**Business reasoning**:
- [Speed to market or team velocity impact]
- [Operational complexity or cost impact]
- [Scaling or organizational impact]

**Cost**: [Infrastructure cost comparison]

**Alternative**: [When to consider different pattern]

**Migration path**: [How to evolve this architecture as you grow]

## Architecture Pattern Recommendation

**Recommended**: Monolith

**Business reasoning**:
- 3-5x faster to build than microservices — ship MVP in weeks not months
- Single deployment means no distributed systems complexity
- 50-70% lower hosting costs (one server vs 5+ services + load balancers)
- Easier to hire for — most developers know monoliths, fewer know microservices well

**Cost**: $20-100/month infrastructure (vs $200-500/month for microservices)

**Alternative**: If you grow beyond 10 backend engineers or have services with very different scaling needs (e.g., CPU-heavy image processing vs memory-heavy caching), migrate to microservices then. Netflix, Amazon, and Uber all started as monoliths.

**Migration path**: Start monolith → Modular monolith (organize code into modules) → Extract high-value services first (e.g., payment processing) → Full microservices if team > 15 engineers

**Don't use**: Microservices at MVP stage. You'll spend 30-40% of dev time on infrastructure (service mesh, API gateway, distributed tracing) instead of features. The "we might need to scale" argument is premature — you can migrate to microservices in 2-3 months when you actually need it.

IF team has framework experience (React/Next, Vue/Nuxt, Svelte):
  → RECOMMEND: Their existing framework
  → BUSINESS REASONING:
    - Productivity on day 1
    - Learning new framework = 1-2 months slower
    - Team knowledge > framework features
  → CAVEAT: "Unless outdated (Angular.js, Backbone) — then recommend migration"

ELSE IF AI integration needed AND (team = none or small):
  → RECOMMEND: Next.js (React) + Python backend (FastAPI)
  → BUSINESS REASONING:
    - Next.js has best AI SDK support (Vercel AI SDK)
    - Python has all AI libraries (OpenAI, LangChain, transformers)
    - Largest AI hiring pool
  → COST: Free frameworks, hosting $20-200/month
  → ALTERNATIVE: "SvelteKit if performance critical, but smaller AI ecosystem"

ELSE IF SEO critical (content site, marketplace):
  → RECOMMEND: Next.js or Nuxt (meta framework with SSR)
  → BUSINESS REASONING:
    - Server-side rendering = better SEO
    - Meta frameworks handle routing, data fetching, optimization
    - Better Core Web Vitals out of the box
  → ALTERNATIVE: "SvelteKit also supports SSR and is faster, but smaller ecosystem"

ELSE IF real-time features needed:
  → RECOMMEND: Next.js or SvelteKit
  → BUSINESS REASONING:
    - Need SSR + real-time
    - Good WebSocket/SSE support
    - Built-in API routes simplify architecture

ELSE IF team = none (will hire):
  → RECOMMEND: Next.js (React) + TypeScript
  → BUSINESS REASONING:
    - Largest hiring pool (React most popular)
    - TypeScript catches bugs pre-production
    - Most third-party components available
  → COST: Free, hosting $20-200/month
  → ALTERNATIVE: "SvelteKit if you value performance over ecosystem (10x fewer developers)"

ELSE (default):
  → RECOMMEND: Next.js (React) + TypeScript
  → BUSINESS REASONING: Safe default, largest ecosystem, easiest hiring

IF team has database experience:
  → RECOMMEND: Their existing database
  → BUSINESS REASONING: Database choice rarely matters at MVP. Speed > features.
  → CAVEAT: "Unless outdated (MySQL 5.x, MongoDB < 4.0)"

ELSE IF highly relational data (e-commerce, SaaS, multi-tenant):
  → RECOMMEND: PostgreSQL (Supabase, Neon, or AWS RDS)
  → BUSINESS REASONING:
    - Handles complex queries and relationships
    - JSONB for flexibility when needed
    - Best free tiers (Supabase 500MB, Neon 0.5GB)
    - Largest ecosystem and hiring pool
  → COST: $0-25/month (free tier) → $25-100/month (production)
  → ALTERNATIVE: "MySQL if better write performance needed, but PostgreSQL more feature-rich"

ELSE IF search critical (content, marketplace, docs):
  → RECOMMEND: PostgreSQL + dedicated search (Typesense, Meilisearch, Algolia)
  → BUSINESS REASONING:
    - PostgreSQL for main data
    - Dedicated search engine for speed/relevance
    - Don't make one database do both jobs
  → COST: PostgreSQL $0-25/month + Search $0-50/month
  → ALTERNATIVE: "Algolia easiest but expensive at scale ($1/1K searches)"

ELSE IF unstructured data OR rapid prototyping:
  → RECOMMEND: PostgreSQL with JSONB (not MongoDB)
  → BUSINESS REASONING:
    - JSONB gives flexibility + relational power
    - Better long-term than starting with MongoDB
    - Easier to add structure as product evolves
  → COST: $0-25/month (free tier)
  → WHY NOT MONGODB: "PostgreSQL JSONB gives 80% of flexibility + full SQL"

ELSE IF scale > 100K users year 1:
  → RECOMMEND: PostgreSQL (AWS RDS or Supabase)
  → BUSINESS REASONING:
    - Proven at scale
    - Read replicas and connection pooling
    - Mature monitoring tools
  → COST: $50-200/month with connection pooling

ELSE (default):
  → RECOMMEND: PostgreSQL (Supabase or Neon)
  → BUSINESS REASONING:
    - Best free tier
    - Supabase includes auth + storage + realtime
    - Easiest to hire for
  → COST: $0/month (free) → $25/month (pro)

IF budget = free tier only AND scale < 10K users:
  → RECOMMEND: Supabase Auth (if using Supabase) or Clerk
  → BUSINESS REASONING:
    - Supabase: included free with database
    - Clerk: best free tier (10K MAU), best DX
  → COST: $0/month
  → CAVEAT: "Free tiers enough for MVP, upgrade when you hit limits"

ELSE IF compliance required (SOC 2, HIPAA, enterprise):
  → RECOMMEND: Auth0
  → BUSINESS REASONING:
    - Best compliance certifications
    - Enterprise SSO support
    - Mature audit logs
    - Trusted by banks/healthcare
  → COST: Free (7K MAU) → $240/month (Essentials) → Custom (Enterprise)
  → ALTERNATIVE: "AWS Cognito if all-in on AWS, but worse DX"

ELSE IF need advanced features (passwordless, magic links, beautiful UI):
  → RECOMMEND: Clerk
  → BUSINESS REASONING:
    - Best pre-built UI components
    - Fastest implementation
    - Modern, polished experience
  → COST: $0 (10K MAU) → $25/month (Pro)
  → ALTERNATIVE: "Auth0 if need more compliance features"

ELSE IF scale > 50K users:
  → RECOMMEND: Auth0 or build on Supabase
  → COST COMPARISON at 50K MAU:
    - Auth0: ~$1,200/month
    - Clerk: ~$800/month
    - Supabase: ~$25-100/month (included with database)
  → DECISION: "Budget-constrained → Supabase. Enterprise features → Auth0"

ELSE (default: small-medium, standard features):
  → RECOMMEND: Clerk (standalone) or Supabase Auth (if using Supabase DB)
  → BUSINESS REASONING:
    - Clerk: best DX, great free tier
    - Supabase: included with database, no extra service
  → COST: $0-25/month

IF no DevOps AND budget < $500:
  → RECOMMEND: Vercel (frontend + serverless API) or Railway (traditional server)
  → BUSINESS REASONING:
    - Zero DevOps work
    - Git push = deploy
    - Auto-scaling
    - Preview deployments
    - Monitoring included
  → COST: Vercel $0-20/month, Railway $5-50/month
  → WHEN TO USE WHICH:
    - Vercel: Next.js/React, API is serverless functions
    - Railway: Persistent servers (WebSockets, background jobs)

ELSE IF backend = WebSocket OR real-time:
  → RECOMMEND: Railway or Render
  → BUSINESS REASONING:
    - Vercel functions timeout at 60s
    - Real-time needs persistent connections
    - Railway/Render support this
  → COST: Railway $5-100/month, Render free (sleeps) → $7-100/month

ELSE IF backend = Background jobs (video, email, AI):
  → RECOMMEND: Railway (persistent workers) or AWS Lambda (event-driven)
  → BUSINESS REASONING:
    - Jobs run longer than serverless limits
    - Railway = simple
    - Lambda = cheaper at scale but complex
  → COST: Railway $20-200/month, Lambda pay-per-use ($0.20 per million requests)

ELSE IF scale > 100K requests/day:
  → RECOMMEND: AWS (ECS Fargate or Lambda) or Railway Pro
  → BUSINESS REASONING:
    - Managed platforms get expensive at scale
    - AWS gives more control + lower per-request cost
  → COST: AWS $100-500/month, Railway $100-500/month

ELSE (default: standard web app, small-medium scale):
  → RECOMMEND: Vercel (if Next.js) or Render (other frameworks)
  → BUSINESS REASONING:
    - Easiest deployment
    - Best DX
    - Free tier generous for MVP
    - Upgrade path when needed
  → COST: $0-20/month

IF user uploads (images/video) AND volume < 100 GB:
  → RECOMMEND: Uploadthing (if Next.js) or Cloudflare R2
  → BUSINESS REASONING:
    - Uploadthing: easiest integration, free tier (2GB)
    - R2: no egress fees (huge savings at scale)
    - Both CDN-backed
  → COST: Uploadthing $0-20/month, R2 ~$1.50/100GB/month (no egress!)
  → ALTERNATIVE: "S3 if AWS-heavy, but watch egress costs ($90/TB)"

ELSE IF public CDN delivery (images/videos on website):
  → RECOMMEND: Cloudflare R2
  → BUSINESS REASONING:
    - Zero egress fees (S3 charges $90/TB)
    - S3-compatible API
    - Built-in CDN
  → COST COMPARISON at 1TB storage + 5TB egress/month:
    - R2: $15/month
    - S3: $473/month ($23 storage + $450 egress)
  → SAVINGS: 97% cheaper for high-egress workloads

ELSE IF private access (authenticated, time-limited URLs):
  → RECOMMEND: S3 (if AWS) or R2 with presigned URLs
  → BUSINESS REASONING:
    - Both support presigned URLs for security
    - R2 cheaper
  → COST: R2 $0.015/GB/month, S3 $0.023/GB/month + egress

ELSE IF volume > 1 TB:
  → RECOMMEND: Cloudflare R2 or Wasabi
  → COST COMPARISON at 5TB storage + 10TB egress:
    - R2: $75/month (storage only, no egress)
    - Wasabi: $30/month (flat pricing)
    - S3: $1,015/month ($115 storage + $900 egress)

ELSE IF backups:
  → RECOMMEND: Cloudflare R2 or Backblaze B2
  → BUSINESS REASONING:
    - Cheapest storage
    - Backups accessed rarely
  → COST: Backblaze $5/TB/month, R2 $15/TB/month

ELSE (default: small scale, user uploads):
  → RECOMMEND: Uploadthing (if Next.js) or Supabase Storage (if using Supabase)
  → BUSINESS REASONING: Simplest setup, generous free tiers
  → COST: $0-10/month

IF volume < 3K/month AND transactional:
  → RECOMMEND: Resend
  → BUSINESS REASONING:
    - Best developer experience
    - 3K emails/month free
    - Built for developers, not marketers
  → COST: $0 (3K emails) → $20/month (50K emails)
  → ALTERNATIVE: "Postmark if you value deliverability over DX (100/month free)"

ELSE IF volume < 100/day AND transactional:
  → RECOMMEND: SendGrid
  → BUSINESS REASONING:
    - 100 emails/day free forever
    - Good for early MVP testing
  → COST: $0 (100/day) → $20/month (40K emails)

ELSE IF marketing (newsletters, campaigns):
  → RECOMMEND: ConvertKit or Mailchimp
  → BUSINESS REASONING:
    - Purpose-built for marketing
    - Segmentation, campaigns, automation
    - Resend/SendGrid are transactional only
  → COST: ConvertKit $0 (1K subscribers) → $29/month (3K subscribers)

ELSE IF volume > 100K/month:
  → RECOMMEND: AWS SES or SendGrid
  → COST COMPARISON at 500K emails/month:
    - SES: ~$50/month (cheapest, complex setup)
    - SendGrid: ~$90/month
    - Resend: ~$150/month

ELSE (default: transactional, < 50K/month):
  → RECOMMEND: Resend
  → BUSINESS REASONING:
    - Best DX
    - React email templates
    - API-first
  → COST: $0-20/month

IF budget = free tier only:
  → RECOMMEND: Sentry (errors) + Vercel Analytics (if Vercel) or PostHog (product analytics)
  → BUSINESS REASONING:
    - Sentry free: 5K errors/month
    - Vercel Analytics: free with Vercel
    - PostHog free: 1M events/month
  → COST: $0/month
  → CAVEAT: "Free tiers enough for MVP, upgrade at limits"

ELSE IF priority = catching errors (crashes, exceptions):
  → RECOMMEND: Sentry
  → BUSINESS REASONING:
    - Best error tracking
    - Source maps and stack traces
    - Integrates everywhere
    - Industry standard
  → COST: $0 (5K errors/month) → $29/month (50K errors)

ELSE IF priority = user behavior (analytics, funnels, retention):
  → RECOMMEND: PostHog
  → BUSINESS REASONING:
    - Product analytics + session replay + feature flags
    - All-in-one platform
    - Open source
    - Generous free tier
  → COST: $0 (1M events/month) → Pay as you go
  → ALTERNATIVE: "Mixpanel or Amplitude for enterprise, but expensive"

ELSE IF priority = performance (slow pages, API latency):
  → RECOMMEND: Vercel Analytics (if Vercel) or Datadog (complex infrastructure)
  → BUSINESS REASONING:
    - Vercel: built-in, zero config
    - Datadog: full observability but expensive
  → COST: Vercel $0-25/month, Datadog $0 (5 hosts) → $180+/month

ELSE IF team > 5 developers:
  → RECOMMEND: Sentry + PostHog + Datadog (or New Relic)
  → BUSINESS REASONING:
    - Need full observability: errors + analytics + performance
    - Worth cost with bigger team
  → COST: ~$100-500/month total

ELSE (default: small team, MVP):
  → RECOMMEND: Sentry (errors) + PostHog (analytics)
  → BUSINESS REASONING: Covers 80% of needs, generous free tiers
  → COST: $0-50/month

IF subscription business AND international sales AND < 5 products:
  → RECOMMEND: Stripe
  → BUSINESS REASONING:
    - Industry standard for subscriptions
    - Best API and developer experience
    - Handles PCI compliance automatically
    - Supports 135+ currencies
    - Extensive ecosystem (payment links, invoices, tax calculation)
  → COST: 2.9% + $0.30 per transaction (US), slightly higher international
  → ALTERNATIVE: "Paddle if you want merchant of record (they handle tax/VAT)"

ELSE IF need merchant of record (you don't want to handle tax/VAT):
  → RECOMMEND: Paddle or LemonSqueezy
  → BUSINESS REASONING:
    - They become merchant of record (handle all tax compliance)
    - You get net revenue, they handle VAT/sales tax globally
    - Simpler compliance (no Stripe Tax subscription needed)
    - Better for small teams without finance/legal resources
  → COST: 5% + $0.50 per transaction (includes tax handling)
  → COST COMPARISON at $10K MRR:
    - Stripe: $290 + $99/mo Stripe Tax = ~$389/month
    - Paddle/LemonSqueezy: ~$500/month (but includes full tax compliance)
  → DECISION: "Worth the extra cost if you're < 5 people and don't have finance team"

ELSE IF digital products (SaaS, e-books, courses) AND small team:
  → RECOMMEND: LemonSqueezy
  → BUSINESS REASONING:
    - Merchant of record (they handle tax)
    - Built for digital products
    - Simpler than Stripe for solo founders
    - No need for separate tax solution
  → COST: 5% + $0.50 per transaction
  → ALTERNATIVE: "Stripe if you need more customization or plan to scale beyond $1M ARR"

ELSE IF physical products OR marketplaces:
  → RECOMMEND: Stripe
  → BUSINESS REASONING:
    - Connect API for marketplaces (split payments)
    - Better fraud detection for physical goods
    - More payment methods (Apple Pay, Google Pay, etc.)
  → COST: 2.9% + $0.30 base + 0.25% for Connect

ELSE IF usage-based pricing (metered billing):
  → RECOMMEND: Stripe
  → BUSINESS REASONING:
    - Best metered billing support
    - Real-time usage reporting
    - Flexible pricing models (tiered, volume, etc.)
  → ALTERNATIVE: "Chargebee if you need very complex billing logic"

ELSE IF enterprise customers (invoicing, POs, annual contracts):
  → RECOMMEND: Stripe (with Invoicing) or Chargebee
  → BUSINESS REASONING:
    - Stripe Invoicing supports NET 30/60 terms
    - Can handle POs and manual payments
    - ACH/wire transfer support
  → COST: Stripe 0.4% for invoices (capped at $2), Chargebee starts at $249/month

ELSE (default: most startups):
  → RECOMMEND: Stripe
  → BUSINESS REASONING:
    - Industry standard
    - Best documentation and community
    - Easiest to hire developers who know it
    - Most third-party integrations
  → COST: 2.9% + $0.30 per transaction

IF collaborative editing (Google Docs-style) OR gaming:
  → RECOMMEND: WebSocket with Operational Transform or CRDT library
  → BUSINESS REASONING:
    - Need bidirectional, low-latency communication (< 100ms)
    - Server needs to push updates to all clients instantly
    - Complex conflict resolution requires stateful connections
  → IMPLEMENTATION: Socket.io or native WebSocket + Yjs (CRDT library)
  → COST: Server must handle persistent connections (use Railway/Render, not Vercel serverless)
  → ALTERNATIVE: "Pusher Channels if you don't want to manage WebSocket infrastructure"

ELSE IF chat application OR live updates with user presence:
  → RECOMMEND: WebSocket (self-hosted) or Pusher/Ably (managed)
  → BUSINESS REASONING:
    - WebSocket: Full control, cheaper at scale (> 10K users), but you manage infrastructure
    - Pusher/Ably: Managed service, faster to implement, expensive at scale
  → COST COMPARISON at 10K concurrent users:
    - Self-hosted WebSocket (Railway): ~$50-100/month
    - Pusher: ~$500/month
    - Ably: ~$300/month
  → DECISION: "Start with Pusher/Ably for MVP, migrate to self-hosted at 5K+ concurrent users"

ELSE IF live dashboards OR stock tickers (server → client only, no client → server):
  → RECOMMEND: Server-Sent Events (SSE)
  → BUSINESS REASONING:
    - Simpler than WebSocket (HTTP-based, no special protocol)
    - Auto-reconnect built in
    - Only need server → client (not bidirectional)

Metric	Track	Alert	Tool
Signups per day	Yes	N/A	PostHog
Active users (DAU/MAU)	Yes	N/A	PostHog
Tasks created per day	Yes	Drop >50%	Custom
Failed payment attempts	Yes	>5 in 1 hour	Stripe webhooks

architecture-methodology

Datos de origen

Opciones de instalación

Revisa los archivos de origen

Más de este repositorio

Más de este repositorio

Architecture Methodology

Identity

Core Principle

Step 1: Requirements Gathering (Assumption-First Model)

The 5 Gating Questions

Architecture Methodology

Identity

Core Principle

Step 1: Requirements Gathering (Assumption-First Model)

The 5 Gating Questions

Gathering Rules

What NOT to Ask (Default These Instead)

Step 1.5: Architecture Invariants (Universal Truths)

Data Scoping (Multi-tenant & Security)

Idempotent Writes (Reliability)

Timeouts & Circuit Breakers (Resilience)

Secrets Management (Security)

At-Least-Once Async Processing (Job Queues)

Audit Logging (Compliance & Security)

Step 1.6: Default Assumptions with Confidence Labels

Confidence Label System

Default Assumptions Template

Using Assumptions in Blueprints

Step 2: Build the System Manifest

Manifest Building Rules

Manifest Quality Checks

Step 2.5: Detect Product Type & Identify Required Depth Sections

Product Type Detection Logic

Detection Output Format

Rules

Step 3: Generate Deliverables

Deliverable Sequence (for full blueprint)

Deliverable Rules

Output Quality Rules

Comprehensive Examples and Templates

Assumption-First Requirements Gathering Example

Communication Pattern Decision Tree

Security Architecture Example

⚡ Optional Enhancements

🛠️ Build Paths

Path 1: Build with AI Tools (Recommended for MVPs)

Path 2: Hire a Developer

Path 3: Hire an Agency

📊 Success Metrics (Track These)

🆘 If You Get Stuck

2. Architecture Pattern (Monolith vs Microservices)

3. Tech Stack (Frontend/Backend)

4. Database Selection

5. Authentication Provider

6. Hosting & Deployment

7. File Storage

8. Email Service

9. Monitoring & Error Tracking

10. Payment Processing

11. Real-time Communication Pattern