"You know, that could be an app" is only step zero. Step two of the playbook - quantifying the cost of the pain point - is where a good idea either earns a real business case or quietly falls apart. Skip it, and you're building on a hunch. Run it honestly, and you know before you spend a dollar whether anyone will actually pay for the fix.
Why a Pain Point Needs a Number
"This is annoying" doesn't get budget approved. "This costs my team six hours a week and roughly $4,000 a month in rework" does - because a number can be compared directly against the price of the thing that fixes it. Buyers don't evaluate solutions in the abstract; they evaluate them against what the problem is already costing them, whether or not anyone has ever written that cost down.
This is also the difference between a pitch that sounds like intuition and one that sounds like math. A founder who says "clients keep telling me this is a problem" is describing a feeling. A founder who says "this problem costs the average client eighty hours a year, which is roughly $28,000 at their own team's rate" is describing a business case.
The Formula
Keep it simple: frequency times cost per occurrence.
Frequency is how often the problem happens - daily, weekly, per project, per client. Cost per occurrence is what it costs in time, money, or risk each time it does. Multiply the two and you have an annualized cost you can hold up next to whatever your app would charge.
The formula works whether the cost shows up as lost time, direct spend, or risk exposure. A compliance gap that creates a 2% chance of a $500,000 penalty each year has an expected annual cost of $10,000 - a number just as real, and just as usable in a business case, as a time-based one.
The Mistake Almost Everyone Makes First
The most common error is quantifying the cost to yourself instead of the cost to the buyer. It's tempting to calculate how much time you'd save by building the tool, or how much easier your delivery process would become. None of that matters to the person deciding whether to pay for it. The number that closes deals is what the problem is costing them - their time, their team's rate, their risk exposure - not what it would save you on your end.
This distinction matters more once you start pricing the eventual app. A tool priced against your own delivery savings tends to be underpriced relative to what it's actually worth to the buyer, because your cost structure and the buyer's cost of the problem are two entirely different numbers.
Turning the Number Into a Conversation
A quantified estimate isn't meant to be the final word - it's meant to walk into a validation conversation with something concrete. Instead of asking a prospect to invent the size of their own problem on the spot, you give them a number to react to: "we estimated this costs a team like yours somewhere around $12,000 a year - does that feel low, high, or about right?"
That single question does more work than an open-ended "what's your biggest challenge with this." It respects that the prospect may not have a precise number either, while still getting you a directionally honest read - and it often surfaces a more accurate figure than either of you started with, because the prospect will correct you toward reality.
How Precise Does This Need to Be?
Precise enough to clear the bar of "this is worth solving," not precise enough to survive an audit. A range - "somewhere between $8,000 and $15,000 a year" - is honest about the uncertainty and still specific enough to be useful. What matters is that the range is grounded in a real formula and validated against at least a few real prospects, not pulled out of thin air to make the business case look better than it is.
A Worked Example
Take the pipeline audit tool from the opening story of "You Know That Could Be An App". The pain point: B2B marketing teams manually reviewing sales pipeline data to figure out which deals are actually likely to close, usually in a spreadsheet, usually once a week, usually by someone senior enough that their time isn't cheap.
Frequency: once a week, 50 weeks a year - 50 occurrences annually. Cost per occurrence: roughly 3 hours of a marketing ops lead's time, valued at $60 an hour internally, plus the harder-to-quantify cost of decisions made on stale or incomplete data in between reviews. The time cost alone: 3 hours x 50 weeks x $60/hour = $9,000 a year, before factoring in the cost of misallocated ad spend chasing deals that were never going to close.
That $9,000 is a real, defensible number - not because it's perfectly precise, but because it's built from a formula a prospect can check against their own reality in under a minute. Priced against that number, a $99-a-month tool that automates the audit isn't a hard sell; it's a number that already makes sense before the first demo starts. That's the entire point of doing this math before you build anything: the business case exists before the product does.
Frequently Asked Questions
What if I can't get exact numbers from a prospect?
Use a reasonable range instead of a false-precision single number, and validate it directly by asking the prospect if the range feels low, high, or about right.
Should I quantify the cost in time, money, or both?
Both, if you can. Time converts to money at the buyer's own hourly or team cost, and having both numbers lets you speak to different stakeholders.
How precise does this number need to be before I move forward?
Precise enough to clear the "is this worth solving" bar, not precise enough to survive an audit. A validated, directionally right range is enough to justify building an MVP.
Does this replace talking to real customers?
No - it's what makes those conversations sharper, giving the prospect something concrete to react to instead of asking them to invent the size of their own problem on the spot.
Once you can put a real number on the pain point, everything downstream gets easier - the pitch, the pricing, and the decision about whether this idea is actually worth the next thirteen days. It also becomes the first line of the business case you'll eventually put in front of founding members, investors, or your own leadership team - the same number, reused everywhere it needs to do work.