u/Lorddwill

Automation is completely useless if you automate the wrong process.

Most teams don’t actually suffer from a lack of tools or software they suffer from automating messy, broken workarounds. When you build automation on top of a bad workflow without fixing it first, all you get is the exact same confusion, just delivered at 10x speed.

A lot of steps in daily operations survive purely because "that's how we've always done it". Writing code around those steps just locks those inefficiencies in place forever.

Before writing a single line of code or setting up a tool, here's the approach I try to take:

1. Map the exact process first – Lay out every single manual step currently being taken.
2. Eliminate legacy steps – Ask why each step exists and cut out the fluff before touching code.
3. Isolate candidates – Look for tasks that are high-volume, highly repetitive, and strictly rule-based.
4. Build & measure – Build specifically for that high-impact step and track the actual time/cost saved.

I'm curious to hear from other dev/ops folks here:

What is the absolute worst or most absurd "manual workaround" process you’ve ever seen, someone try to automate instead of fixing?

A few months ago, a client came to me with absolute certainty: "Edward, I need an app." No background context, no workflow breakdown, just a feature request presented as a non-negotiable requirement.

As developers, our knee-jerk reaction is often to open VS Code, spin up a stack, and start coding. We love solving technical problems, so we jump straight to the implementation.

Instead, I paused and asked: "What exact problem are we trying to solve?"

After digging into his daily business operations, we realized he didn't need a mobile app at all. He needed a clean internal dashboard and a simple automated workflow to replace a manual process wasting hours of his team's week.

If I had just taken the order and started coding on day one, we would have burned weeks of development time and thousands of dollars building a product that didn't actually fix his underlying operational bottleneck.

Now, before writing a single line of code or picking a stack, I run every request through four baseline questions:

1. What exact problem are we solving? (Not what tool do you want, but what is currently broken?)
2. Who uses this system daily? (End-user reality vs. manager expectations)
3. What happens right now without this tool? (Uncovering the existing manual workaround)
4. How do we measure success after launch? (Metrics, time saved, or revenue gained)

Coding only starts at step four. Requirement scoping and problem definition have to come first.

Curious how you all handle this in your own work when a client, founder, or product manager comes to you asking for a specific complex feature or stack before they've even defined the business problem, how do you steer the conversation back to discovery without sounding dismissive?