Here's how most quotes actually get built. Someone eyeballs the work, arrives at a number of hours that feels roughly right, and that number does two jobs at once: multiplied by a rate, it becomes the price; divided by the team's assumed capacity, it becomes the date. One estimate, two promises, both made in the same five minutes, both resting on the same guess.
That's not two risks. It's the same risk, counted twice, and dressed up to look like two separate, considered decisions.
Why this is worse than it looks
If the original estimate is wrong — and a single-point estimate for a piece of creative or technical work is wrong far more often than anyone likes to admit — the price and the date don't fail independently. They fail together, in the same direction, for the same reason. Underestimate the work, and the engagement is simultaneously underpriced and overdue. There's no scenario where the estimate being off only costs you one of the two promises. It costs you both, at the same time, and now the conversation with the client is about a blown budget and a blown deadline in the same breath.
Compare that to what happens when price and date come from genuinely separate processes. If one estimate is off, only one promise is at risk. The two failures aren't correlated anymore, because they were never the same number wearing two hats to begin with.
Price and date aren't actually the same question
It's easy to default to one shared estimate because on the surface, cost and schedule both seem to reduce to "how much work is this." They don't, not really. Cost is mostly a function of total effort — hours, regardless of when they happen. A calendar date is a function of effort and how that effort actually flows through a team with real constraints: how much can run in parallel, how much is blocked on review, how many other engagements are competing for the same people's attention this month. Two engagements that would cost the same amount can land on wildly different dates depending on team capacity and what else is on the board — and a single point estimate has no way to represent that, because it was never built to.
Collapsing both questions into one number doesn't simplify the problem. It just hides the fact that one of the two questions was never actually answered.
A better way: decouple them
The fix isn't a better estimate. It's two separate processes, each answering the question it's actually suited for.
Price still comes from a cost estimate — that part doesn't change. What changes is that it stops being asked to do double duty as a scheduling model. Whatever process an agency already uses to size and price work — historical comparables, a rough hours estimate, whatever it is — keeps doing that job, and only that job.
The date comes from somewhere else entirely: real throughput data, run through a Monte Carlo forecast. Once there's a board with tickets on it, the delivery date should be a function of how fast this team has actually been finishing similar work — not an artifact of the number that was used to write the quote three weeks before anyone started. Early on, before real history exists, that means an honestly-labeled synthetic estimate (see the cold-start post on how that works) — still separate from the pricing number, and still getting more accurate as real data replaces the placeholder, rather than staying anchored to a guess made before the work began.
That "once there's a board with tickets on it" is doing real work in the sentence above, and it's worth being explicit about: a Monte Carlo forecast can't run against a paragraph of scope in an SOW. It resamples from a count of remaining tickets and how fast tickets like them have historically moved — it needs the work already broken into discrete, countable pieces before it has anything to sample from. Decomposing scope into a backlog isn't optional groundwork on the way to a real forecast; it's the step that has to happen before a genuine date exists at all, forecast or otherwise. The difference this post is arguing for was never about skipping that decomposition. It's about what the date is built from once that backlog exists — resampled ticket-level history, or the same single number that already set the price.
Follow that logic one step further back and it lands somewhere worth stating directly: the same decomposition needs to happen before the cost estimate too, not just before the forecast. A price built by eyeballing a paragraph of scope and guessing at a number of hours is exactly the "sloppy estimate" this post opened with — it's not a cost estimate so much as a placeholder wearing one's clothes. A price built from an itemized backlog, sized ticket by ticket, is a genuinely different exercise, and a more defensible one. The decomposition work isn't something forecasting needs and pricing can skip. It's a single prerequisite that both processes depend on — do it once, up front, and it makes the cost estimate more honest and hands the forecast something real to sample from the moment work starts.
What this actually buys you
Not a lower price, and not a longer timeline by default — just two numbers that can be wrong independently instead of one number that's wrong twice. When the date needs to move, it's a schedule conversation, not automatically a budget renegotiation too. When the scope needs to change, it's a pricing conversation that doesn't require redoing a forecast that was actually built on evidence in the first place. Decoupling the two doesn't make either estimate perfect. It just stops one bad guess from being able to break both promises on its own.