bmad-method（巴德法）

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:

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. Measure Infrastructure Cost Per User

If you can't calculate cost per user, you can't predict profitability.

Track monthly:

• AWS/GCP/Azure spend
• Third-party SaaS costs
• Divide by active users

4. Align Architectural Investments with Revenue

If feature doesn't drive revenue/retention, defer expensive architecture.

Example: Don't build multi-region before proving PMF.

5. Plan for Architectural Pivot Points

Know when you'll need to refactor:

• 1,000 users → Optimize database queries
• 10,000 users → Add caching layer
• 100,000 users → Microservices for bottlenecks
• 1M users → Multi-region, custom infra

Common Pitfalls

1. Over-Engineering for Scale You Don't Have

Building for 1M users when you have 100 wastes time and money.

Antipattern: Microservices + Kubernetes at MVP stage Better: Monolith on Railway/Heroku, scale later

2. Under-Engineering for Business Model

Not building multi-tenancy in B2B SaaS kills margins at scale.

Antipattern: Dedicated database per customer Better: Multi-tenant architecture from day 1

3. Ignoring Unit Economics

Not tracking cost per user means surprises at scale.

Antipattern: "We'll figure out costs later" Better: Model costs before building

4. Building Everything In-House

Commodities don't need custom solutions.

Antipattern: Build custom auth, payments, email Better: Buy Stripe, Auth0, SendGrid; build differentiation

5. Misaligned Tech Investments

Spending on features that don't drive business value.

Antipattern: Perfect CI/CD before proving PMF Better: Ship fast, optimize later

Related Skills

• mvp-builder - Rapid MVP development (BMAD guides what to build)
• product-strategist - Product-market fit validation (BMAD aligns architecture)
• deployment-advisor - Infrastructure and CI/CD (BMAD sets cost targets)
• api-designer - API design (BMAD determines pricing model)
• performance-optimizer - Optimize costs at scale (BMAD identifies when to optimize)

Deliverables

When using BMAD Method, produce:

1. Business Model Canvas

- Revenue streams, cost structure, value proposition - Unit economics (CAC, LTV, margin)

1. Architecture Alignment Document

- How architecture supports business model - Cost per user calculations - Scalability plan for growth stages

1. Build vs. Buy Decision Matrix

- Core capabilities to build - Context capabilities to buy - Cost-benefit analysis

1. Architectural Roadmap

- Current stage architecture - Planned refactors at scale milestones - Investment priorities

Success Metrics

You've successfully applied BMAD when:

• Infrastructure costs are predictable and within target margins
• Architecture supports current stage without over-engineering
• Clear plan exists for next scale milestone
• Build vs. buy decisions are justified by business value
• Technical debt is strategic, not accidental
• Team understands business implications of technical choices

Remember: The best architecture is the one that makes your business model sustainable and profitable.