What Happens Before Writing Code for a Client

When I first sat with the client, I did not show them anything. I asked them to walk me through a normal day. Not the ideal version of how operations were supposed to work. The actual version, with the workarounds and the manual checks and the tasks that depended on one specific person being available.

That conversation told me more than any requirements document would have. Where the real bottlenecks were. Which parts of the process were held together by habit rather than any designed logic. What would break first if the team grew by twenty percent.

I went home and built a rough version of what their process could look like as a system. That approach is detailed in Why Prototypes Close Deals Better Than Pitches. Brought it back. Showed it to them. The question stopped being whether they needed anything at all and became how soon it could be ready.

That shift does not happen because of technical skill. It happens because the thing they are looking at reflects how their operation actually runs, not a generic version of a business that vaguely resembles theirs.

Software that does not fit the actual process gets worked around. People find ways to do it the old way alongside the new system, and within a few months the system handles the easy parts while the hard parts still happen in WhatsApp. This is the pattern described in When WhatsApp and Excel Stop Being Enough.

The listening phase is where software either earns its place in a business or doesn't. It is also the part most vendors skip because it is slow and does not look like progress from the outside.

Most of what I do on any project has nothing to do with code. It is understanding what a business actually needs clearly enough that what gets built matches that, not just approximately, but exactly. That's why the process foundation matters more than the technology stack—a lesson reinforced in Why Businesses Need Process Before AI.