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. 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:

Business Model Canvas
- Revenue streams, cost structure, value proposition
- Unit economics (CAC, LTV, margin)
Architecture Alignment Document
- How architecture supports business model
- Cost per user calculations
- Scalability plan for growth stages
Build vs. Buy Decision Matrix
- Core capabilities to build
- Context capabilities to buy
- Cost-benefit analysis
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.