Build the cost model for a multi-tenant SaaS — enumerate cost drivers (compute, storage, database, AI tokens, seats, third-party providers, support load), attribute costs to tenants and plans via tenant-tagged usage, compute unit economics (cost per tenant, per seat, per plan tier vs revenue), identify unbounded and variable-cost exposure (AI, egress, storage) and noisy-neighbor risk, and define cost guardrails (quotas, alerts, degradation ladders, per-tenant kill criteria) with a staged roll...
Scanned 9/11/2026
Install to Claude Code
npx -y skills add ModernNomad-98/Project-Aegis --skill saas-cost-architect --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Saas Cost Architect?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/modernnomad-98-saas-cost-architect)More formats (shields.io, HTML) on the badges page.
---
name: saas-cost-architect
description: Build the cost model for a multi-tenant SaaS — enumerate cost drivers (compute, storage, database, AI tokens, seats, third-party providers, support load), attribute costs to tenants and plans via tenant-tagged usage, compute unit economics (cost per tenant, per seat, per plan tier vs revenue), identify unbounded and variable-cost exposure (AI, egress, storage) and noisy-neighbor risk, and define cost guardrails (quotas, alerts, degradation ladders, per-tenant kill criteria) with a staged rollout and rollback. Use when asked what a tenant or plan actually costs, whether pricing covers cost, which tenants are unprofitable, before launching a feature with variable per-use cost, or when the cloud/AI bill grew and nobody knows which tenants drove it. Do NOT use for designing plan features and limit semantics (plan-entitlement-architect — this skill prices what that one gates), platform structure (saas-platform-architect), or general cloud architecture selection.
---
# SaaS Cost Architect
## Purpose
Produce a cost model that connects the bill to the tenants and plans that
generate it: a driver inventory grounded in real billing data, an attribution
map that says how each driver is tagged back to a tenant, per-plan unit
economics against revenue, named unbounded-cost exposures, and guardrails
with rollout and rollback. The discipline is attribution-or-admission: every
cost is either attributed to tenants by a stated mechanism or explicitly
listed as unattributable overhead — a model that "roughly allocates" the
biggest line item is fiction with a spreadsheet.
## Use When
- Use when: asked what a tenant, seat, or plan actually costs to serve — or
which tenants are unprofitable at their current plan.
- Use when: validating that pricing covers cost before a launch, a plan
change, or an enterprise deal ("can we afford this allowance?").
- Use when: launching a feature with variable per-use cost — AI inference,
storage, egress, third-party API calls — and the exposure is unmodeled.
- Use when: the cloud or AI bill jumped and the question is which tenants,
features, or plans drove it.
- Use when: designing cost guardrails — quotas, alerts, degradation, kill
criteria — for expensive paths.
- Do NOT use when: defining what features/limits a plan CONTAINS — that is
`plan-entitlement-architect`; this skill prices those decisions and feeds
margin data back.
- Do NOT use when: choosing platform structure or deployment models —
`saas-platform-architect` (though its pooled/siloed choices set each
tenant's cost floor).
- Do NOT use when: general infrastructure right-sizing with no tenant/plan
dimension — that is ordinary cloud engineering, not this skill.
- Do NOT use when: BUILDING the metering pipeline that produces the usage
numbers — the append-only event table, rate-card versioning, idempotent
cost entries, additive rollups, and invoice reconciliation are
`usage-metering-and-cost-attribution-pipeline-designer`; this skill is the
economic MODEL those numbers feed, not the ETL.
## Inputs to Inspect
1. Real billing data: cloud provider bills, AI provider usage exports,
third-party invoices — by service, at least 1–3 months. The model is
built from bills, not list prices.
2. Existing usage/metering data per tenant (plan-entitlement-architect's
metering hooks, if they exist) and what is NOT yet tenant-tagged.
3. The entitlement matrix and price book: plans, prices, allowances,
overrides — revenue side of unit economics.
4. Tenant population: count, plan distribution, size skew (the top tenant's
share of usage), growth.
5. The platform's deployment model (pooled/siloed per component) — silos
have per-tenant cost floors; pools need attribution keys.
6. Variable-cost feature paths in code: what calls the AI provider, what
writes to storage, what egresses — and whether those paths carry tenant
context.
## Workflow
1. **Inventory cost drivers from real bills.** Group by service, mark each
driver fixed (exists at zero tenants), stepped (scales in chunks), or
variable (scales per use). No bill available → the model is an estimate
and is labeled as one (see Stop Conditions).
2. **Define the attribution map**: for each driver, the mechanism that ties
it to a tenant — tenant-tagged usage events, resource tags, per-tenant
storage prefixes, metering counters, or proportional allocation with the
proxy named. Drivers with no mechanism go to the unattributable-overhead
line, visibly.
3. **Fill attribution gaps worth filling**: specify the missing tenant
tags/counters (often the same metering hooks
`plan-entitlement-architect` needs) — a small build list, ranked by the
dollars it would attribute.
4. **Compute unit economics**: cost per tenant (attributed + overhead
share), per seat, per plan tier — against revenue per the price book.
Present distributions, not just averages: the mean tenant is profitable
in almost every broken model; the P95 tenant is the finding.
5. **Name the exposures**: unbounded variable costs (AI tokens, egress,
storage growth) with worst-case-per-tenant math; noisy-neighbor cost
concentration (top tenant's share); allowance arbitrage (plan allowances
priced below cost at full utilization).
6. **Design guardrails**, proportional to exposure: per-tenant quotas tied
to entitlements, budget alerts at attribution granularity, degradation
ladders (cheaper model, throttle, queue) before hard stops, and
per-tenant kill criteria for pathological cost — each guardrail with an
owner and a tenant-visible behavior.
7. **Plan rollout and rollback**: guardrails ship observe-only first
(alert, don't block), thresholds tuned on real distribution, then
enforce — with a per-guardrail disable path as rollback. Enforcement
that can degrade a paying tenant's service routes through
`human-approval-boundary`.
8. **Define the validation loop**: model vs actual bill reconciliation
monthly; drift beyond a stated tolerance reopens the model. A cost model
nobody reconciles is decor.
## Output Format
```
SAAS COST MODEL — <product/scope>
Driver inventory: <driver — service — fixed/stepped/variable — monthly $ from
real bills (or ESTIMATE label)>
Attribution map: <driver → mechanism (tag/counter/prefix/proxy) →
unattributable overhead listed separately with total>
Attribution build list: <missing tag/counter — dollars it would attribute —
ranked>
Unit economics: <per plan: revenue vs attributed cost + overhead share;
distribution incl. P95 tenant; unprofitable tenants named by criteria>
Exposures: <unbounded drivers with worst-case math; noisy-neighbor
concentration; allowance arbitrage>
Guardrails: <guardrail — threshold — behavior (alert/degrade/stop) —
tenant-visible effect — owner>
Rollout & rollback: <observe-only → tune → enforce; per-guardrail disable;
approval gates for service-degrading enforcement>
Validation loop: <reconciliation cadence, tolerance, reopen trigger>
Assumptions & open questions: <each with risk-if-wrong / who answers>
```
## Validation Checklist
- [ ] Drivers come from real bills, or every affected number carries an
ESTIMATE label — no silent list-price math.
- [ ] Every driver has an attribution mechanism or sits visibly in
unattributable overhead; overhead is bounded and stated.
- [ ] Unit economics show distributions (incl. P95/top tenants), not only
averages.
- [ ] Every variable-cost driver has worst-case-per-tenant math and a
guardrail decision (including "accepted, no guardrail" as an explicit
choice).
- [ ] Guardrails have owners, tenant-visible behaviors, observe-only
rollout, and a disable path.
- [ ] The reconciliation loop exists with a cadence and tolerance.
- [ ] No plan/limit semantics were redesigned here — margin findings are
handed to `plan-entitlement-architect`, not silently patched into
entitlements.
## Tenant Isolation Rules
- Cost attribution rides on tenant-tagged usage; counters keyed by user
alone mis-attribute the moment users span tenants.
- Tenant-facing cost/usage dashboards show only that tenant's data; internal
cost dashboards that rank tenants by name are access-controlled like the
sensitive data they are.
- Guardrail enforcement messages never disclose other tenants' usage,
thresholds, or existence ("capacity" wording, not "tenant X used it all").
## Gotchas
- Shared-infrastructure allocation by tenant count flatters heavy tenants;
allocate by a usage proxy (requests, rows, storage) and name the proxy.
- AI costs are input+output tokens times the model actually invoked —
fallbacks and retries included; per-request averages hide retry storms.
- The most expensive tenant is routinely on a legacy/discounted plan with a
grandfathered allowance — check overrides, not just list plans.
- Free-tier and trial cost is a real driver; leaving it out of the model
makes conversion economics look better than they are.
- Hard-stop guardrails on paying tenants convert a cost problem into a churn
problem; degradation ladders first, stops last, humans in the loop for
enterprise tenants.
- Reserved-instance/committed-use discounts distort marginal-cost math; use
marginal rates for "what does one more tenant cost."
## Stop Conditions
- No billing or usage data is accessible → produce only a labeled-estimate
model with the data-access request list; do not present estimates as
measurements.
- A guardrail would degrade or cut off a paying tenant's service →
`human-approval-boundary` with the tenant impact before enforcement ships.
- Unit economics reveal pricing is underwater at scale → that is a
commercial decision; present the math and options
(`plan-entitlement-architect` for the entitlement side), do not quietly
redesign plans.
- Attribution requires new tracking of user-level behavior with privacy
implications → surface the privacy question before specifying the
tracking.
## Supporting Files
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination against
`saas-platform-architect` and `plan-entitlement-architect`
(platform/commercial cluster).
- No references/ — the driver, attribution, and guardrail tables above are
the complete procedure; detail lives in the output artifacts.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!