What Selling Software to Non-Technical Buyers Taught Me About Building It
Years on the vendor side taught me that a technically correct system nobody adopts isn't a partial success — it's a failed project wearing a passing grade.
For several years I sat on the vendor side of software adoption, first taking support calls, then managing the rollout logistics, then optimizing the systems those tools ran on. I wasn't the client. I was the person on the other end of the phone when a client's system didn't do what they expected, and the person who had to figure out whether that was a bug, a training gap, or a mismatch between what was sold and what the team on the ground actually needed.
That seat teaches you things that building software in isolation doesn't. You learn that a feature can be objectively good and still get zero adoption if it was introduced at the wrong moment, or introduced without anyone explaining why it mattered to the specific person using it. You learn that the support ticket volume in the first two weeks after a rollout tells you more about the design than the sales deck ever did. You learn to distinguish "this is broken" from "this doesn't match how we actually work," which sound identical over the phone and require completely different fixes.
It also teaches you to take the adoption question seriously before the build starts, not after. When you've spent years fielding the calls that come in after a launch goes sideways, you stop treating "will people actually use this" as a soft, secondary concern. It becomes a hard requirement, the same as uptime or data integrity, because from where I sat, a technically correct system that nobody adopted wasn't a partial success. It was a failed project wearing a passing grade.
I carried that into how I build now. Not as a slogan, but as a working assumption: the build isn't done when it passes tests. It's done when the person using it trusts it enough to stop keeping the spreadsheet as a backup.