Half the problems businesses bring me are not software problems. They're process problems. About 50% — I've been at this long enough to say it with confidence.
I've been building software for many years and spent around 15 years working in telecom. Both worlds reinforced the same conviction: a well-designed process feels like a well-lubricated engine humming along. You barely notice it's running. A broken one announces itself constantly — in delays, in workarounds, in that one person who "just knows how this part works" and can never take a vacation.
What I do before I write a single line of code
When I'm in early discussions with a potential client, the first thing I want to do — before any talk of software — is watch. Literally sit in the room and observe how work actually gets done. I have no problem spending hours on this. I bring a notebook and I'm looking for one thing: friction.
Friction is easy to spot once you know what you're looking for. A step that requires going back to verify something. A handoff where information gets lost or re-entered. A tool that doesn't quite fit what people need, so they compensate with a workaround that nobody wrote down. Each one is a clue.
A process is never broken all at once. It collects friction in small pieces, until one day the whole thing is slow and nobody can explain exactly why.
Some of these problems need software. Quite a few don't — they need someone to redesign the sequence of steps. Honestly, I enjoy that part just as much.
The owner drowning in Sundays
Recently I sat with a micro business owner who was frustrated. His weekly accounting and stock inventory update was taking him two full days — every single week. And because it was such a burden, it kept getting postponed. The backlog would grow. The numbers would fall weeks behind.
Here's the funny part: weeks earlier, I had already told him about several free tools that would fit his business perfectly. Manufacturing accounting, inventory tracking, everything he needed.
So instead of jumping straight into a custom build conversation, I told him: let me sit with you first and understand exactly how you're currently tracking things.
You can guess what I found. His business model is not unusual — not even slightly. The tools he needs exist, they're free, and they're built for exactly what he does. But his process was a tangle. Multiple Excel files with dozens of sheets. Separate notebooks patching the gaps. Steps that connected to each other through institutional memory rather than any logical sequence. He had been building on top of what once worked until the whole thing was held together by habit.
Fix the sequence, then pick the tool
We didn't build anything. We sat together and mapped out what actually needed to happen — in the order it logically needed to happen. Removed steps that existed out of habit. Consolidated the scattered records. Then took the free tool I had originally recommended, configured it for his business, and moved the cleaned-up process into it.
Two full days became a manageable daily habit.
The point isn't that free tools are always the answer. The point is that software dropped onto a broken process doesn't fix the process — it encodes it. You get a faster broken process. Sometimes an automated one, complete with dependencies and a support contract.
Fix the sequence first. Then choose the tool that fits it.
