BMAD Method

What this skill does

# BMAD Method (Business Model and Architecture Design)

## Overview

The BMAD Method bridges business strategy and technical architecture. It ensures your technical decisions support long-term business sustainability, not just immediate feature delivery.

**Core Insight:** Your architecture IS your business model in code form.

## When to Use This Skill

Use BMAD when:

- Starting a new product or major architectural redesign
- Technical decisions have direct revenue/cost implications
- Scaling challenges intersect with business model constraints
- Evaluating build vs. buy for core capabilities
- Transitioning from MVP to sustainable growth
- Business model changes require architectural shifts

## Key Capabilities

- Map business model to technical architecture decisions
- Identify architectural implications of revenue models
- Design for cost sustainability at scale
- Align technology investments with business value
- Evaluate infrastructure costs vs. revenue potential
- Plan architecture evolution alongside business growth

## Workflow

### Step 1: Business Model Analysis

**Understand the Revenue Engine:**

- How does money flow? (One-time, subscription, usage-based, marketplace, advertising)
- What's the unit economics? (CAC, LTV, gross margin, payback period)
- What are the scale expectations? (10 users? 10k? 10M?)
- What's the competitive moat? (Network effects, data, tech, brand)

**Key Questions:**

- Is this B2B or B2C?
- What's the pricing model?
- What drives costs? (Infrastructure, support, sales, dev)
- What's the target gross margin?

---

### Step 2: Architecture Alignment

**Map Business Model to Architecture:**

**Subscription SaaS (B2B):**

- Multi-tenancy architecture
- Pay-as-you-grow infrastructure (starts cheap)
- Enterprise features (SSO, RBAC, audit logs)
- 99.9%+ uptime SLA requirements
- Data isolation and security compliance

**Usage-Based (API/Platform):**

- Serverless/metered infrastructure
- Rate limiting and quota management
- Detailed usage tracking and billing
- Developer experience (docs, SDKs)
- Predictable per-request costs

**Marketplace/Network:**

- Support dual-sided interactions (buyers/sellers)
- Transaction processing and escrow
- Search, matching, and discovery algorithms
- Trust and safety systems
- Commission-based cost structure

**Freemium/Consumer:**

- Scales to millions of users efficiently
- Clear free vs. paid feature boundaries
- Low marginal cost per user
- Conversion funnel optimization
- Viral/growth mechanics

---

### Step 3: Cost Modeling

**Infrastructure Cost Analysis:**

**Calculate Unit Economics:**

- Cost per user/month
- Cost per transaction
- Cost per API call
- Infrastructure overhead vs. variable costs

**Example (SaaS):**

```
Target: $20/user/month subscription

Acceptable costs:
- Infrastructure: <$2/user/month (10% COGS)
- Support: <$4/user/month (20%)
- Sales/Marketing: <$60 CAC (3-month payback)

Architecture decisions:
- Shared infrastructure (not dedicated per customer)
- Self-service onboarding (reduce sales cost)
- In-app support tools (reduce support tickets)
- Efficient database design (reduce storage costs)
```

---

### Step 4: Scalability Planning

**Design for Growth Stages:**

**Stage 1: MVP (0-100 users)**

- **Goal:** Validate product-market fit
- **Architecture:** Simple, monolithic, managed services
- **Cost:** Fixed low monthly ($100-500/month)
- **Trade-off:** Speed over scalability

**Stage 2: Growth (100-10k users)**

- **Goal:** Prove unit economics work
- **Architecture:** Modular monolith, scale vertically first
- **Cost:** Linear with users ($0.50-5/user/month)
- **Trade-off:** Optimize for margin over features

**Stage 3: Scale (10k-1M users)**

- **Goal:** Efficient scaling without rewrites
- **Architecture:** Microservices for bottlenecks, caching, CDN
- **Cost:** Sublinear growth ($0.10-1/user/month)
- **Trade-off:** Operational complexity vs. efficiency

**Stage 4: Enterprise (1M+ users)**

- **Goal:** Dominant market position
- **Architecture:** Multi-region, custom infra, dedicated teams
- **Cost:** Economies of scale (<$0.10/user/month)
- **Trade-off:** Long-term investment over short-term agility

---

### Step 5: Build vs. Buy Framework

**Evaluate Core vs. Context:**

**Build when:**

- It's your competitive differentiator
- You need specific customization
- Recurring costs exceed build cost
- You have expertise in-house
- Control/security is critical

**Buy/Use SaaS when:**

- It's commodity functionality
- Time-to-market is critical
- You lack expertise
- Maintenance burden is high
- Cost predictability matters

**Examples:**

| Capability          | Decision              | Rationale                   |
| ------------------- | --------------------- | --------------------------- |
| Payment processing  | Buy (Stripe)          | Commodity, compliance heavy |
| Core algorithm      | Build                 | Competitive moat            |
| Email delivery      | Buy (SendGrid)        | Commodity infrastructure    |
| Analytics           | Buy (Mixpanel)        | Faster than building        |
| Custom AI model     | Build                 | Unique to your data         |
| Auth infrastructure | Buy (Auth0) initially | Build later at scale        |

---

### Step 6: Business Constraints Documentation

**Capture Non-Negotiable Requirements:**

**Regulatory/Compliance:**

- GDPR, HIPAA, SOC2, PCI-DSS
- Data residency requirements
- Audit trail and retention policies

**Business Commitments:**

- SLA commitments (uptime, response time)
- Data portability guarantees
- Security certifications required
- Integration promises to customers

**Financial Constraints:**

- Burn rate and runway
- Target gross margin
- Pricing commitments made
- Investor expectations

---

## Examples

### Example 1: B2B SaaS Analytics Platform

**Business Model:**

- $99-$499/month subscription
- Target: 1,000 customers = $1.5M ARR
- Target gross margin: 80%
- Max COGS: $3/customer/month

**Architecture Decisions:**

- **Multi-tenant database** (shared PostgreSQL)
- **Serverless data processing** (AWS Lambda)
- **Managed infrastructure** (AWS RDS, S3, CloudFront)
- **No dedicated resources per customer** (kills margin)

**Build vs. Buy:**

- Build: Core analytics engine (differentiator)
- Buy: Auth (Auth0), Email (SendGrid), Support (Intercom)

**Outcome:** $2.50/customer/month COGS, 83% margin

---

### Example 2: Usage-Based API Platform

**Business Model:**

- $0.01/API call pricing
- Target: 10M calls/month = $100k MRR
- Target gross margin: 70%
- Max COGS: $0.003/call

**Architecture Decisions:**

- **Serverless architecture** (AWS Lambda + API Gateway)
- **Pay-per-use infrastructure** (no idle costs)
- **Aggressive caching** (CloudFlare + Redis)
- **Efficient algorithms** (cost per call matters)

**Build vs. Buy:**

- Build: Core API logic (differentiator)
- Buy: API gateway (AWS), CDN (CloudFlare), Monitoring (Datadog)

**Outcome:** $0.0025/call COGS, 75% margin

---

### Example 3: Consumer Marketplace

**Business Model:**

- 10% commission on transactions
- Target: $1M GMV/month = $100k revenue
- Target gross margin: 60%
- Max COGS: $40k/month

**Architecture Decisions:**

- **Scalable to millions of users** (serverless + CDN)
- **Transaction processing** (Stripe Connect)
- **Search and matching** (Algolia or Elasticsearch)
- **Low marginal cost per user** (<$0.01/user/month)

**Build vs. Buy:**

- Build: Matching algorithm (differentiator)
- Buy: Payments (Stripe), Search (Algolia), Chat (Stream)

**Outcome:** Scales to 100k users at <$35k/month

---

## Best Practices

### 1. Start with Business Model, Not Tech Stack

Don't choose React/Node/AWS first. Choose after understanding:

- Revenue model
- User scale
- Unit economics
- Margin targets

### 2. Design for Current Stage +1

Build for where you are now, but don't lock yourself out of next stage.

**Bad:** Hard-coded single-tenant that can't scale
**Good:** Multi-tenant from day 1 (even at 10 users)

### 3. Mea