Watch the Process Before You Build the Tool

Watch the Process Before You Build the Tool

When a small operation asks me for a system, I don't start with a proposal or a stack. I start by asking how the work already happens, because building the request as written can create a tool the crew walks around.

The request describes a system, not always the problem

A request often arrives as “we need a system.” That describes a solution before it explains the work.

Before I discuss software, I ask who owns each step, what gets written down, where the work breaks, and what has already been tried. I want to understand the process as it runs today, including the parts that look too ordinary to mention.

That matters because the requested system can contain a step nobody owns. It can include a spreadsheet that’s already doing fine. It can also assume a problem exists because the process feels untidy, even though the work is still getting done.

If I build the request without checking those things, I may deliver something that looks complete while making the job harder. The expensive mistake isn’t always a failed build. Sometimes it’s a working tool that adds another place to enter the same information.

I contract independently, so I have to make that decision early. I’ll turn down work if the request would mean building the wrong thing. Saying no before the build is cheaper than shipping a tool the crew will walk around.

One real run shows which step actually hurts

I want to watch one real run of the work before I decide what needs to change. I’m looking for the point where the process actually slows down, gets repeated, or depends on someone remembering what happens next.

That run can separate a genuine workflow problem from a request based on assumptions. It can show that a step is unowned rather than unsupported. It can show that the issue sits outside the proposed system altogether.

This is also where the gap between a specification and the work becomes visible. I’ve sat between warehouse staff and developers during software rollouts across operational regions. The screen had to match how the work was actually done, not how the spec described it.

If the floor process and the screen disagree, the floor wins until somebody changes one of them on purpose. A specification can say that a task belongs in a certain place. The person doing the task may already have a different sequence that keeps the work moving.

Watching the process gives me something more useful than a longer requirements document. It gives me the step that deserves attention and the steps that should be left alone.

Sometimes the right decision is to build nothing

A spreadsheet may be doing fine. A phone call may still be part of the process. I’ve worked around payments, export administration, and shipment workflows that relied mostly on phone calls and spreadsheets rather than software.

That experience changed how I approach a replacement request. I don’t start by replacing the spreadsheet because it looks old or because a new system would appear more complete. I check what job the spreadsheet is doing and whether the proposed tool would improve that job.

The same applies to a phone call. A phone call may carry information that the process needs, or it may be the way a person confirms something that software can’t settle by itself. Removing it because it isn’t a screen can add more work rather than less.

A tool should earn its place in the process. If it only adds clicking, creates another handoff, or makes the crew record the same detail twice, I don’t think it’s a useful build. Sometimes the right decision is to leave the step alone.

That decision can feel less satisfying than delivering a system. It’s still part of the job. Productivity for a small operation doesn’t come from having more software. It comes from seeing the process clearly and changing the part that keeps causing trouble.

The tool has to match the step people already use

When a build is justified, I keep the first version close to the process I’ve seen. The first version is often there to learn the process. The rebuild is for the part that kept breaking.

I’ve built business apps on a low-code platform and rebuilt the same kinds of systems in Python. The limits and debugging experience were different, but the lesson wasn’t that one form of code is automatically better. Code doesn’t answer the process question by itself.

The useful question is narrower. Which step keeps failing, and what can a tool do without forcing the crew to invent a new way of working?

That question sets a build limit. I don’t need to redesign every step because one step is difficult. I don’t need to turn a phone call into a screen because a screen exists. I need to fix the part that keeps breaking, then check whether the change fits the work around it.

This keeps the tool connected to the job rather than to the original request. It also gives the first version a purpose beyond appearing finished. It helps me learn enough about the process to decide what deserves a rebuild.

Testing follows the real sequence, not the demo

Testing has to follow the same sequence as the work. A screen can behave correctly in a demo and still fail when the next step depends on something the demo left out.

When I build and test a tool for a business, I check whether the work can move through it in its actual order. I’m checking what gets entered, what happens next, and whether the person doing the work can complete the step without leaving the screen to recover the process elsewhere.

That check matters because people will protect the process that gets the job done. If the tool doesn’t match the work, the crew will use the spreadsheet, make the phone call, or keep a separate workaround. The software may technically function, but it won’t be doing the job it was built for.

I’d rather cut a request down before building than ask people to work around a finished tool. The practical test is simple. Follow the work through its actual sequence and see whether the crew can complete the step without walking around the screen.