Skip to content
Back to skills

Bmad Method Daffy0208 Ai Dev Standards 2

ASecurity

Business Model and Architecture Design methodology for aligning technical architecture with business model sustainability and scalability

  • 666 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added June 2, 2026
devopsrustgosqlreactnodekubernetesawsgcpazureapi

Works with

  • api
  • mcp

Security analysis

A100/100

Scanned June 2, 2026

npx -y skills add majiayu000/claude-skill-registry --skill bmad-method-daffy0208-ai-dev-standards-2 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Bmad Method Daffy0208 Ai Dev Standards 2?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Bmad Method Daffy0208 Ai Dev Standards 2
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/majiayu000-bmad-method-daffy0208-ai-dev-standards-2/badge)](https://www.skillsdirectory.com/skills/majiayu000-bmad-method-daffy0208-ai-dev-standards-2)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: BMAD Method
description: Business Model and Architecture Design methodology for aligning technical architecture with business model sustainability and scalability
version: 1.0.0
category: business-architecture
triggers:
  - 'bmad-method'
  - 'bmad method'
  - 'business model architecture'
  - 'business architecture design'
  - 'align architecture with business model'
dependencies:
  required_mcps: []
  required_tools: []
  required_integrations: []
---

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

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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.