How do you document cost assumptions inside a PRD?

How to answer this, stage by stage

Seven moves. This is arithmetic with one honesty problem folded in, so what's being graded is whether you flag your own weak assumption before the interviewer finds it.

Let's learn

Say a small law firm has a feature that reads everything a new client uploads, a passport, an employment letter, an old case file, and writes a one-page summary the attorney reads before the first call. Before the feature, a paralegal read the whole file by hand and wrote that summary herself. About forty minutes a file. Now the feature does the same read in under a minute, for about five cents.

The equation is short. Cost per intake equals the tokens in the file, times the price per token, times how many times the summarizer actually runs before the file is done. The first two terms come from the model and its price list. The third term comes from a person deciding they're not satisfied yet, and it's the one that quietly gets skipped.

Here's what that cost at its worst. The dollars stayed small. Across the forty small firms using this feature, the documented compute line was about thirty seven dollars a month. The real one, once reruns were counted honestly, was closer to a hundred and twenty five. Nobody's budget broke. But the PRD had told finance a number, and three months later a different number showed up on an invoice with no warning in between.

The choice I would take back. Writing "one call per intake" as a flat line in the cost section, the same confident way the token count got written, instead of giving it its own range and its own source. Token counts came from real files. That number came from nowhere.

What I would leave alone. The token price itself doesn't need micro-tuning. It's public, it updates on its own when a vendor changes it, and chasing the fourth decimal place is time not spent on the term that actually moves the total.

The lesson. If the part of an estimate that swings the most is also the part with no real source behind it, the estimate wasn't finished. It was the easy eighty percent, dressed up to look like the whole hundred.

Now here is the same thing as a story

Skip this if a wrong PRD number already keeps you up at night. Read on if it doesn't yet.

Nusrat Karim has written eleven PRDs at Casebridge, a small legal-tech company that builds AI add-ons for law firms too small to build their own. Every one of the eleven shipped on schedule, and every one had a cost section finance never had to ask her about twice.

The eleventh was Intake Assist: a feature that reads everything a new client uploads and writes a one-page case summary for the attorney's first call. Solmar Immigration Law, a five-lawyer practice, was the first firm to turn it on.

For the first two months, the invoices matched her PRD almost to the cent. Eighteen intakes a month, about a nickel each, under a dollar total. She'd written "calls per intake: 1" in the cost section without a second thought, the same way she'd write a token count. It felt like a fact, not a guess.

Then Solmar's staff got comfortable with the feature. A client would email a missing employment letter after the first upload, and instead of adding it to next week's file, someone would just rerun the summary. An attorney, prepping for a second call, would ask for a refreshed one-pager after the first conversation turned something up. A typo in a client's name would get fixed by rerunning the whole thing rather than editing the output by hand.

None of this looked like a habit changing. It looked like three different people, three different weeks, each doing the sensible thing in the moment.

It surfaced on a Tuesday, the way weather does, not a headline. A customer success lead mentioned it in standup, in passing. "Solmar's bill came in almost four times what we quoted them, by the way. Nobody's complained. Just flagging it."

Nusrat pulled the raw call logs that afternoon. Average calls per intake at Solmar: 3.4. Not one. She checked two other firms on the same feature. 2.9. 3.6. Nobody had told her to check, and nobody had complained, because the actual dollars were still small. The number had simply been wrong, quietly, for three months.

She ran the same math across all forty firms live on Intake Assist. The line item she'd told finance to expect was thirty seven dollars a month. The real one was closer to a hundred and twenty five.

Here's what I want to be honest about: the dollars were never the danger. Even at the real, higher number, Intake Assist still cost a fraction of what a paralegal's forty minutes was worth. If Nusrat had sized this generously from day one, nobody would have noticed or cared. The danger was that she'd written one confident number for the single term in the equation that wasn't really a model fact at all. It was a guess about how people would use a new tool, and guesses about people are exactly the kind that belong in a range, not a fact sitting next to a token count.

She remembered the exact moment she wrote it. Drafting the cost section the week before launch, tokens and prices lined up neatly from the price list, and then a blank line for "usage assumptions." She typed "1 call per intake" because leaving it blank felt worse, and a range felt like admitting she didn't know, in a document that was supposed to sound certain.

The PRD she rewrote after that Tuesday gives calls per intake its own row next to the token math, instead of underneath it: one to four calls, sourced from ninety days of real logs across three firms, checked every quarter against the actual invoice. The next feature she scoped got the same treatment before launch, not three months after. Its first real invoice came in at four dollars and ten cents a firm, squarely inside the two-to-nine-dollar range she'd printed on page one. No standup remark. No surprise.

The equation never changed. What changed was which line in it she was willing to call a guess, out loud, in the document itself.

Same equation. The missing piece was never a number, it was a source.

BOUND, letter by letter, for this cost section

This is a sizing question with a documentation habit riding on top, so BOUND fits and FLIPS doesn't. Nobody's behavior snapped here. A PM wrote a number that felt like a fact and it was actually a guess.

The range on the model side. The felt check on the right is the number that proves the range never mattered financially, only honestly.

B, break it down. Cost per intake equals the file's tokens, times the price per token, times how many times the summarizer actually runs before the file is considered done.
O, own the numbers. 18,000 input tokens and 600 output tokens for a typical Solmar file, from a sample of forty real intakes. $0.0025 per 1,000 input tokens and $0.010 per 1,000 output, from the public price list. One call per intake, guessed, with no source, which is exactly the problem.
U, use a range. About three cents a call on a simple file to eight cents on a complex one. Combined with one to four calls, the honest monthly range for Solmar runs from under a dollar to about six dollars, not the single nickel first quoted.
N, nail the sanity check. Even the high end is a rounding error against the twenty three dollars of paralegal time a summary replaces. The tool was never the risk. The undocumented guess was.
D, direction. Calls per intake swings the total the most, more than the token price and more than the file size, because it's the one term nobody sourced, and it moved by more than three times once real firms started using the feature their own way.

And if you want to be sure it really works, try it somewhere else

A small city's planning office uses a similar feature: it reads a building permit application, drawings included, and writes a one-page review brief for the assigned planner.

B, break it down. Cost per permit equals the packet of forms and drawings in tokens, times price per token, times how many times the applicant resubmits before the file is complete.
O, own the numbers. Packet size swings wildly here, from an 8,000-token kitchen remodel to a 200,000-token environmental report for a subdivision. Same price tiers as before. Resubmission calls, pulled from real permit-office logs, average 2.1 per application, not 1.
U, use a range. From about a cent for a small remodel to well over a dollar for the biggest environmental filings, before resubmissions are even counted.
N, nail the sanity check. A planner spends about twenty five minutes on a first read of a permit file by hand. Even the priciest environmental case, resubmissions included, costs a fraction of that in compute.
D, direction. Here it isn't resubmissions that swings the total the most. It's packet size, because a two-page remodel and a two-hundred-page environmental report sit in the same queue, a swing no call-count assumption could ever hide. The opposite lesson from Solmar's case, where every file was roughly the same size and only the call count moved.

Swap the trigger and it still runs.
Speed: an interviewer asks how fast the cost section needs to be ready before a board vote on next year's budget. Same equation, solved earlier with wider ranges instead of real logs.
Cost: finance caps the AI line item at two hundred dollars a month across every firm. Same equation, run backwards, to find how many reruns the budget can actually absorb.
The model got better: a newer model drops the price per token by half. Same equation, same ranges on tokens and calls, only the price term moves, and the guessed term is still the one worth rechecking.

Where people run it wrong.
They source the model-cost terms carefully and leave the usage term as a bare guess, because it doesn't feel like it belongs to the same math.
They quote finance a single number instead of a range, so the first real invoice reads as a miss even when it's still cheap.
They never revisit the usage assumption once real logs exist, so a guess from launch week quietly outlives the data that could have replaced it.

How to use it live. Say the equation before touching a single number: "tokens times price, times calls per interaction." That buys you a few seconds to recall which term you actually have a source for, and it tells the interviewer up front that the guess is going to get flagged, not hidden.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0