All examples for SaaS Unit Economics Calculator

API Service Per-Call Economics

Calculate cost per API call, margins, and scaling projections for an API-first SaaS handling 10M calls/month.

Input

What you provide to the skill

I’m running an API service with 10 million calls per month, $10000 revenue at $0.001 per call, and $1500 infrastructure costs. What’s my unit economics?

Output

What the skill generates for you

Based on the calculation logic from the Python script, here’s your unit economics analysis:


API Service Unit Economics Analysis

Current Metrics

  • API Calls: 10,000,000 per month
  • Price per Call: $0.001
  • Monthly Revenue: $10,000
  • Infrastructure Cost: $1,500

Unit Economics

  • Cost per Call: $0.00015
  • Gross Margin: 85.0%
  • Margin per Call: $0.00085

Cost by Component

Component Monthly Cost Cost per Million Calls Cost per Call
Infrastructure $1,500 $150.00 $0.00015

Scaling Projection

Current (10M calls/month)

  • Revenue: $10,000
  • Cost: $1,500
  • Margin: 85.0%

At 50M calls/month (5x scale)

  • Revenue: $50,000
  • Cost: $6,750 (with 10% economy of scale)
  • Margin: 86.5%

At 100M calls/month (10x scale)

  • Revenue: $100,000
  • Cost: $12,750 (with 15% economy of scale)
  • Margin: 87.3%

Key Insights

Health Status: Excellent

Your API service has strong unit economics with an 85% gross margin. At $0.00015 cost per call with $0.001 pricing, you have significant headroom - your price is 6.7x your infrastructure cost.

Margin Analysis: With such high margins, you have multiple strategic options:

  • Price competitively to win market share (could reduce to $0.0005 and still maintain 70% margins)
  • Maintain current pricing and maximize profitability
  • Invest margin in additional features/reliability

Scaling Economics: Your margins improve as you scale due to fixed cost dilution and volume discounts:

  • 5x volume = 86.5% margin (1.5 point improvement)
  • 10x volume = 87.3% margin (2.3 point improvement)

Optimization Recommendations

Without detailed infrastructure breakdown, consider these general optimizations:

  1. Detailed cost allocation - Break down your $1,500 into compute, database, API gateway, storage, and data transfer to identify the largest cost drivers.

  2. Right-size compute resources - If using Lambda, profile actual memory usage. Most functions over-allocate memory. Dropping from 1024MB to 512MB can cut compute costs by 50%.

  3. Database optimization - If database represents >30% of costs, audit:

    • Instance size vs actual CPU/memory usage
    • On-demand vs provisioned capacity for predictable workloads (40% savings)
    • Connection pooling and query optimization
  4. Reserved capacity - For stable workloads, commit to 1-year reserved instances for 30-40% savings on compute resources.

  5. API Gateway alternatives - At your current 10M calls/month you’re below the threshold, but beyond 50M calls/month consider switching from API Gateway to Application Load Balancer (saves ~70% on routing costs).

Cost Formula Reference

For an API service, typical cost breakdown:

Cost per call = (Compute_cost/call) + (API_routing/call) + (Database_ops/call) + (Data_transfer/call)
Example with typical AWS services:
- Lambda: (execution_ms/1000) x (memory_GB) x $0.0000166667
- API Gateway: $0.00000350 per request
- DynamoDB: $0.25 per million read units + $1.25 per million write units
- Data Transfer: (response_KB/1024/1024) x $0.09 per GB

Your current blended rate of $0.00015 per call suggests efficient infrastructure. To optimize further, get granular cost allocation by tagging resources with service type (compute, database, routing, storage).

Action Items

  1. Immediate: Export detailed AWS cost breakdown by service to identify the largest cost component
  2. This week: Audit compute memory allocation - quick win if over-provisioned
  3. This month: Implement cost allocation tags (api-compute, api-database, api-routing, api-storage) for ongoing tracking
  4. Quarterly: Review and right-size based on 90 days of usage data

Your unit economics are strong. Focus on incremental optimizations as you scale rather than major architectural changes.