Price the work syllabus

The floor under your price

You have a cost model for a system from the technical side: tokens, watts, wall-clock. This is the same arithmetic with the parts nobody enjoys adding — the support hours, the monitoring, and the failure you will be fixing on a Sunday.

Everything that arrives every month

Six lines, and most quotes contain two of them:

  1. Inference or API spend at the volume in the scope, not the demo volume.
  2. Hosting, storage, and whatever the thing runs on.
  3. Monitoring — including the cost of noticing quietly wrong output, which is the expensive kind.
  4. Support hours at your actual rate, driven by the exception rate.
  5. Model and dependency churn: the version you built on will change.
  6. The cost of the client's own time, if their people have to check outputs. Not your cost, but it belongs in the conversation, because it decides whether they keep using it.

Cost your own scope

Take the scope from the last lesson and put a monthly figure on all six lines. Where you genuinely do not know, put a range and mark it.

For support, do it properly: estimate the exception rate, multiply by the volume in the scope, and multiply that by how long an exception takes you to resolve. A 3% exception rate on 2,000 items a month at fifteen minutes each is 15 hours. That is not a rounding error, it is most of a working week.

Your monthly run cost

The total of all six lines. This is the number below which a support retainer loses you money every single month, indefinitely.

What share of it is support?

Support hours as a percentage of the monthly total. Most people are shocked by this, and it is the number that should decide how much engineering effort goes into reducing the exception rate rather than improving the happy path.

The fixed-price trap

A client wants one fixed price, everything included, no ongoing fee. What is the actual problem with agreeing?