The email had a budget number in the subject line. That almost never happens.
The owner of a distribution company wanted a custom CRM to track his sales reps — where they went, who they visited, what they sold. He'd already gotten sign-off from his partners. He wanted to start within the week. Most of my calls start with someone trying to figure out what they can afford. This one started with someone telling me what he'd already approved.
I turned it down.
The pitch that almost wrote itself
On paper, this was the easiest yes of the year. Clear budget, clear urgency, a client who'd clearly thought about it before calling. I could have scoped a CRM in a week and had a contract signed the week after. Reps get an app, checks in with GPS, logs visits, syncs to a dashboard the owner checks every evening. I've built this exact shape of system more than once. It works.
I asked him one question before I said any of that.
What he actually asked for
"Walk me through what happens right now when a rep visits a client."
He explained that reps were supposed to call in after each visit. Most didn't. Some called at the end of the day and reported five visits at once. A few, he suspected, reported visits that never happened. He wanted the app to fix this — force a check-in, timestamp it, attach a location, make it impossible to fake.
That's a real problem. It is not a software problem yet.
The question I asked instead
I asked him what would happen if a rep skipped a mandatory check-in on day one of the new app. He hadn't thought about it. Would they get a warning? A deduction? Would anyone actually look at the report daily, or would it join the pile of dashboards nobody opens after the first month?
He didn't have an answer, and to his credit, he didn't pretend to.
An app can make bad behavior visible. It can't make anyone act on what it shows them.
This is the part that gets skipped in most sales conversations, mine included when I let it. A client describes a symptom, a developer designs a cure, and nobody asks whether the underlying condition has anything to do with software at all. The CRM he was describing would have logged the same broken habits with more precision. It wouldn't have changed a single one of them.
Why I said no
I told him building the app now would cost him money twice. Once to build it, and again in six months when it sat half-used because nobody had defined what "using it correctly" meant, or who was responsible for enforcing it. I've watched that exact sequence happen to other clients — a good tool, no owner, no consequence for ignoring it, dead within a quarter.
What I recommended instead: spend two weeks defining what a completed visit actually looks like, who reviews the reports, and what happens when someone doesn't comply. Write it down. Run it manually, on paper or in a shared spreadsheet, for those two weeks. If the process holds up under real use, building the app to enforce it becomes straightforward — and worth doing properly.
If it doesn't hold up manually, no app was going to save it.
The money I didn't take
He wasn't thrilled. He'd budgeted for this, gotten approval, cleared his calendar for it. Telling a client to wait two weeks and solve half the problem without me is not a natural instinct in a business that gets paid to build things.
But I'd rather lose that project than deliver software that quietly fails and gets blamed on the developer. That failure doesn't stay contained to one client — it becomes the story he tells the next business owner who asks him about custom software. I've been doing this long enough to know which version of "no" costs less.
He called back three weeks later. The manual process had exposed two reps who were fabricating visits entirely — something the CRM, ironically, would have made harder to catch early, since a well-designed app tends to earn premature trust. We built the system after that, with a much clearer idea of what it needed to enforce and who was accountable for the numbers it produced.
Saying no to that project cost me three weeks of revenue on paper. It's the reason the project that eventually got built actually works.
