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)
2. •

   Architecture Alignment Document

   • •How architecture supports business model
   • •Cost per user calculations
   • •Scalability plan for growth stages
3. •

   Build vs. Buy Decision Matrix

   • •Core capabilities to build
   • •Context capabilities to buy
   • •Cost-benefit analysis
4. •

   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.