The First Time a User Costs You Money: SaaS Unit Economics for Engineers

What you actually need to know

• Every architectural decision affects the cost to serve customers. Engineers who do not think in unit economics make decisions that can undermine business viability.
• AI inference costs are the highest-risk COGS component in AI-enabled SaaS. Model the per-session cost before pricing the product.
• Gross margin is the accumulated result of architectural decisions. A well-architected system has higher gross margin than a poorly architected one serving the same customers.
• The cost that is invisible at 100 customers becomes a crisis at 10,000 customers. Design with cost efficiency in mind from the beginning.
• Tag and measure compute by customer or tier from day one. Cost visibility is the prerequisite to cost management.

The core argument

The engineer who builds a product without understanding the unit economics is like a product manager who builds without understanding user needs. The product may be technically correct and may even delight users, but if the cost to serve each user is greater than the revenue they generate, the business is not viable regardless of how impressive the engineering is.

This is not a hypothetical risk. The AI-enabled SaaS products that are most at risk right now are the ones where engineers built features that make multiple LLM API calls per user interaction without modeling the cost. A user who generates ten LLM calls per session at $0.02 per call has a $0.20 AI cost per session. If that user has ten sessions per month, the AI cost is $2.00 per month. If the subscription price is $15 per month and the gross margin target is 70 percent, the total COGS budget per user is $4.50 per month. The AI cost alone is 44 percent of the COGS budget, leaving $2.50 per month for compute, database, storage, and support.

This math forces architectural decisions. Caching responses for common queries reduces the cost of repeated prompts to near zero. Optimizing prompts to reduce token count reduces inference cost per call. Implementing rate limits prevents individual users from consuming disproportionate AI resources. These decisions are not arbitrary constraints -- they are the architectural choices required to keep the business viable at the unit level.

Understanding the cost structure

The direct cost to serve a SaaS customer -- the cost of goods sold -- has several components. Compute: the servers, containers, or serverless functions that run the application for the customer's requests. Database: the read and write operations, storage, and backup for the customer's data. Storage: the files, attachments, and exports the customer creates. Network: the bandwidth consumed by the customer's traffic. Third-party APIs: external services the product calls on the customer's behalf (email sending, payment processing, AI inference, SMS, map tiles).

Understanding which of these is the largest component for a specific product is the starting point for engineering cost optimization. A product that is primarily compute-bound should optimize for compute efficiency. A product that is primarily storage-bound should implement data tiering (keeping recent data in fast storage, archiving old data to slow storage). A product that is primarily AI-inference-bound should optimize prompt efficiency and implement caching.

The cost model is most useful as a per-user-per-month calculation. For each cost category, calculate the average monthly cost per user based on the current architecture and usage patterns. Sum these to get the total COGS per user per month. Compare this to the average revenue per user. The difference is the gross margin contribution per user.

The multi-tenant architecture and its cost implications

The architectural decision that has the largest single impact on SaaS unit economics is the data isolation model: will each customer have dedicated database and compute resources, or will all customers share resources with logical isolation?

Dedicated resources per customer is the higher-cost model. The minimum cost per customer is the minimum cost of their dedicated stack, even if they are using the product infrequently. This model is sometimes required by compliance (each customer's data must be physically isolated) or by reliability requirements (one customer's heavy usage must not affect another's).

Shared resources with logical isolation (multi-tenancy) is significantly more cost-effective. Compute is shared across all customers. Database resources are shared, with row-level security or schema-per-tenant isolation to keep customer data separate. The cost per customer is the fraction of the shared resources they consume, which is much lower at low utilization than dedicated resources.

The architectural choice between these models should be made with the unit economics in mind. A product where the minimum viable customer is a small team that will spend $50 per month cannot afford to provision dedicated infrastructure per customer -- the infrastructure cost would exceed the revenue. A product where the minimum viable customer is an enterprise paying $10,000 per month can afford a higher COGS per customer while maintaining acceptable gross margins.

AI inference cost management

AI inference is the fastest-growing COGS component in SaaS products that integrate LLMs. The cost of inference depends on the model selected, the number of tokens in each request and response, and the frequency of calls per user session.

The engineering levers for managing inference cost: model selection (using a smaller, cheaper model for tasks that do not require the full capability of the largest model), prompt optimization (reducing token count without reducing quality), response caching (caching responses for prompts that are frequently repeated, such as common help queries), rate limiting (preventing individual users from consuming disproportionate inference resources), and streaming (showing users partial responses while generation continues, which improves perceived performance without changing the total cost).

The pricing structure must reflect the inference cost structure. A flat subscription that includes unlimited AI usage for $15 per month may be viable at 1,000 users, where the average usage is low and the economics average out. At 10,000 users, with some power users making hundreds of calls per day, the economics may be different. Usage-based pricing or per-seat pricing with usage caps are mechanisms that align revenue with the cost to serve.

Building cost visibility

The cost visibility that allows these decisions to be made requires instrumentation. Tag cloud resources by customer ID (or customer tier for shared resources) so that per-customer costs can be computed from cloud billing data. Instrument the application to record the number of AI inference calls, tokens consumed, and third-party API calls per user session. Set alerts when per-request costs increase -- this may indicate an efficiency regression introduced in a recent deployment.

The monthly review of per-customer unit economics should be a regular part of engineering leadership. Not a detailed report for every customer, but an analysis of the cost distribution: what is the average cost per customer, what is the cost of the top 10 percent heaviest users, and is the average cost trending up or down relative to revenue per customer?

Common mistakes engineers make with SaaS unit economics

1. Not modeling the cost before building AI features. The inference cost of a feature that seems inexpensive in testing can be significant at production usage patterns.
2. Using dedicated resources per customer when multi-tenancy would work. The cost difference is substantial and the complexity of multi-tenancy is manageable.
3. Not implementing data tiering for storage. All data stored at hot storage prices is the highest-cost storage architecture. Archive old data automatically.
4. Not rate-limiting third-party API calls. A user who can trigger unlimited calls to an external API that charges per call creates unbounded COGS exposure.
5. Not tracking cost metrics alongside product metrics. Cost metrics that are only reviewed when the cloud bill is large are cost metrics that are too late to be managed effectively.

Where to start: a 3-step cost model

Step 1: Build the per-customer cost model for the current architecture. For each cost category, calculate the average monthly cost per user based on actual usage data or reasonable estimates. Sum to get the total COGS per user per month.

Step 2: Identify the highest-cost category and the engineering lever to reduce it. For AI inference: prompt optimization and caching. For compute: workload right-sizing and shared tenancy. For storage: tiered storage and automated archival. Choose the highest-return lever and implement it.

Step 3: Instrument the application to track cost metrics. Per-request compute cost, per-session AI inference cost, per-user storage growth. Set alerts for regressions. Review monthly as part of the engineering health review.

The Economics Inside the Architecture

Yashveer Singh. Founder of Yashveer Labs. The unit economics of the systems I build for clients are part of the architecture conversation from the beginning. A multi-tenant data model is not just a technical choice -- it is a choice that enables the gross margin that makes the business viable. An AI feature with uncapped inference calls is not just a product choice -- it is a financial exposure that the pricing model must account for. The engineering and the business are the same conversation.

Related reading

• The Database You Did Not Think You Needed
• The Finance Stack for a SaaS Business
• The Edge Rendering Bet: When It Pays Off
• The Difference Between an AI Wrapper and an AI Product