Plant managers have learned to fear software bills that arrive per seat, per site and per module, rising every renewal. This platform is priced differently: the company rents hosting, a database and a coding agent, and builds the rest. The total is small, but it is not zero, and the case you make in chapter 3 is only believable if every line is in it.

Every line, free way first

What makes each line grow

The line people forget: your time

Someone must review the agents' pull requests, apply dependency updates, run the monthly drills from the runbook, answer questions from the floor and read the bills. Count it. In the worked example it is 6 hours a month of the platform owner's time, valued at their loaded hourly rate (chapter 2). That is $330 a month, nearly twice the tools.

• Monthly: review and merge dependency updates; one runbook drill; read the three bills.
• Weekly: read the incident log and the health monitor's history; answer requests.
• Per change: write the brief, review the pull request, check the preview on your phone.

Keep it from growing unnoticed

The FinOps Foundation's framework for managing cloud costs comes down to three habits: make costs visible to the people who make the decisions, optimise what you see, and review it on a schedule ^[6]. For one plant platform:

1. Spend limits on. Supabase Pro has a spend cap, on by default, that stops usage charges beyond the included amounts; leave it on until you choose otherwise ^[7]. Vercel's spend management lets you set a monthly amount with alerts, and can pause projects when it is reached ^[8].
2. One card, company-owned, on every account, with bills going to a shared finance mailbox, not a person's inbox.
3. A monthly bill review as a line in the runbook: compare each bill with last month and write one sentence on anything that moved.
4. The AI line is a choice. A subscription is predictable; the API is pay-as-you-go and can be cheaper for light use or far dearer for an overnight fleet (F01 chapter 11). Decide deliberately and write the decision down.

What it can replace

Measuring hours: a ten-sample time study

Lean practitioners time each step of a task several times and use the typical time, because single timings mislead ^[1]. You need nothing more than a stopwatch and a sheet of paper:

1. Pick a task the platform changes, with a clear start and end ("from opening the downtime sheet to sending the shift report").
2. Time it ten times before go-live, with the people who normally do it, on normal shifts. Write every sample down.
3. Time it ten times again a month after go-live, when the new way is habit.
4. Multiply the difference by how often the task happens a month.
5. Multiply the hours by the loaded rate.

Tell people what you are timing and why: you are measuring the task, not the person. The aim is to show what the platform saves them.

The loaded hourly rate

An hour of someone's time costs the company more than their wage: paid leave, insurance, retirement contributions and legally required payroll taxes are added on top. The US Bureau of Labor Statistics publishes these costs every quarter; for private industry, wages and salaries make up roughly 70% of total compensation and benefits about 30% ^[2]. So a quick loaded rate is:

loaded hourly rate ≈ hourly wage ÷ 0.70      (check the current BLS release, or ask your finance team for the company's own figure)
example: a $28.00 wage → about $40 an hour loaded
example: a salaried owner at $77,000 a year → $77,000 ÷ 2,080 h = $37.02 an hour → about $53, rounded to $55 with overheads

If your finance team has the company's own burden rate, use theirs: it is the number they will trust.

How much freed time to count

Time saved becomes money only if the time goes somewhere useful: overtime not worked, a vacancy not filled, a supervisor on the floor instead of at a desk. Some of it disappears into the day. A cost estimate should state such assumptions openly and show what happens if they are wrong, as the US Government Accountability Office's cost estimating guide recommends ^[3]. The worked example counts half the freed hours as value and says so on the page; chapter 3 shows the case still holds if the share is lower.

The worked example

An illustrative plant, not a named one: a 140-person machining plant on two shifts. The platform replaced a per-user forms app ($500 a month) and the paper-to-spreadsheet routine for downtime and quality checks. The owner, a production engineer, spent about 80 hours on the course and the build; the company pays two owners' seats and a Claude Max subscription.

Add anything else you paid to get here, such as course fees or a consultant's day, to the build cost. The case is only as honest as its most awkward line.

Payback

Payback is the build cost divided by the monthly net value: $4,400 ÷ $1,122 ≈ 3.9 months. It is the number most managers ask for first, because it needs no discount rate and is easy to check.

Three-year cost of ownership

Total cost of ownership compares the full cost of each option over the same period, here three years, including people's time. It answers "what does each way of working cost?" rather than "what does the platform save?", which some finance teams prefer.

Test the case: sensitivity

Every number in the case is an estimate except the bills. The GAO guide's advice is to vary each assumption and show the effect, so the reader sees which ones matter ^[1]. Vary each by half either way and redraw the three-year value:

• If one bar dominates (here, hours saved), spend your measuring effort there: more samples, more tasks.
• If any bar crosses zero, say so plainly and say what would have to be true for the case to hold.
• Re-run it at three months with measured after-timings and the real bills. A case that is updated is trusted; regular review is the third of the FinOps habits from chapter 1 ^[2].

One page

cost-case.csv: fill in the amount column from your own bills and timings; the formulas live in the spreadsheet.
item,amount,unit,source
build_hours,80,hours,timesheet
loaded_rate_owner,55,$/hour,finance burden rate
tools_monthly,174,$/month,"GitHub, Vercel, Supabase, AI agent bills"
upkeep_hours_monthly,6,hours/month,owner's log
subscriptions_retired_monthly,500,$/month,cancelled invoices
hours_freed_monthly,56.3,hours/month,time studies
loaded_rate_staff,40,$/hour,wage / 0.70
share_of_freed_hours_counted,0.5,fraction,stated assumption
# net_monthly = subscriptions + hours_freed * rate_staff * share - tools - upkeep_hours * rate_owner
# payback_months = build_hours * rate_owner / net_monthly
# value_3yr = 36 * net_monthly - build_hours * rate_owner

1. The decision asked for: keep the platform and retire the named subscriptions.
2. Three numbers: build cost, payback in months, three-year value.
3. The table of assumptions, each with its source, and the share of freed hours counted.
4. The sensitivity chart and one sentence on what would make the case fail.
5. What is not counted: errors avoided, faster holds on suspect product, better decisions. Name them without putting a number on them unless you measured it.