DEV Community: Muhammad Azlaan Zubair

LLM Input vs. Output Token Pricing: How to Calculate the Difference

Muhammad Azlaan Zubair — Sat, 24 Oct 2026 11:42:37 +0000

Input and output tokens are often billed at different rates, so the total number of tokens alone is not enough to estimate an LLM API bill. To calculate the cost of a request, multiply input tokens by the input rate, output tokens by the output rate, then add any applicable cached-input or other usage charges.

The exact rates depend on the provider, model, service tier, and billing conditions. OpenAI, Anthropic, and Google publish pricing tables that distinguish input from output and document additional pricing rules for features such as caching or tools. Check the OpenAI API pricing page, Anthropic Claude pricing, or Gemini API pricing for the model and tier you actually use.

The short version

Input tokens are the tokens the model receives, including relevant instructions, conversation history, retrieved text, and the current user message.
Output tokens are the tokens the model generates. Depending on the model and API, billed output can include reasoning or thinking tokens as well as visible response text.
Cached input tokens may be charged at a separate rate when a provider supports prompt or context caching. Cache writes and storage can have their own charges.
Other billable operations—such as web search, tool use, audio, image processing, or agent runtime—may sit outside a simple text-token calculation.

Use the Letinix LLM API Cost Calculator to estimate a text-token scenario by entering the current rates from your provider's pricing page. It does not automatically fetch rates, so update your inputs when prices or model choices change.

Why input and output rates differ

Providers price model usage by the type and amount of processing being billed. Input tokens represent material supplied to the model; output tokens represent material generated by it. The provider sets separate rates for each category, and output rates are often higher—but that is not a universal rule across every model, modality, or service tier.

The practical implication is simple: two requests with the same combined token count can cost different amounts if their input/output mix differs.

For example, a request containing 8,000 input tokens and 500 output tokens should not be estimated as though it contained 8,500 tokens all billed at the input rate. Calculate the two categories separately. The model's current pricing table—not a general rule about output being more expensive—determines the result.

Calculate the cost of one request

For a simple text request with no caching or separately billed tools, use this formula:

input cost  = input tokens  / 1,000,000 × input price per 1M tokens
output cost = output tokens / 1,000,000 × output price per 1M tokens
request cost = input cost + output cost

The prices in this formula must use the same currency and billing unit. If the vendor lists a rate per million tokens, divide token counts by 1,000,000. Do not multiply the full token count by a single blended rate unless you deliberately calculated that blended rate from your expected input/output mix.

Worked example with hypothetical rates

Assume one request uses 8,000 input tokens and 1,000 output tokens. For illustration only, suppose the input rate is $2 per million tokens and the output rate is $8 per million tokens. These are hypothetical values, not a current provider quote.

Component	Calculation	Estimated cost
Input	8,000 ÷ 1,000,000 × $2	$0.016
Output	1,000 ÷ 1,000,000 × $8	$0.008
Total	$0.016 + $0.008	$0.024

Here, input costs twice as much as output in absolute dollars because the request contains eight times more input tokens, even though the assumed output rate is four times higher. A higher per-token rate does not necessarily mean that category dominates the bill; the token volume matters too.

Estimate a month of usage

Once you have an estimate per request, multiply it by expected request volume:

monthly cost = cost per request × requests per month

Using the hypothetical $0.024 request above:

1,000 requests per month: $24
10,000 requests per month: $240
100,000 requests per month: $2,400

These totals assume every request has the same token profile and that the only charges are the two token categories in the example. Real traffic varies. Measure representative requests, estimate a range, and separate common, long-context, and long-output cases if their token profiles differ materially.

For a repeatable estimate, enter your input and output token counts, current rates, and request volume into the LLM API Cost Calculator. Use the result as a scenario estimate, not as an invoice or a substitute for the provider's usage records.

Where cached input fits

Caching can change the cost of repeated prompt material. When a provider supports prompt caching, some input tokens may be billed at a cache-read rate rather than the standard input rate. Depending on the service, writing content to a cache or keeping it stored can also have a separate charge.

A simple model of cached input is:

uncached input cost = uncached input tokens / 1,000,000 × input rate
cached input cost   = cached input tokens   / 1,000,000 × cache-read rate

Add those components to the output cost, and include cache-write or storage charges where applicable. Do not assume all cached tokens are free, that every model supports caching, or that the same cache lifetime and write/read multipliers apply across vendors. See the official OpenAI pricing documentation and Anthropic prompt-caching pricing for provider-specific rules; Google's Gemini pricing documentation also lists context-caching terms for supported models.

The current Letinix calculator can model a cache-read price and cache-hit percentage when you supply those values. Its result is only as accurate as the token counts, hit-rate assumption, and prices you enter. If cache writes or storage are separately charged in your configuration, add those costs separately.

The categories and rates must match the selected provider and model.

Common estimation mistakes

Treating every token as the same price

A blended rate can hide important changes in the input/output mix. Keep the categories separate until you know the workload's typical distribution.

Counting only the visible prompt and answer

Conversation history, system instructions, retrieved documents, tool definitions, and other request context can add input tokens. Some models also bill reasoning or thinking tokens as output even when those tokens are not shown as ordinary response text. Check the model's official billing documentation and use token usage reported by the API when available.

Assuming caching is always cheaper overall

Cache reads may be cheaper than ordinary input, but cache creation, storage, eligibility, minimum cacheable prompt sizes, and retention windows can affect the economics. Use the actual provider's rules and your observed cache-hit rate.

Forgetting charges outside text tokens

A text-token estimate may omit separately priced search or other tools, image and audio processing, hosting, orchestration, retries, and monitoring. Google documents separate pricing for some grounding tools; other providers also have feature-specific pricing. Add these components when your application uses them.

Using a price from an old model page

Pricing and model availability can change. Before estimating or comparing providers, confirm the exact model, tier, region, processing mode, and cache rules on the official pricing page. Record when you checked the rate if the estimate will be used for a budget or business case.

A reliable estimation workflow

Choose the exact model and service tier. Do not mix a model's standard rate with a batch, priority, regional, or other tier's rate.
Measure representative token counts. Include system prompts, conversation history, retrieved content, and generated output. Use API-reported usage where possible.
Split input, output, and cached input. Keep each billing category separate and account for cache writes or storage if the provider charges them.
Multiply by realistic request volume. Estimate normal and high-usage scenarios rather than assuming every request is identical.
Add non-token charges. Include paid tools, modalities, runtime, and infrastructure that your workload actually uses.
Recheck the official rates before making a commitment. A calculator is useful for the arithmetic; provider documentation remains authoritative for current billing rules.

Limitations and next steps

The Letinix calculator estimates text-token costs from the rates and usage assumptions you enter. It does not automatically synchronize provider prices or model your complete agent graph, retries, every modality, cache-write/storage fees, or hosting and observability costs. Treat those as separate line items where relevant.

If you are planning an application, start with a representative request and calculate the input/output split before extrapolating to monthly volume. For broader planning, use the guide to estimating LLM API costs before launch alongside this calculation, then add the costs that sit outside simple text-token billing.

References

This article was originally published on Letinix.

How to Validate API Responses in TypeScript

Muhammad Azlaan Zubair — Sat, 24 Oct 2026 11:42:12 +0000

TypeScript types do not validate API responses at runtime. They help the compiler check how your code uses values, but a remote server can still return malformed JSON, missing fields, or values that do not match your declared type. To check the data you actually receive, validate it at the boundary where it enters your application.

A practical pattern is to treat the payload as unknown, validate it with a runtime schema, and only then use the validated result. This guide uses Zod for a concise example; JSON Schema with a validator such as Ajv is another option when a portable schema is important.

Why a TypeScript annotation is not enough

This assertion does not inspect the response:

unsafe.ts

type User = {
  id: number;
  name: string;
};

const user = (await response.json()) as User;

The assertion tells TypeScript to trust the programmer. It does not check that id is a number or that name exists. TypeScript's handbook documents that type assertions are removed at compile time and have no runtime checking.

Parsing JSON is a separate step. JSON.parse() checks whether a string is syntactically valid JSON, but valid JSON can still have the wrong shape for your application. For example, {"id":"not-a-number","name":false} is valid JSON but does not match the User contract above.

Validate at the boundary with Zod

Install Zod in the project:

terminal

npm install zod

Define a schema for the shape your application expects. The example below is illustrative and follows the API documented in Zod's basic-usage guide:

user-schema.ts

import * as z from "zod";

export const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().nullable(),
});

export type User = z.infer<typeof UserSchema>;

The schema defines runtime checks, and z.infer derives the corresponding static TypeScript type. In this example, email must be present, but its value can be either a string or null. If the API may omit the property too, make that rule explicit with an optional schema.

Use safeParse() to handle validation failures as data rather than relying on an exception:

get-user.ts

import { UserSchema } from "./user-schema";

export async function getUser(id: number) {
  const response = await fetch(`/api/users/${id}`);

  if (!response.ok) {
    throw new Error(`User request failed: ${response.status}`);
  }

  const payload: unknown = await response.json();
  const result = UserSchema.safeParse(payload);

  if (!result.success) {
    throw new Error("The API returned an unexpected user shape");
  }

  return result.data;
}

The result's success branch contains validated data that TypeScript can treat as the inferred type. The error branch contains the validation details, which you can log or map into your application's error model. The example intentionally keeps error handling minimal; production code should choose how much detail is safe to expose to callers.

Decide what the schema should enforce

A schema should reflect the contract your application needs, not just the first payload you happened to capture. Consider:

Required properties: which keys must exist for the application to proceed?
Nullability and optionality: can a key be absent, present with null, or both?
Constraints: does an identifier need a particular format, or must a status be one of a known set?
Unknown keys: should additional fields be accepted, stripped, or rejected?
Variants: does the endpoint return a different object shape for different states?

Runtime validation is only as strong as the rules you define. A schema that checks only id and name will not establish constraints it does not express. Keep validation aligned with the API's documentation and update it when the contract changes.

When JSON Schema and Ajv are a better fit

Zod is a TypeScript-first option that lets you define schemas in code and infer TypeScript types from them. JSON Schema is a declarative format for describing and validating JSON documents. It can be useful when a schema needs to be shared across services or used by tooling outside TypeScript.

Ajv compiles JSON Schema or JSON Type Definition schemas into validation functions and can integrate validation results with TypeScript's type system. Choose based on your contract source, portability requirements, schema features, and validation workflow—not a blanket claim that one library is best for every application.

If the API already publishes an OpenAPI schema, consider generating TypeScript declarations from that contract instead of manually maintaining a parallel type. For example, openapi-typescript generates types from OpenAPI 3.0 and 3.1 schemas. Generated declarations improve static checking, but they still do not replace runtime validation of data received over the network.

Where JSON-to-TypeScript conversion fits

A converter is useful when you have a sample response and need a starting type declaration. The Letinix JSON to TypeScript Converter handles documented structures such as nested objects, arrays, and unions inferred from mixed values.

The generated declarations can improve editor feedback and make application code easier to maintain. They cannot prove that future responses match the sample or reject unexpected payloads at runtime. Use sample conversion to bootstrap the static model, then add validation when the boundary and consequences justify it.

Common mistakes

Casting a payload and calling it validation. Assertions change compiler assumptions, not runtime data.
Confusing valid JSON with valid application data. Syntax parsing does not establish that required fields or constraints are satisfied.
Maintaining a schema that is weaker than the contract. Unchecked fields remain unchecked.
Ignoring validation failures. Decide how to handle invalid responses and avoid exposing sensitive internal details.
Assuming generated types stay synchronized automatically. Keep generated declarations and runtime schemas aligned with the authoritative contract.

References

TypeScript Handbook: Everyday Types

Zod: Basic usage

JSON Schema: Specification

Ajv: Using with TypeScript

OpenAPI TypeScript: CLI

Letinix JSON to TypeScript Converter

This article was originally published on Letinix.

How to Estimate LLM API Costs Before Launch

Muhammad Azlaan Zubair — Thu, 22 Oct 2026 17:17:12 +0000

To estimate LLM API costs before launch, start with the price per million input and output tokens, estimate how many tokens each request uses, and multiply by expected request volume. Treat the result as a planning estimate, not a guaranteed invoice: real usage varies with prompt length, output length, caching, retries, model routing and separately billed tools.

The LLM API Cost Calculator applies those assumptions to estimate cost per request, day, month and year. The hard part is not the multiplication. It is choosing assumptions that resemble the workload you intend to ship.

1. Define the workload before entering prices

Start with a specific product action, not a vague label such as “one AI request.” A support reply, a document summary and an agent that searches a knowledge base can have very different token and tool-use patterns.

For a first estimate, write down four inputs:

Requests per period: the expected number of model requests per day or month. Make clear whether you mean user actions or actual model calls; one user action can trigger several calls.
Input tokens per request: the system prompt, conversation history, retrieved passages, tool results and other content sent to the model.
Output tokens per request: the generated response and, for reasoning models, any reasoning tokens that the provider bills as output.
Price per million tokens: the selected model’s current input and output rates, using the same billing tier and modality as your workload.

Use observed traces from a prototype when you have them. Before that, define a low, expected and high scenario rather than treating a single guess as a forecast. Keep each assumption visible so it can be replaced with measured usage later.

If you need to estimate the token count of a particular prompt or context first, use a tokenizer appropriate to the model. Token counts are not reliably interchangeable across model families, and text length alone is only a rough proxy.

2. Use the per-million-token formula

When a provider quotes text input and output prices per million tokens, calculate the two components separately:

Use these formulas (prices are in USD per million tokens):

C_input = T_input × P_input / 1,000,000
C_output = T_output × P_output / 1,000,000
C_request = C_input + C_output

Here, each T is the token count for one request, and each P is the price in USD per million tokens. Multiply the per-request estimate by the number of model requests in the period to estimate total inference charges for that period.

The unit matters. A price entered as dollars per million tokens must be divided by one million; a price quoted per thousand tokens, per image, per audio unit or per request needs a different calculation. Confirm the unit on the provider’s pricing page before copying a rate into the calculator.

3. Work through an illustrative monthly estimate

Suppose a hypothetical application makes 5,000 model requests each day. Assume each request uses 1,200 input tokens and generates 350 output tokens. For illustration only, enter an input price of $2.00 per million tokens and an output price of $8.00 per million tokens. These are example inputs, not current prices for any provider or model.

The request-level arithmetic is:

Input: 1,200 × $2.00 ÷ 1,000,000 = $0.0024
Output: 350 × $8.00 ÷ 1,000,000 = $0.0028
Total: $0.0024 + $0.0028 = $0.0052 per request

At 5,000 requests per day, that is $26.00 per day. With 30 days in the planning month, the estimate is $780 per month, or $9,360 for twelve months if the same usage and prices persisted. The monthly token volume is 232.5 million tokens across input and output.

This example deliberately holds request volume, token counts and prices constant. It does not account for growth, day-to-day variation, caching, failed requests, tool fees or discounts. The annual figure is a straight multiplication of the monthly scenario, not a claim about future spend.

The output is a scenario estimate, not a provider invoice.

4. Model cached input separately when the price is known

If a provider charges a different rate for cached input tokens, the cost of those tokens depends on how much input is eligible for cache reads and how often the cache is hit. A simplified estimate is:

C_input = T_input × [(1 − h) × P_input + h × P_cached] / 1,000,000

Here, h is the cache-hit fraction from 0 to 1, and P_cached is the price for cached input tokens. A 30% cache-hit rate is entered as 30 in the calculator’s percentage field.

This is a simplified model, not a universal cache-billing formula. Provider rules can distinguish cache writes from reads, impose minimum cacheable prompt lengths or durations, and charge for cache storage. The calculator’s single cached-input price and hit-rate field does not model all those details. If writes or storage are material, estimate them separately and add them to the scenario.

Do not assume that all repeated text is automatically billed at the cached rate. Check the provider’s caching documentation and the API behavior for the model you use.

5. Check the provider’s current pricing rules

Use official pricing documentation to obtain rates for the exact model and service tier. The three major providers document different pricing details, so avoid copying one provider’s cache or tool assumptions into another provider’s estimate.

OpenAI API pricing lists model-specific input and output prices and separate cached-input and cache-write rates for supported models.
Anthropic Claude pricing documents input/output pricing and prompt-cache read and write multipliers, including different cache durations.
Google Gemini API pricing distinguishes model/service tiers, documents context caching and separately priced tools, and notes that agent usage can include intermediate input or reasoning tokens.

These pages are references for current provider rules, not fixed values embedded in this article. Prices and model availability change. Before budgeting, check the page for your chosen model, API, modality, service tier, region or other applicable pricing modifier. Record the date and assumptions alongside any estimate you intend to compare later.

6. Turn one estimate into a useful forecast

A single scenario is a starting point. A budget becomes more useful when it makes uncertainty visible.

Use low, expected and high cases

Vary the inputs that actually drive your workload. For example, you can model fewer or more requests, shorter or longer prompts, and lower or higher output lengths. Do not label these cases “typical” unless you have measurements supporting that claim.

If request volume is uncertain, forecast it separately from cost per request. If token usage is uncertain, keep input and output estimates separate. This makes it easier to see whether the budget is sensitive to traffic, long context or generated output.

Measure actual traces when a prototype exists

Capture token usage returned by the API, along with the model, request type and relevant cache or tool metadata. Use a representative sample of real product tasks. Compare the observed distribution—not only the average—with your planning assumptions. Long-tail prompts and unusually large outputs can matter even when most requests are small.

Update the estimate when you change the system prompt, retrieval strategy, model, output limit, routing policy or agent loop. These changes can alter token use without changing the number of user-visible actions.

Separate user actions from model calls

For a simple chat turn, one user action may correspond to one model call. In a workflow, the same action may lead to a planning call, a tool-selection call, one or more follow-up calls and a final response. Estimate each call class separately when you know the workflow. Do not multiply every user action by an assumed fixed number of calls without checking traces or explicitly labelling the assumption.

The calculator models an average request and a request count. It does not model a workflow graph, retries or tool fees as separate line items. For a multi-step agent, calculate each step or call class independently, then sum the results and add separately billed components.

7. Know what the estimate excludes

A token-based estimate is not the same as the full cost of operating an AI feature. Depending on the provider and architecture, a first-pass estimate may exclude:

tool calls, search grounding, code execution or other separately billed services;
cache writes, cache storage or other cache-specific charges not represented by one cached-input rate;
image, audio, video or other non-text billing units;
batch, priority, committed-use or other service-tier adjustments;
retries, failed requests, validation calls or secondary model calls;
hosting, databases, retrieval infrastructure, logging, observability, evaluation and human review.

The calculator does not automatically fetch provider rates. It uses the prices and workload assumptions entered by the user, runs in the browser, and does not send those inputs elsewhere. Its results are an estimate of the token charges represented by those fields—not a complete invoice, total product cost or guarantee of future spend.

8. A pre-launch checklist

Before using an estimate to set a budget, verify these items:

The input and output rates match the exact model, API and service tier.
All rates use the units entered into the calculator: USD per million tokens.
Input tokens include the system prompt, relevant history, retrieved context and other content sent to the model.
Output tokens include any reasoning tokens that the provider bills as output.
Requests per day or month represent model calls, or the difference between user actions and model calls is modelled explicitly.
Cache assumptions reflect the provider’s rules, and unmodelled writes or storage are added separately if relevant.
Tool charges, retries and non-text usage are included separately where applicable.
The forecast includes more than one scenario if workload uncertainty is material.
The assumptions are dated and can be updated when pricing or product behavior changes.

The practical goal is not to predict an exact future invoice. It is to build a transparent estimate, understand which assumptions dominate it, and replace guesses with observed usage as the application matures.

References

This article was originally published on Letinix.

SaaS Unit Economics: Payment Fees and Usage Costs

Muhammad Azlaan Zubair — Thu, 22 Oct 2026 09:36:39 +0000

A SaaS customer’s subscription price is not the same as the revenue the business keeps. Payment processing, metered infrastructure, third-party APIs, storage, and other customer-driven expenses reduce the amount available to cover fixed costs and profit. A useful first unit-economics measure is monthly contribution per customer: revenue attributable to that customer minus the variable costs of serving and collecting payment from them.

The exact calculation depends on your payment contract, product architecture, and what you classify as a variable cost. Treat the worked numbers below as an illustrative model, not a quote or a benchmark.

A customer-level contribution model separates payment costs from usage-driven service costs.

The per-customer contribution formula

Contribution per customer = monthly revenue per customer − payment fees − variable service costs.

Variable service costs can include cloud compute, storage, bandwidth, model or API calls, metered messaging, and support costs that rise with customer activity. Include only costs that are genuinely attributable to serving the customer in this calculation, and document any allocation method for shared resources.

Contribution margin expresses that contribution as a share of revenue: contribution per customer ÷ monthly revenue per customer × 100. This is not necessarily the same as reported gross margin. The result depends on which costs your accounting policy includes in cost of revenue and whether customer acquisition, R&D, and other operating expenses are excluded.

Calculate payment-processing fees

Payment fees may combine a percentage of the charge with a fixed amount per successful transaction. The applicable rate can vary by provider, country, payment method, card type, currency conversion, and contract. Stripe’s published US standard pricing page lists 2.9% + $0.30 per successful domestic-card transaction; check the current pricing page for the market and payment method you actually use. Do not apply a US rate to a different country without verification.

For a single illustrative $49 monthly charge using that example rate: percentage fee: $49 × 2.9% = $1.421; fixed fee: $0.30; total processing fee: $1.721, or about 3.51% of the $49 charge. The effective percentage rises on smaller charges because the fixed fee takes a larger share. If customers make multiple billable transactions in a month, model the fixed component for each transaction rather than assuming one fee per account.

Also check whether the original processing fee is returned after refunds; Stripe’s pricing page says processing fees from the original payment are not returned for its standard pricing. Stripe’s pricing page documents this caveat.

Add customer-driven service costs

Next, estimate the costs that change with usage. Separate these from fixed or step-fixed costs such as a baseline database, minimum cloud commitments, or a team member’s salary.

Cost driver	Possible unit	What to measure
Compute and jobs	Runtime, CPU, or job count	Actual usage by tenant or workload
Storage	GB-month or stored objects	Average stored volume and retention
Network	GB transferred or requests	Egress and request volume
AI or external APIs	Tokens, calls, or task	Provider-billed usage per customer
Messaging	SMS, email, or event	Billable volume and destination mix
Support	Tickets or handling time	Only if a defensible variable allocation is available

Examples of usage-driven costs and useful measurement units.

For shared infrastructure, a cost-allocation rule is an estimate, not a direct invoice. Choose a measurable driver, apply it consistently, and revisit it when the architecture or customer mix changes. AWS cost guidance recommends cost-allocation tagging and using metrics to understand where spending occurs; see the AWS cost optimization guidance.

Avoid dividing the entire cloud bill by the number of customers and calling the result variable cost without checking the underlying cost behavior. That average can be useful for planning, but it can misstate the incremental cost of a new customer when much of the bill is fixed or shared.

Worked example: a $49 subscription

Assume one customer pays $49 once per month, the illustrative US domestic-card processing fee is 2.9% + $0.30, and that customer’s attributable variable service costs are estimated at $4.50 per month.

Item	Monthly amount
Subscription revenue	$49.00
Payment-processing fee	−$1.72
Variable service costs	−$4.50
Contribution per customer	$42.78
Contribution margin	87.3%

Illustrative monthly contribution calculation; amounts rounded.

These figures are rounded. The result excludes fixed operating costs, customer acquisition costs, taxes, refunds, discounts, failed payments, currency conversion, and any additional transactions. It should not be presented as gross margin unless the cost categories match the company’s gross-margin definition.

If the same customer’s usage rises and attributable service costs increase from $4.50 to $18.00, contribution falls to $29.28 and contribution margin falls to about 59.8%, assuming the same revenue and processing fee. This illustrates why a flat subscription price can become less profitable as high-usage customers grow.

Turn the calculation into a decision

Does the price cover normal usage? Estimate costs at low, typical, and high usage rather than relying on a single average.
Which customers or features create cost spikes? Compare cost drivers by plan, tenant, workflow, and usage cohort where the data supports it.
What happens when volume changes? Recalculate with more transactions, more API calls, different payment methods, and different usage mixes.

If usage is difficult to predict, pricing can combine a base subscription with included usage and an overage rate. Stripe documents several recurring and usage-based patterns, including flat-rate, per-seat, tiered, and usage-based pricing, in its recurring pricing documentation. The model should be selected for the product and customer experience—not just to transfer every cost fluctuation to the customer.

Common mistakes

Using a provider’s headline fee as a universal rate. Fees vary by region, payment method, contract, and currency.
Forgetting the fixed fee per transaction. This is especially material for low-priced plans and frequent small charges.
Treating all cloud spending as variable. Distinguish baseline capacity, commitments, shared services, and incremental usage.
Using average cost as marginal cost. Average cost helps allocate a bill; marginal cost estimates the additional expense of serving one more unit or customer.
Ignoring usage distribution. A few heavy users can dominate API or infrastructure costs even when the average customer appears profitable.
Mixing contribution margin with gross margin. State which costs are included and use the same definition when comparing periods or plans.

Connect contribution to break-even

Contribution per customer helps estimate how many customers are needed to cover fixed costs. If monthly fixed costs are $12,000 and contribution per customer is $42.78, the simple break-even estimate is $12,000 ÷ $42.78 = 280.5, rounded up to 281 customers. This assumes the same contribution for each customer and ignores changes in costs, churn, taxes, and customer mix. Use the SaaS Pricing Calculator to explore pricing and cost assumptions. Treat any calculator output as a model of the inputs provided, not as a substitute for your processor invoices, cloud usage records, or accounting definitions.

Limitations and next steps

A per-customer model is only as reliable as its cost attribution. Start with actual processor fees and provider bills, choose explicit allocation drivers for shared costs, and label assumptions. Reconcile estimates against monthly totals so the sum of customer-level allocations can be compared with the source invoices.

For a useful review cadence, track contribution per customer, contribution margin, usage per account, payment fees as a percentage of revenue, and the distribution—not just the average—of variable costs. Revisit the model when pricing, provider contracts, architecture, or customer behavior changes.

References

Stripe — Pricing & Fees. Published standard pricing and fee caveats; rates depend on the actual market and payment method.

AWS — Choosing a cost management strategy. Cost allocation and usage visibility guidance.

Stripe Docs — Recurring pricing models. Overview of flat-rate, per-seat, tiered, and usage-based subscription patterns.

This article was originally published on Letinix.

TypeScript Optional vs. Nullable: Model API Fields Correctly

Muhammad Azlaan Zubair — Wed, 21 Oct 2026 18:17:05 +0000

In TypeScript, an optional property and a nullable property describe different API states. name?: string means the property may be absent; name: string | null means the property is required but its value may be null. Use name?: string | null only when both conditions are allowed by the contract.

This distinction matters when you turn JSON into types: one sample can show a value of null, but it cannot prove whether the property may be omitted in other responses. If you have a sample ready, the Letinix JSON to TypeScript Converter can generate a starting declaration; review the result against the actual API contract.

The three shapes

Consider these illustrative API response shapes:

present.json

{ "displayName": "Mina" }

null.json

{ "displayName": null }

missing.json

{}

They are not interchangeable. The first contains a string value. The second contains the property with a JSON null value. The third does not contain the property at all.

Here are the corresponding TypeScript models:

user.ts

interface UserWithName {
  displayName: string;
}

interface UserWithNullableName {
  displayName: string | null;
}

interface UserWithOptionalName {
  displayName?: string;
}

interface UserWithOptionalNullableName {
  displayName?: string | null;
}

Choose the narrowest model that matches the documented contract. Making every field optional may quiet compiler errors, but it also weakens the guarantee your type provides.

What ? means

The ? modifier makes a property optional. An object typed with displayName?: string may omit that key:

usage.ts

const a: UserWithOptionalName = {};
const b: UserWithOptionalName = { displayName: "Mina" };

When you read the property, TypeScript must account for the possibility that it is absent:

usage.ts

declare const user: UserWithOptionalName;

const name = user.displayName;
// string | undefined when strictNullChecks is enabled

That undefined is a JavaScript read result; JSON itself has no undefined value. A missing JSON key becomes an undefined result when you access it as an object property.

With exactOptionalPropertyTypes, TypeScript also distinguishes an omitted optional property from explicitly assigning undefined unless undefined is included in the declared value type. This option is useful when the presence of a property has meaning in your application.

What | null means

A union with null allows a present property to hold a null value:

profile.ts

interface UserProfile {
  displayName: string | null;
}

const profile: UserProfile = { displayName: null };

The property is still required. This object does not satisfy UserProfile because the key is missing:

profile.ts

const profile: UserProfile = {};
// Type error: displayName is required

Use T | null when the API contract explicitly uses null to represent a known state, such as no assigned owner or no value available. Do not assume that a null in one example means the property can also be absent.

When both states are allowed

Some APIs allow the field to be omitted and also return null when it is present but has no value. If the API documentation or observed contract supports both cases, model them explicitly:

profile.ts

interface UserProfile {
  displayName?: string | null;
}

Consumers must then handle all three outcomes: a string, null, or undefined after reading an omitted property.

labels.ts

function labelFor(user: UserProfile): string {
  if (user.displayName == null) {
    return "Unnamed";
  }

  return user.displayName;
}

The == null check intentionally matches both null and undefined. If your logic needs to distinguish an absent key from an explicitly null key, test property presence separately with Object.hasOwn(user, "displayName") and then handle the value.

How to infer the right type from JSON

A converter can infer types from the values in the sample. It cannot infer every possible response state from a single object. A property that appears with a string in your sample may be absent in another response; a property that is null may be nullable, or the sample may simply not contain a non-null example.

Check the API's official schema or response documentation for required properties and nullability.
Compare multiple realistic responses, including empty, partial, and error responses where relevant.
Keep optionality and nullability separate in the type declaration.
Add a runtime check when the incoming payload is not guaranteed to match the documented contract.

The Letinix converter documents optional-key inference when objects in the same array have different keys, and it maps a field that is null in some array objects and has a value in others to a union with null. Those are useful inferences from the supplied sample; they do not replace the API specification.

Common modeling mistakes

Using ? to mean nullable. field?: string does not permit a present null value.
Using | null to mean optional. field: string | null still requires the property to exist.
Making every property optional. This can hide contract mismatches and make consumers handle states the API never permits.
Trusting one sample as a complete schema. Use authoritative documentation or more representative responses.
Assuming the type validates incoming JSON. Type declarations do not validate network data at runtime.

References

TypeScript Handbook: Object Types

TypeScript 4.4 release notes: exact optional property types

Letinix JSON to TypeScript Converter

This article was originally published on Letinix.