Every discovery call we take starts the same way, and it disappoints people.
They come in ready. They've read about agents. They've watched a demo where a chatbot answered a customer question in a friendly voice, and they've got a list — three, four, sometimes eleven things they want built. They want to talk about the build. And the first thing out of our mouths is not "great, let's scope it."
It's: what is this costing you right now, in dollars, per year?
Most of the time, the answer is a pause.
That pause is the whole business. It's not a gotcha, and it isn't a test. It's the discovery that no one else is doing, because everyone else in this market gets paid to build, which means everyone else in this market is structurally incentivized to skip straight to the fun part.
The problem with starting at the solution
Say a title agency comes to us wanting to automate its post-closing package assembly. Reasonable ask. The closer finishes a file, and then somebody has to gather the recorded deed, the final settlement statement, the policy, the payoff letters, assemble them in the right order, name them correctly, and get them out to the lender and the buyer within the window.
If we start at the solution, we spend the call talking about document parsing and naming conventions and which portal to push to. Fun conversation. Everyone leaves excited.
If we start at the cost, we spend the call finding out that the post-closing coordinator spends about ninety minutes per file on assembly, that they close roughly forty files a month, that her loaded rate is $38 an hour, and that the agency is therefore spending somewhere around $28,000 a year on the act of putting PDFs in order — plus whatever it costs them the four times last year a package went out late and the lender got loud about it.
Twenty-eight thousand dollars. Now we know something. Now we can have an adult conversation about what it's worth to fix.
Notice that we didn't learn anything about AI in that exercise. We learned something about the business. That's the point.
Pricing the problem before you price the solution
There is a discipline to this, and it's not complicated. You need four things:
The frequency — how often does this happen? Not how often does it feel like it happens; go count. The duration — how long does it actually take the person doing it, which is usually longer than management thinks and shorter than the person doing it will admit on the first ask. The loaded rate of whoever is doing it, which is their fully burdened annual cost divided by their working hours, not their salary divided by 2,080. And the consequence cost — what happens when it goes wrong, how often does it go wrong, and what did the last three failures cost you in refunds, rework, or a relationship.
Multiply the first three, add the fourth. That's the annual value of the problem.
Everything downstream is arithmetic. If the problem is worth $28,000 a year and the build is $22,000 with $200 a month to run, you're looking at a first-year return around 1.1x and a strong second year. If the problem is worth $9,000 a year and the build is $22,000, you have your answer, and it isn't the answer either of us wanted.
Why we won't build without the number
Because a project without a number is a project that can never be judged.
This is the quiet reason so many AI initiatives at small companies end in a shrug. Not because the technology failed — the technology mostly works now, and works well. They end in a shrug because nobody ever agreed on what winning looked like. Six months later, the owner is asked whether it was worth it, and he genuinely does not know. He can't tell you if the thing saved money. He can only tell you that people use it, sometimes, and that it was expensive.
That's not a technology failure. That's a diligence failure. And it's ours to prevent, not yours.
So we make it a rule. We quantify the problem first, we agree on the number together, and we only build when the numbers guarantee a strong return — we commit to a minimum 2x annual return on what you spend, and if the math doesn't clear, we tell you not to build it. That happens more than you'd expect. It happened twice last quarter.
Telling a prospect not to buy is a strange way to run a sales process. It's also the only thing that makes the rest of what we say worth anything. If we'll say "don't build this" when the numbers are bad, then when we say "build this," you can believe us.
The reader's version of this
You don't need us to run this play. You need a legal pad.
Take the thing that annoys you most about how work gets done in your company. Price it — frequency, duration, loaded rate, consequence. Give it an honest annual number. Then ask what you'd pay to make it stop.
Sometimes the answer is "a lot, immediately." Sometimes the answer is "actually, that's a $4,000 problem and I've been treating it like a $40,000 one, and I should just live with it." Both outcomes are wins. Both make you a sharper operator than you were an hour ago.
The value of the question isn't that it leads to a project. It's that it tells you the truth about your own business — which workflows are quietly eating you alive, and which ones you've simply been in the habit of resenting.
Start there. The build, if there is one, will take care of itself.