I built a client a working piece of software. Tested. Notarized. Signed off by Apple. He stopped using it inside of a month.

That bothered me for weeks, so let me walk through what actually happened, because the lesson isn't the one I expected going in.

This client's business runs on relationships: enterprise accounts, individual collectors, a small stable of makers whose work he represents. He'd been tracking all of it in a spreadsheet, the kind that grows sheets the way a garden grows weeds. I offered to build him something better: a real desktop app, tabs matching his existing workflow exactly, local data, change logging, CSV import and export so nothing he already had got orphaned.

I built it. A proper data layer, automated tests, the whole thing. Shipped a signed, notarized Mac installer.

Then I watched him go back to the spreadsheet.

Not because the app was broken. Because it "didn't update reliably" and was "harder to use" than what he already had. Two sentences that took me a while to actually sit with, because my first instinct was to defend the build. It worked. I tested it. That instinct is exactly the problem.

Here's what actually happened: I skipped a step. I got excited about building the right tool instead of first asking whether a tool that already exists would solve this faster, cheaper, and with less risk of exactly what happened, an owner reverting to the thing he already knew under deadline pressure. Researchers put a number on this pattern this year: an estimated 95% of enterprise generative AI pilots show no measurable return. Not because the AI doesn't work. Because "it works" and "it gets adopted" are different questions, and most teams, including me on this one, only answer the first.

So now I'm recommending he trial an AI-native CRM built for exactly this kind of relationship tracking, rather than another custom build from me. That's an uncomfortable sentence for a consultant to write. It's also the honest one.

The lesson isn't "don't build custom software." It's that adoption risk is real risk, and it doesn't show up in a test suite. Before I build anything for a client again, the first question isn't "can I build this," it's "what already exists that does this, and why isn't that the answer." If I can't beat that bar clearly, I don't get to skip it just because building is the fun part.