A strange thing happens inside modern software companies: engineers can tell you the latency of an endpoint to the millisecond, but often nobody can tell you what executing that endpoint actually costs. That gap matters more than it used to. The broader financial discipline described in Business Finance That Actually Prevents Failure becomes much more concrete when applied at the software layer, because a growing number of products now accumulate real costs every time a user clicks a button, uploads a file, generates an image, runs a search, sends a message, or asks an AI model a question. A feature can be technically successful, heavily used, loved by customers—and economically terrible.
For decades, software benefited from an attractive assumption: once the product was built, serving one more user was comparatively cheap.
That assumption has not disappeared, but it has become dangerously unreliable.
A modern application may call an LLM, invoke an OCR service, generate embeddings, query a vector database, send an SMS, use a geocoding API, process an image, write logs to an observability platform, transfer data across regions, run a serverless function, store the result, and pay a transaction fee before the user sees a single response.
Each component might look inexpensive in isolation.
The feature is not.
We Still Design Features as if Compute Were Free
Imagine a startup selling an AI document-analysis product for $49 per month.
The product team launches a feature called “Deep Review.” Users upload contracts and receive a detailed analysis.
Engagement is excellent.
Customers love it.
Usage grows rapidly.
Everyone celebrates.
But one Deep Review is not one operation. Behind the button, the system might extract text, classify pages, call a large model several times, generate embeddings, search stored context, call another model to verify the answer, save the output, and retain the source document.
Assume, purely as an example, that an ordinary review costs the company $0.18 to process.
That sounds irrelevant.
Then someone uploads a huge document.
It needs multiple OCR passes. Chunking creates dozens of model calls. A retry fires after one provider times out. The verification step receives far more context than expected. That review costs $1.40.
A customer on the $49 plan runs 70 of them.
The customer has paid $49.
The company may have spent close to the entire subscription price on one feature before paying for databases, support, engineering, payment processing, salaries, or anything else.
The feature has not failed.
Its economics have.
This is one of the most important architectural changes developers need to recognize: in a metered software stack, product behavior and financial behavior are no longer separate systems.
“Cloud Bill” Is Too Coarse a Data Type
A monthly infrastructure bill tells you approximately as much about product economics as total CPU utilization tells you about which endpoint is slow.
You need attribution.
If the company spends $80,000 on infrastructure, the interesting questions are not limited to “Why is AWS expensive?” or “Can we reduce the bill by 10%?”
The interesting questions are:
Which customers caused the spend?
Which workflows caused it?
Which product tier generated it?
Which release changed it?
Which feature creates the highest gross profit?
Which popular feature becomes less profitable as usage increases?
Which customer appears valuable in the CRM but loses money after its actual resource consumption is included?
This is not merely a finance problem. AWS’s work on SaaS cost attribution makes the architectural implication clear: understanding resource consumption at the tenant and feature level can influence pricing, product decisions, and architecture itself.
That is a radically better framing than “engineering needs to reduce cloud costs.”
Cost is not something finance discovers after engineering has finished building.
Cost is an output of the architecture.
Cost Should Travel With the Request
Most applications already propagate context through their systems.
A request may carry a user ID, tenant ID, trace ID, session ID, request ID, experiment ID, region, and application version.
Why not economic context?
Suppose an AI workflow generates an event after each billable or resource-intensive operation:
{
"tenant_id": "tenant_482",
"feature": "deep_review",
"operation": "contract_analysis",
"provider": "model_provider",
"model": "large_model",
"input_units": 43820,
"output_units": 6140,
"estimated_cost": 0.173,
"request_id": "req_91af",
"release": "2026.08.18"
}
This is not intended to replace the provider's invoice.
It solves a different problem.
The invoice tells you what the company owes.
Application-level cost attribution tells you what created the obligation.
Once that information exists, entirely new questions become easy to answer.
You can compare feature revenue with feature cost. You can identify customers whose usage patterns are structurally different from everyone else's. You can discover that a new release increased the cost of a workflow. You can compare two implementations not only on latency but on cost per successful outcome.
Most importantly, engineers gain a feedback loop.
Without that loop, architecture has financial side effects that remain invisible until someone notices the monthly bill.
The Most Dangerous Customer May Be Your “Best” Customer
SaaS dashboards train teams to celebrate heavy users.
More sessions.
More queries.
More generated content.
More uploaded files.
More API calls.
Usually, those are good signs.
But usage and value are not identical.
Consider two customers paying $500 per month.
Customer A makes 2,000 lightweight requests, rarely contacts support, and consumes $35 of variable infrastructure.
Customer B makes 70,000 requests, uploads unusually large files, frequently triggers the most expensive workflow, stores enormous amounts of generated data, and consumes $430 of variable infrastructure.
A revenue dashboard sees two $500 customers.
An economic model sees two completely different products being delivered at the same price.
This becomes especially important when software contains AI workloads. The economics of AI are unusually sensitive to behavior because the cost of serving two apparently identical users can differ dramatically depending on context size, model selection, number of generations, retries, media processing, agent loops, or tool calls.
That is one reason Stripe’s analysis of pricing for AI products focuses on connecting pricing with actual consumption and underlying compute economics rather than assuming the traditional flat subscription automatically works.
Developers do not need to become pricing consultants to care about this.
They need to understand that unbounded product behavior can create unbounded financial behavior.
An Infinite Loop Can Now Appear on the Income Statement
Software engineers already protect systems against technical runaway conditions.
We limit recursion.
We set timeouts.
We cap retries.
We rate-limit APIs.
We kill jobs that run for too long.
We stop queues from expanding indefinitely.
But consider an AI agent.
The agent receives a task, calls a model, invokes a tool, reads the result, decides it needs more information, calls another tool, queries the model again, retries an unsuccessful step, expands its context, and repeats the cycle.
From a technical perspective, the workflow may still be functioning exactly as designed.
From an economic perspective, it may have entered a runaway loop.
This produces a new category of engineering requirement: financial bounds.
An operation should not only have a timeout. It may need a cost ceiling.
A job should not only have a maximum retry count. It may need a maximum cumulative inference budget.
A customer should not only have an API rate limit. The application may need a resource budget based on the economics of the customer's plan.
A feature should not only satisfy latency and reliability requirements. It may need an acceptable cost-per-successful-execution range.
That sounds obvious once stated.
It is rarely treated as a first-class software requirement.
Put Economics Into the Pull Request
Here is where things get more interesting.
Suppose a developer improves an AI workflow.
The old implementation makes one expensive model call.
The new implementation performs five smaller calls because the developer discovers that decomposition improves answer quality.
The accuracy benchmark improves 8%.
The latency remains acceptable.
Tests pass.
The pull request looks excellent.
But suppose the cost per successful workflow rises from $0.11 to $0.39.
Is the new version better?
There is no universal answer.
If customers pay $20 every time the workflow succeeds, almost certainly.
If it is included without limits inside a $9 monthly plan, perhaps not.
The point is that the economic regression belongs in the engineering discussion.
Teams already reject code because it creates unacceptable latency, memory consumption, security exposure, or reliability risk.
Why should a 250% increase in variable cost remain invisible?
For measurable workflows, teams can go surprisingly far with simple tooling.
A benchmark suite can record the number of external calls.
It can record input and output units.
It can estimate compute duration.
It can compare those values with a baseline.
It can flag a pull request that makes a common workflow dramatically more expensive.
Not every cost estimate will be perfect. It does not need to be.
A smoke detector does not need to calculate the insurance value of the house before it becomes useful.
The Database Query That Saves $50,000 Is Still an Optimization
Developers frequently debate optimization using technical language.
This query is 200 milliseconds faster.
This cache reduces database load.
This architecture supports more requests per second.
This model produces better answers.
Those are legitimate improvements.
But at sufficient scale, some of the highest-impact performance work may be invisible when measured only in milliseconds.
Imagine that a high-volume request performs three redundant database operations. Removing them saves an amount so small per request that nobody cares during development.
Multiply that amount across hundreds of millions of executions.
Now it matters.
Or imagine that an image-processing workflow keeps the original, intermediate files, generated variants, and debug artifacts forever.
Nothing breaks.
Storage simply compounds.
Or a tracing configuration sends huge payloads for successful requests that nobody will ever inspect.
Or an AI application sends an entire conversation history back to a model even when only a small section is relevant.
Technically, the product works.
Economically, the implementation contains waste.
The important shift is not “developers should always choose the cheapest architecture.”
That would be bad engineering.
The shift is: developers should be able to see the economic consequence of architectural choices.
Sometimes paying more is absolutely correct.
A more expensive model may improve conversion enough to justify itself.
Additional redundancy may be essential for reliability.
Lower latency may generate enough business value to justify significantly higher infrastructure spend.
Premium observability may reduce incident duration.
The goal is not minimum cost.
The goal is deliberate cost.
“Unlimited” Is an Engineering Decision
Product teams love the word “unlimited.”
Customers do too.
Engineers should hear something else when they see it:
What technically prevents one user from consuming 10,000 times more resources than another user paying the same price?
Sometimes the answer is that nothing prevents it because marginal cost really is negligible.
Fine.
Sometimes the answer is that extreme usage is statistically rare enough that the economics still work.
Also fine.
But sometimes “unlimited” simply means nobody modeled the tail.
Average users are frequently irrelevant to infrastructure risk. Outliers matter.
The same principle appears in performance engineering.
A system with a 100 ms average response time can still be terrible if its tail latency is 12 seconds.
Product economics also have tails.
The average customer may cost $6 per month to serve while the top one percent costs $90.
If pricing was designed around the average, growth can gradually select for the customers who exploit the mismatch most effectively.
That is not abuse.
They are using the product you sold them.
Build a Cost Map Before You Build a Cost Dashboard
You do not need a massive FinOps implementation to start.
You need to understand where money enters the execution path.
For one important customer action, trace the full chain from click to result and identify every resource whose cost changes with usage.
For example:
- Trigger: user requests a video analysis
- Variable work: upload, transcoding, model inference, object storage, database operations, data transfer, notifications
- Cost driver: video duration, resolution, model runtime, generated output size
- Customer dimension: tenant, plan, geography, contract type
- Product dimension: feature, workflow version, experiment
- Business output: successful analysis, revenue associated with usage, gross contribution
That is the only list this article needs because the important part comes afterward.
Instrument one workflow.
Not the entire company.
Pick the feature that is expensive, rapidly growing, strategically important, or difficult to understand.
Then ask a question most teams cannot currently answer:
What happens to our gross profit if usage of this exact feature increases 10x tomorrow?
If the answer requires three people, two spreadsheets, a cloud invoice, and a week of analysis, the architecture is hiding business-critical information.
The Best Architecture May Depend on Who Is Using It
Cost attribution also complicates a sacred engineering instinct: finding the single “best” implementation.
There may not be one.
An enterprise customer paying $50,000 per year might justify a computationally expensive workflow that produces the highest possible accuracy.
A self-service customer paying $12 per month may need a different model, smaller context window, lower retention period, asynchronous processing, or stricter usage limits.
That is not necessarily an inferior product.
It is resource allocation.
Cloud architecture already changes resources according to workload. Product architecture can do the same according to economics.
Model routing is an obvious example.
A request does not automatically need the most capable model available.
A lightweight classification might go to a smaller model. An ambiguous case can escalate. A high-value workflow can justify a more expensive path. Repeated context can be cached. Inputs can be compressed. Work that does not require immediate completion can be batched.
The interesting engineering problem becomes:
What is the cheapest execution path that still delivers the required outcome?
That is much better than asking engineers to “cut AI costs.”
Your Unit Test Knows Whether the Function Works. It Could Also Know Whether the Business Model Still Works.
Software development has spent decades moving failure detection earlier.
We moved testing from users to QA.
Then from QA to automated test suites.
Then into continuous integration.
We moved security checks into development pipelines.
We moved dependency scanning into pull requests.
We moved performance benchmarks closer to the code.
The same direction makes sense for variable product economics.
A feature whose economics are only discovered on a monthly invoice has a feedback loop measured in weeks.
A feature whose resource consumption is measured during development has a feedback loop measured in minutes.
That does not mean putting the CFO in GitHub.
It means recognizing a simple truth:
In modern metered software, cost is increasingly a runtime property.
Runtime properties belong close to engineering.
The Next Generation of Great Developers Will Understand the Machine and the Meter
There was a period when a developer could reasonably treat infrastructure economics as someone else's concern.
Servers were purchased centrally. Finance handled contracts. Product set pricing. Engineering built the application.
Cloud computing already weakened that separation.
Serverless weakened it further.
API-first software weakened it again.
AI may finally destroy it.
A developer can now add a few lines of code and change the company's variable cost structure instantly. Choosing a different model, changing context length, adding a second validation pass, moving data between regions, retaining files longer, increasing observability volume, or introducing a third-party API can alter the economics of a feature without changing its price by one cent.
That gives engineers more responsibility.
It also gives them more influence.
The developer who can say, “This version is faster,” is useful.
The developer who can say, “This version is faster, improves successful completion by 6%, and reduces cost per successful task by 31%,” is participating in the business at an entirely different level.
The future of software engineering is not about turning developers into accountants.
It is about giving architecture one more observable property.
We already measure whether software works.
We measure how fast it works.
We measure whether it is available.
We measure whether it is secure.
Now, for the growing class of software in which every meaningful action consumes metered resources, we should measure one more thing:
Was executing it worth what it cost?
Top comments (0)