The cover illustrates a fictional store, not a deployed system or real test result.
Ready Parts’ cloud bill falls, but its completed orders fall by even more. Has the system become cheaper? I would not decide from one bill total. I would ask how many successful outcomes we bought, whether quality stayed the same, and how much work shifted from the provider’s bill to the team’s time.
Every figure here is hypothetical, showing a comparison method, not a package price, quote, company result, or real test. The idea drawn from FinOps is to connect spending to a unit that matters to the business. Any suggestion about which model the store should start with or switch to depends on the stated assumptions.
Choose a denominator that matches what customers receive
HTTP request counts help operate a system, but ten searches are not ten orders, and a 200 response with an incomplete record is not a success. Our example unit is an order recorded correctly, without duplication, whose result the customer can verify under the rules. Count each truly completed order once in the same month as the costs.
Use separate units for other journeys, such as cost per authorized, useful search or per document delivered by its deadline. Do not combine them into one unit whose meaning changes, or pad the denominator with failures to make per-unit cost look lower. Each unit needs a definition owner, data source, and reconciliation method.
Average cost per completed order = monthly cost within the defined boundary ÷ completed orders in that month; failed work and retries remain in the numerator. If no orders complete that month, the denominator is zero, so report the cost and incident separately, not a zero cost per order.
Include the costs that actually make the service work
Compute and database bills are only part of it. Include file storage, CDN, data egress, reads and writes, image conversion, backups, logs, monitoring, queues, and downstream services. If AI is used, include actual usage under its billing unit. Minimum readiness and capacity reserved for failures are costs of the chosen service level too.
On-call time, incident response, regular upkeep, and engineering effort allocated to the service belong in scope. Use an explainable allocation method, such as recorded hours or a verifiable usage share, rather than splitting everything evenly for convenience. If some cost cannot yet be separated, show the shared amount and estimation method instead of hiding it.
Keep uncertain business harm, such as sales possibly lost during an outage, separate from recorded spending. Do not multiply every minute of outage by revenue and call it certain lost profit. But include actual duplicate-order correction, refunds, or customer support effort within the agreed scope. Risk still matters when it cannot yet be priced in THB.
Compute, data, backups, and reserve capacity
Egress, reads and writes, retries, and downstream calls
On call, incidents, upkeep, and customer help
Two models with equal quality and scope
Suppose model A has THB 30,000 in monthly service operating cost plus an average THB 1.20 per completed order that varies with volume. Model B has THB 90,000 per month plus THB 0.40 per completed order. The monthly portion includes minimum infrastructure, reserve capacity, and allocated operating effort. The volume portion already includes related work, egress, retries, and expected failures under the same work mix.
This is an operating-cost model within the example’s boundary, not company-wide cost or sales profit. Assume service quality, correctness, and the volume range are comparable under the formulas, with no step changes or added capacity limits within the table’s range. If those assumptions fail, recalculate; do not extend the straight lines forever.
Write A = 30,000 + 1.20Q and B = 90,000 + 0.40Q, where Q means completed orders per month, not cumulative registered users. The operating costs are equal at 60,000 ÷ 0.80 = 75,000 orders per month; both cost THB 120,000 there. This is where the two options have equal costs, not the store’s profit break-even point.
| Completed orders/month | Model A cost | Model B cost | Average A/order | Average B/order |
|---|---|---|---|---|
| 20,000 | THB 54,000 | THB 98,000 | THB 2.70 | THB 4.90 |
| 75,000 | THB 120,000 | THB 120,000 | THB 1.60 | THB 1.60 |
| 100,000 | THB 150,000 | THB 130,000 | THB 1.50 | THB 1.30 |
One more order is different from the average cost
TC/Q is average cost. Marginal cost compares a change in total cost with a change in output, or ΔTC/ΔQ over a stated range. In these hypothetical straight-line formulas, the volume-dependent marginal amounts are THB 1.20 for A and THB 0.40 for B per order. That does not make average cost equal to those numbers or prove we can add work forever without a new capacity step.
Past the modeled range, another on-call person, database, or service plan might cause a cost jump that must be included. If the team is already fully occupied, added volume may also displace important improvement work. A low technical price per request does not mean people are available to own more business outcomes for free.
THB 30,000 + 1.20Q per month
THB 90,000 + 0.40Q per month
Both cost THB 120,000 per month
Monthly operating costs for two models at hypothetical volumes
Monthly service operating cost (THB)
Completed orders per month (orders)
- A = 30,000 + 1.20Q
- B = 90,000 + 0.40Q
- 75,000 orders / both cost THB 120,000
A falling average as volume grows does not prove long-run economies of scale
While some costs are fixed, more volume can spread them over more orders. That alone does not prove that, once all inputs can change, a larger operation always achieves “lower long-run average cost”. Economic short and long run differ by which inputs can be adjusted, not by an automatic rule that month three or year two is “long run.”
Shared tools, specialized skills, and buying power may lower cost with growth. Coordination across teams, multiple data stores, monitoring several regions, and incidents with wider impact may raise it. Compare total cost at comparable service levels; a lower per-machine price alone cannot settle it.
Returns to scale describes how output changes with inputs; economies of scale describes long-run average cost. They can be related but are not the same term. I explain the foundation in Economics for Business, Episode 5. This web example should use the term that matches what was actually measured.
Before switching to B, count transition costs and displaced work
At 100,000 orders per month, B’s modeled service operating cost is THB 20,000 per month below A’s, before switching costs. Suppose development, migration, testing, and a period of overlap total THB 60,000 once. The same monthly difference sustained for three months equals that amount in a simple calculation, excluding time value of money, risk, and costs still unknown.
One month at that volume is therefore no reason to move immediately. Check whether volume is reliable or seasonal, whether B has passed the quality tests, and whether the team can migrate without sacrificing essential work. This simple equality period is not net profit or a promised return, and changes with volume or budget.
Also account for the opportunity cost of work displaced: the team may postpone a fix affecting existing customers. Estimate the net benefit of the best forgone option, not every item on a wish list. Do not count allocated salaries and the full opportunity cost again without explaining the accounting base. Keep economic comparison distinct from reported spending.
Use a managed service when the time it buys back is worth it
A managed service may reduce operations work the team performs, but does not promise the lowest bill. Usage billing can fit some periods; code that loops over API calls or retries without limits can also raise spending quickly. Flexibility needs caps, alerts, and someone who decides when a budget is exceeded.
Compare both the work the provider takes and the duties we retain: data planning, access, restore testing, and customer responsibility. A long-term discount suits a well-understood usage baseline; do not lock in excess capacity for an attractive discount percentage. Plan how to reduce or move resources before committing.
Average total cost per completed result
Cost change as volume changes within the stated range
For the fictional store, I would choose the option that meets the service level at lower total cost over a volume range supported by evidence, with room for transition spending and uncertainty. If evidence is thin, choose a reversible path and collect data rather than invest for an imagined huge audience.
Report costs so people can decide
A monthly report should show completed-order count, definition and service level, costs by category, average cost, causes of change, and estimates still unresolved. Put cost charts beside failed work and team time. If cost per order rises, first determine whether volume fell, each order became heavier, or a new readiness cost was added. Do not cut reserve capacity without checking service impact.
The final episode turns these criteria into a staged test plan, from measurement and work reduction to adding capacity, with rollback. Budget approvers and operators should be able to read the same evidence and stop scaling when it no longer buys worthwhile outcomes.
Read the sources and limits of the example
The following sources explain the concepts and limitations and were checked on October 18, 2026. The fictional store numbers and choices are my synthesis, not provider prices, test results, or guarantees. Check the current version, plan, and terms before applying them.