What business experience taught me about software
Years of selling and supporting software changed how I build it. On workflows, trust, and why the customer's day-to-day should shape the architecture.
Before I wrote production code, I spent years on the other side of software, selling it, supporting it, and sitting across from the people who had to live with it every day. Most engineers meet the customer last. I met them first, and it changed what I think good software means.
Software is adopted, not delivered
Shipping a feature and having it used are two different events, often months apart, sometimes never connected at all. I watched capable products get abandoned because they did not fit how the work already happened, and unremarkable ones get loved because they removed one specific daily friction. That gap between delivered and adopted is where most of the value is won or lost, and it is nearly invisible from inside the codebase.
The workflow is the spec
Businesses do not run on features. They run on repeated workflows, the same handful of motions over and over, done by people who are busy. When I design something now, I start from those motions instead of a feature list. Agentic CRM exists because I watched one workflow break constantly. An email arrives, context scatters across threads, the follow-up slips, and the CRM goes stale because keeping it current is a chore. The product is a direct answer to something I saw fail a hundred times.
Trust has a budget
Selling software taught me that trust is earned slowly and spent fast. One confidently wrong number, one silent change nobody asked for, and the whole tool is suspect. That instinct is why the AI in my CRM proposes instead of acts. I am not guarding against a hypothetical. I watched real people stop trusting a system the first time it did something they had not authorized.
Where the bottlenecks actually are
- The slow step is rarely the one engineers assume. Usually it is a manual handoff, a piece of context stuck in one person's head, or a process nobody owns.
- Customers describe symptoms, not causes. The real requirement is often one question deeper than the one they asked.
- Operational reality beats elegant design. A system has to survive how the work actually happens, not how a diagram says it should.
The convergence
I don't think of the business side of my work as a previous life I'm leaving behind. It's the part that tells me what to build and why it matters, and the engineering is how I build it. Caring about workflows, trust, and friction is not separate from being a good engineer. For the software I want to build, it is the foundation.