Suppose the team has closed the recovery and incident-ownership gaps from part four, agreed on scope with the application owner, and let one application use the production database service. A work cycle later, more people request databases and service charges rise. The question is whether users can do enough better work to justify the continuing operating burden.
This continues the fictional situation, not a Supaket or client launch result. Part four, by contrast, ended by deferring the production move to gather more evidence. This article adds a new assumption: the team did that work and launched within agreed boundaries. We can now consider the decision after launch.
Start with the work users need to finish
For a database service, a successful provisioning request shows that the entry path works. It does not show that an application can read, write, and complete its business work. I would ask the owner to name an important task we can check, such as recording a transaction and retrieving it correctly. Then examine how often that task succeeds, where it waits or fails, and how many times the platform team has to help behind the scenes.
Look at people who begin using the service and continue, as well as those who stop. Do not substitute login counts or database counts for the value of the work. People may have been required to use it, and unused databases make the total look high without work getting done. If users switch to another method, ask about the actual job before calling the platform a success or failure.
From request to completed work
- RequestWho requests it for what task, and how long until they can start?
- WorkCan the application read, write, and complete the agreed business task?
- Get helpWhen work stalls, whom do users wait for, and who helps them resume?
- Continue or retireIs the work still needed, and what remains after use ends?
Compare similar kinds of work over comparable periods, and disclose any extra help or simultaneous application changes. Shorter waits due to an operator manually fixing every request benefit users, but do not yet prove the service is easier to run.
See the money spent and the work still owed
Invoices show machines, storage, backups, and networking. Other costs sit in the time spent configuring, updating, checking access, rehearsing recovery, handling incidents, and helping users. I would record these in different units: spending in THB, people's time in hours and other work delayed. Do not multiply hours by wages and announce cash savings when no expense actually changed.
Shared expenses, such as monitoring systems and on-call staff, can be allocated across services under a stated rule to see total cost. FinOps Allocation helps define how common costs are shared, while Unit Economics connects costs to a unit meaningful for the business, not just resource consumption. Here that unit could be an application job completed to the same definition, rather than API requests. One job may make many requests.
Allocated total cost and the spending that would actually change with a new decision answer different questions. If another application joins, the existing monitoring subscription may not rise, while backup storage, testing, and incident work may rise immediately. If the service ends, the whole shared cost may not disappear from the budget. Check which resources or contracts can actually stop being paid for, and when. Money already spent is no reason to keep running a service that no longer makes sense.
Direct costs plus a disclosed share of common costs, using the same allocation rule across periods
Which spending and work would rise, be avoided, or persist if we expand, improve, or retire?
For cost per completed job, include successful, failed, and retried work from the same period and scope on the cost side. Count only business jobs completed under the agreed definition in the denominator; retries are not extra jobs. Record people's time for all this separately in hours rather than adding it to THB. Compare similar job mixes across periods. A falling unit cost does not automatically justify expansion: a new use may involve more sensitive data, after-hours response, or specialized people, so burdens and risks may grow faster than volume. If unit cost rises, examine why. Necessary reliability for real work is not automatically waste.
Meet again to choose the next action
I would bring the work owner, application team, platform operators, and budget owner to the same period of evidence: completed jobs, user problems, expenses, actual operating work, and unmet needs. Talk to current and former users. End with an option that has an owner and a review date, rather than one combined score that hides the problem to fix.
| What the review finds | Possible decision | Next checkable work |
|---|---|---|
| Users complete jobs but repeatedly wait for an operator at the same step | Improve what is already running first | The operator and application team fix that bottleneck, then measure waits and help hours again for the same kind of work. |
| Current work is supportable, a new need names a clear job, and the added people and cost can be carried | Try limited expansion | The work owner and operator agree on scope, incremental spending, incident coverage, stop conditions, and a review date before taking requests. |
| The need has disappeared or a better option exists, but users, data, or contracts remain | Plan retirement or migration | The work owner tells users. The data team checks retention needs. Operators assess one-time migration costs, permissions, resources, contracts that cannot yet end, and spending that would truly stop. |
If a problem affects data correctness or access within the live scope, manage that risk immediately according to its impact rather than waiting for a scheduled review. An attractive expansion request can wait until someone owns the added work. Unit savings among current users do not prove another service type will be equally cheap and easy to operate.
Retirement also needs an owner. Tell users the schedule and options, migrate or export data under the terms, check access and backups that must be kept, close resources when safe, and count one-time migration and support costs plus contractual commitments that cannot yet be ended. Only then compare them with spending that will really fall in the next period. Deleting a database alone does not erase the work or responsibility.
Make "worth it" a condition we can revisit
A one-page decision record should state the work scope, evidence period, chosen reason, rejected alternatives, owner, and next review date. The question I want the work owner and operator to answer together is if we operate this service for one more cycle, what can users do because of it, and who carries the resulting burden? If they cannot answer, an existing launch is no reason to accept more requests yet.
Source and scope
The common-cost and unit-cost ideas draw on FinOps Allocation and FinOps Unit Economics. The database work, diagram, table, and proposed review apply those ideas to a hypothetical case. They are neither measured results nor FinOps-certified criteria for this platform. A real service's worth depends on that organization's costs, completed work, and obligations.