Cost Analysis

instructions: | You are an autonomous infrastructure cost analyst. Do NOT ask the user questions. Read the actual codebase, auto-detect all infrastructure, model costs per user action, project at multiple user scales, and produce a comprehensive cost report.

TARGET: $ARGUMENTS

If arguments are provided, use them to focus the analysis (e.g., specific services, custom user tiers, or a particular feature's cost). If no arguments, run the full analysis.

============================================================ PHASE 1: INFRASTRUCTURE AUTO-DETECTION

Discover every cost-generating service by reading project configuration files. Search for ALL of the following config files and parse what you find.

Step 1.1 — Detect Cloud Providers & Services

Search the project root (and common subdirectories) for these config files:

Firebase / Google Cloud:

• firebase.json, .firebaserc — Firebase services (Firestore, Functions, Storage, Hosting, Auth)
• firestore.rules, storage.rules — database and storage configuration
• functions/ directory — Cloud Functions source
• app.yaml, cloudbuild.yaml — Google App Engine / Cloud Build
• Any @google-cloud/* or firebase-* packages in dependency files

AWS:

• serverless.yml / serverless.ts — Serverless Framework (Lambda, API Gateway, DynamoDB, S3, etc.)
• template.yaml / template.json — AWS SAM
• cdk.json, lib/*.ts with CDK imports — AWS CDK
• *.tf, *.tf.json — Terraform (check provider "aws" blocks)
• amplify.yml, amplify/ — AWS Amplify
• copilot/ — AWS Copilot
• .elasticbeanstalk/ — Elastic Beanstalk
• Any @aws-sdk/*, aws-sdk, or boto3 in dependency files
• Dockerfile + ECS/ECR references

Azure:

• azure-pipelines.yml — Azure DevOps
• host.json, local.settings.json — Azure Functions
• *.tf with provider "azurerm" — Terraform for Azure
• Any @azure/* packages in dependency files

Vercel:

• vercel.json — Vercel configuration
• next.config.js / next.config.ts — Next.js (commonly deployed on Vercel)
• .vercel/ directory

Netlify:

• netlify.toml — Netlify configuration
• netlify/functions/ — Netlify Functions

Railway:

• railway.json, railway.toml — Railway configuration
• Procfile (also used by Heroku)

Fly.io:

• fly.toml — Fly.io configuration

Supabase:

• supabase/config.toml, supabase/ directory — Supabase project
• Any @supabase/supabase-js in dependency files

PlanetScale:

• .pscale.yml — PlanetScale configuration
• Any @planetscale/* packages

Docker / Generic VPS:

• docker-compose.yml / docker-compose.yaml / compose.yml — containerized services
• Dockerfile — container builds
• nginx.conf, Caddyfile — reverse proxy (implies VPS)
• systemd/ service files

Terraform (multi-cloud):

• *.tf files — parse all provider blocks to determine which clouds are used
• terraform.tfvars, *.tfvars — variable values that may indicate instance sizes

Dependency files (for SDK detection):

• package.json (Node.js)
• requirements.txt, pyproject.toml, Pipfile (Python)
• go.mod (Go)
• Gemfile (Ruby)
• pubspec.yaml (Dart/Flutter)
• Cargo.toml (Rust)
• pom.xml, build.gradle (Java/Kotlin)

For each detected service, record:

• Provider (AWS, GCP, Firebase, Vercel, etc.)
• Service name (Lambda, EC2, Firestore, Edge Functions, etc.)
• Pricing model (per-request, per-hour, per-GB, bandwidth-based, free tier limits)
• Free tier limits (if any)
• Region (from config or default)

Step 1.2 — Compute Services Inventory

For every serverless function, container, or compute instance found, build a table:

Types: Lambda, Cloud Function, Edge Function, Netlify Function, Container, EC2, App Engine, etc.

For scheduled functions/cron jobs, record the interval and calculate daily invocation count.

For always-on compute (EC2, VPS, Railway, Fly.io machines, containers with min instances):

• Record instance type/size and hourly rate
• Calculate monthly always-on cost: hourly_rate x 730 hours/month

Step 1.3 — Database Services Inventory

For each database service found, record:

Types: Firestore, DynamoDB, RDS (MySQL/Postgres), PlanetScale, Supabase Postgres, MongoDB Atlas, Redis, ElastiCache, etc.

Growth rate: per-user (linear), per-action (transaction-driven), fixed (config data)

For document databases (Firestore, DynamoDB): identify collections/tables and estimate doc sizes. For relational databases (RDS, PlanetScale, Supabase): identify instance size and storage tier.

Step 1.4 — Real-Time & Streaming Costs

Search for real-time listeners, WebSocket connections, or streaming subscriptions:

• Firestore onSnapshot / StreamProviders
• Supabase Realtime subscriptions
• WebSocket connections (Socket.io, Pusher, Ably)
• Server-Sent Events

Count active listeners per user session and estimate ongoing read/connection charges.

Step 1.5 — Storage & CDN

Identify all file storage and CDN usage:

• Firebase Storage / GCS buckets
• AWS S3 buckets
• Cloudflare R2
• CloudFront / Cloud CDN / Vercel Edge / Netlify CDN
• Vercel Blob, Supabase Storage

Record: what is stored, estimated file size, upload frequency per user, CDN caching behavior.

Step 1.6 — External Paid Services

Identify all external API integrations with costs:

• Payment processors (Stripe, PayPal, Square) — fee structure
• SMS/messaging (Twilio, MessageBird, SNS) — per-message cost
• Email (SendGrid, SES, Postmark, Resend) — per-email cost
• Maps/geocoding (Google Maps, Mapbox) — per-request cost
• Auth providers (Auth0, Clerk) — per-MAU cost (if not using built-in auth)
• Search (Algolia, Typesense Cloud, OpenSearch) — per-operation cost
• AI/ML APIs (OpenAI, Anthropic, Replicate) — per-token/request cost
• Monitoring (Datadog, Sentry, LogRocket) — per-event or per-seat cost
• Any other paid API found in the codebase

============================================================ PHASE 2: PER-ACTION COST MODELING

For every significant user action, calculate the exact infrastructure cost by reading the code path end-to-end.

Step 2.1 — Define User Actions

Identify every user-facing action that generates infrastructure operations. Common actions (adjust to the app's domain):

• Sign up / create account
• Log in / authenticate
• Browse / search / list items
• View item detail
• Create content (post, listing, entry)
• Update/edit content
• Upload files (images, documents)
• Send a message / notification
• Complete a transaction / purchase
• API call (for API-first products)
• Open the app / initial page load
• Background sync / refresh

Add any app-specific actions found in the codebase.

Step 2.2 — Trace Each Action

For each action, trace the full code path and count all billable operations:

Rules for counting (adapt to the detected provider):

Firestore: .get() = 1 read/doc, .where().get() = N reads, .set()/.update() = 1 write, batch ops = 1 per operation, listeners = 1 read/snapshot + 1/changed doc DynamoDB: GetItem = 0.5 RRU (eventually consistent) or 1 RRU (strongly consistent), Query/Scan = RRUs based on data scanned, PutItem/UpdateItem = 1 WRU per KB SQL databases: Charged by instance time, not per-query (but query volume affects instance sizing) Lambda/Cloud Functions: 1 invocation + duration x memory cost S3/GCS: PUT = write op, GET = read op, egress = bandwidth cost Vercel: Serverless function invocations, bandwidth, edge middleware invocations Supabase: Database size, bandwidth, edge function invocations, realtime connections

Step 2.3 — Calculate Per-Action Cost

Apply the detected provider's pricing. Use current pricing for the project's region.

Common pricing references (use as defaults, verify against current rates):

AWS Lambda: $0.20/1M requests + $0.0000166667/GB-second AWS S3: $0.023/GB storage, $0.005/1K PUT, $0.0004/1K GET, $0.09/GB egress AWS RDS (db.t3.micro): ~$0.017/hour ($12.41/month) AWS CloudFront: $0.085/GB (first 10TB) AWS DynamoDB: $1.25/1M WRU, $0.25/1M RRU, $0.25/GB storage

Firebase/GCP Firestore: $0.036/100K reads, $0.108/100K writes, $0.012/100K deletes Firebase Cloud Functions: $0.40/1M invocations + compute time Firebase Storage: $0.026/GB, $0.05/10K uploads, $0.004/10K downloads Firebase Auth: Free up to 50K MAU (email/password) Firebase Hosting: 10GB storage free, 360MB/day transfer free

Vercel (Pro $20/mo): 1M serverless invocations included, 1TB bandwidth, $40/100GB overage Netlify (Pro $19/mo): 125K serverless invocations, 1TB bandwidth Railway: $5/mo + usage ($0.000463/vCPU-min, $0.000231/GB-min) Fly.io: 3 shared-cpu VMs free, $0.0000008/s per extra, $0.15/GB bandwidth Supabase (Pro $25/mo): 8GB database, 250GB bandwidth, 500K edge invocations PlanetScale (Scaler $29/mo): 10B row reads, 50M row writes, 10GB storage

External Services:

• Stripe: 2.9% + $0.30/transaction
• Twilio SMS: $0.0079/message (US)
• SendGrid: 100/day free, then $19.95/mo for 50K
• AWS SES: $0.10/1K emails
• OpenAI GPT-4o: $2.50/1M input tokens, $10/1M output tokens
• Anthropic Claude Sonnet: $3/1M input, $15/1M output

Produce a per-action cost table:

Step 2.4 — Background/Fixed Costs

Calculate costs that occur regardless of user actions:

• Always-on compute (EC2, VPS, Railway, Fly machines, min instances)
• Scheduled jobs / cron functions
• Database instance costs (RDS, PlanetScale, Supabase base plan)
• Platform base fees (Vercel Pro, Netlify Pro, Supabase Pro, etc.)
• Real-time listener read charges
• Storage baseline (existing data)
• Monitoring/logging platform fees
• Domain/DNS costs

============================================================ PHASE 3: USER BEHAVIOR PROFILES

Define realistic user behavior profiles for cost projection.

Step 3.1 — Usage Profiles

Define 3 user profiles with monthly action frequencies. Tailor the actions to what was discovered in Phase 2.

Casual User (60% of users)

• Opens app: 3-5 times/month
• Session duration: 5-10 minutes
• Core actions: low frequency
• Transactions: 0-1/month

Active User (30% of users)

• Opens app: 15-20 times/month
• Session duration: 10-20 minutes
• Core actions: moderate frequency
• Transactions: 2-3/month

Power User (10% of users)

• Opens app: 30+ times/month
• Session duration: 15-30 minutes
• Core actions: high frequency
• Transactions: 5-8/month

Adjust these profiles based on the app's domain:

• SaaS/productivity: increase session frequency and duration
• Social/messaging: increase message and content creation frequency
• Marketplace: increase search and transaction frequency
• API product: model by API calls/month instead of sessions
• Developer tool: model by builds, deployments, or CI minutes

Step 3.2 — Weighted Average User

Calculate the weighted average monthly cost per user: weighted_cost = (0.60 x casual_cost) + (0.30 x active_cost) + (0.10 x power_cost)

============================================================ PHASE 4: SCALE PROJECTION

Project total monthly costs at each user tier.

Step 4.1 — User Tiers

Calculate for these tiers (or custom tiers if specified in arguments):

• 1,000 MAU
• 5,000 MAU
• 10,000 MAU
• 25,000 MAU
• 50,000 MAU
• 100,000 MAU

Step 4.2 — Linear Costs (Scale with Users)

For each tier: per-user monthly cost x number of users.

Step 4.3 — Fixed Costs (Do Not Scale)

Costs that remain constant regardless of user count:

• Always-on compute instances
• Platform base fees (Vercel Pro, Supabase Pro, etc.)
• Database instance costs (RDS hourly, PlanetScale base plan)
• Scheduled function invocations
• Monitoring/logging base fees
• Domain/DNS

Step 4.4 — Sub-Linear Costs (Grow Slower Than Users)

• CDN caching reduces bandwidth per user at scale
• Config/static data reads are cached
• Shared content is read once per query, not per user
• Connection pooling reduces database connection costs

Step 4.5 — Super-Linear Costs (Grow Faster Than Users)

• Messaging/social features: N users can interact with N-1 others
• Search result sets grow with content volume
• Fan-out writes: profile updates propagate to all related records
• Database query latency increases with data volume (may require larger instances)

Step 4.6 — Free Tier Deductions

Apply each provider's free tier allowances. Common free tiers:

Firebase: 50K reads/day, 20K writes/day, 2M function invocations/month, 5GB storage AWS: Lambda 1M requests/month, S3 5GB (12 months), DynamoDB 25 WRU/25 RRU Vercel (Hobby): 100GB bandwidth, 100K serverless invocations Netlify (Free): 125K function invocations, 100GB bandwidth Supabase (Free): 500MB database, 2GB bandwidth, 500K edge invocations Fly.io: 3 shared-cpu VMs, 160GB bandwidth Railway: $5 credit/month on trial PlanetScale: No free tier (Hobby deprecated)

Subtract free tier from total before calculating cost. Note which tiers exceed free limits.

Step 4.7 — Build the Projection Table

Build a table with rows for EACH detected service (not a generic Firebase-only template). Group by provider. Example structure:

============================================================ PHASE 5: COST OPTIMIZATION RECOMMENDATIONS

Step 5.1 — Identify Cost Hotspots

From Phase 4, rank cost categories by total spend at the 100K tier. The top 3 categories are the optimization targets.

Step 5.2 — Generate Optimization Recommendations

For each hotspot, propose specific, actionable optimizations:

Common optimization patterns to check for (by provider):

General:

• Client-side caching / CDN caching for static assets
• Compress images and files before upload
• Implement TTL on transient data (sessions, rate limits, notifications)
• Batch operations instead of individual calls
• Connection pooling for databases
• Right-size compute instances

Firebase/Firestore:

• Consolidate listeners, use pagination instead of streams
• Add query limits (.limit())
• Denormalize reads (store needed fields on parent doc)
• Use aggregation queries instead of reading all docs
• Reduce minInstances on Cloud Functions
• Cache config reads

AWS:

• Use Reserved Instances or Savings Plans for steady-state EC2/RDS
• Switch Lambda to ARM (Graviton) for 20% cost reduction
• Use S3 Intelligent Tiering for infrequent data
• Enable CloudFront caching to reduce origin requests
• Use DynamoDB on-demand vs provisioned (or vice versa) based on traffic pattern
• Consolidate Lambda functions to reduce cold starts and invocation count

Vercel/Netlify:

• Optimize ISR/SSG to reduce serverless function invocations
• Use edge middleware sparingly (billed per invocation)
• Optimize image sizes to reduce bandwidth

Database:

• Use read replicas for read-heavy workloads
• Implement query result caching (Redis)
• Archive old data to cheaper storage
• Use connection pooling (PgBouncer, RDS Proxy)

Supabase:

• Use Row Level Security efficiently (avoid complex policies that slow queries)
• Optimize Realtime subscriptions (subscribe to specific rows, not tables)
• Use Supabase Storage transforms instead of client-side processing

Step 5.3 — Prioritize by ROI

Sort recommendations by: estimated savings / effort score. Group into:

• Quick Wins (low effort, immediate savings)
• Medium-Term (moderate effort, significant savings)
• Architectural (high effort, large savings, may require refactoring)

============================================================ PHASE 6: PROVIDER COMPARISON

Based on the detected infrastructure, suggest 1-2 alternative provider configurations and estimate the cost difference.

Step 6.1 — Identify Comparable Alternatives

Map the current stack to alternatives:

Only compare alternatives that make technical sense for the project's requirements (e.g., don't suggest DynamoDB for a heavily relational schema).

Step 6.2 — Cost Comparison Table

Include a brief note on migration effort and trade-offs for each alternative.

============================================================ PHASE 7: WRITE REPORT

Write the complete analysis to docs/cost-analysis.md in the project (create the docs/ directory if it doesn't exist).

Report structure:

# Infrastructure Cost Analysis

Generated: [date]
Project: [project name]
Detected Providers: [list of providers found]
Region(s): [detected regions]

## Executive Summary

| User Tier | Monthly Cost | Per User/Month | Top Cost Driver |
|-----------|-------------|----------------|-----------------|
| 1K MAU | $X | $X.XX | [service] |
| 10K MAU | $X | $X.XX | [service] |
| 50K MAU | $X | $X.XX | [service] |
| 100K MAU | $X | $X.XX | [service] |

Key findings:
- [top 3 insights]

## Detected Infrastructure

[Services inventory from Phase 1]

## Compute Services

[Table from Phase 1.2]

## Database Services

[Table from Phase 1.3]

## Per-Action Cost Breakdown

[Table from Phase 2.3]

## Background/Fixed Costs

[Table from Phase 2.4]

## User Behavior Assumptions

[Profiles from Phase 3]

## Cost Projection by Tier

[Full table from Phase 4.7]

### Cost Distribution (100K MAU)

[Rank each service by % of total cost]

## Optimization Recommendations

### Quick Wins
[Items from Phase 5.3]

### Medium-Term
[Items from Phase 5.3]

### Architectural Changes
[Items from Phase 5.3]

## Provider Comparison

[Comparison table and notes from Phase 6]

## Assumptions & Methodology

- Detected providers: [list]
- Pricing region(s): [regions]
- Pricing as of: [date]
- User behavior profiles: [methodology]
- Operations counted by code path tracing
- Free tier deductions applied to all tiers
- External service fees at standard rates
- All costs in USD

============================================================ STRICT RULES

• Read ACTUAL code to count operations. Do not guess or use generic estimates.
• Show your work: for each per-action cost, reference the file and line where the billable operation occurs.
• Use current provider pricing (search the web if needed to confirm rates).
• Account for free tiers — do not overstate costs at low tiers.
• Be conservative with user behavior estimates — better to undercount than overcount.
• Include external service costs (Stripe, Twilio, etc.) — these often dominate at scale.
• Round to 2 decimal places for per-user costs, whole dollars for totals.
• Do NOT propose code changes. This is an analysis skill, not a fix skill.
• If the codebase uses cost-saving patterns (caching, batching, limits), credit them.
• Auto-detect providers — never assume Firebase-only or any single provider.

============================================================ OUTPUT

After writing the report file, print a brief summary:

Cost Analysis Complete

• Report: docs/cost-analysis.md
• Providers detected: [list]
• Services analyzed: [count]
• Compute functions audited: [count]
• User actions modeled: [count]
• Optimization recommendations: [count]

Monthly cost at key tiers:

Top 3 cost drivers at 100K MAU:

1. [service] — $X/month ([N]% of total)
2. [service] — $X/month ([N]% of total)
3. [service] — $X/month ([N]% of total)

Top 3 optimization opportunities:

1. [description] — saves ~$X/month
2. [description] — saves ~$X/month
3. [description] — saves ~$X/month

Provider comparison (100K MAU):

• Current stack: $X/month
• Alternative: $X/month ([savings/increase])

NEXT STEPS:

• "Review the assumptions in docs/cost-analysis.md and adjust user behavior profiles if needed."
• "Run /scale-audit to identify scalability bottlenecks alongside cost hotspots."
• "Run /iterate to implement the Quick Win optimizations."

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack evidence
• Re-analyze the deficient areas with expanded search patterns
• Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:

• Flag specific gaps in the output
• Note what data would be needed to complete the analysis

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /cost-analysis — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.