The week before building is worth more than the month of building

Someone billed $8K for an automation project and mentioned almost as an aside that he spent a full week before writing a single line — just talking to the client. Where things broke down. What they’d already tried. Why the previous attempt failed.

That week, he said, matters more than people think.

I’ve come to the same conclusion.

The projects that go cleanly are the ones where I understand the process before touching the tools. Not the ideal version of the process — the real one. The one with the exception nobody documented, the step that only works because one person does it a certain way, the workaround that became permanent three years ago and now everyone treats as normal.

The projects that get messy are the ones where I start building early. You make assumptions, the assumptions turn out to be wrong, and now you’re fixing things midway through instead of designing around them from the start.

I did a chargeback workflow for Mollie once where I processed the first case entirely by hand before writing anything. Fifteen minutes of manual work, every lookup, every decision point, every check I made along the way. Not because I had to — because I needed to know what the automation would actually need to do.

The automation that came out of that was cleaner and faster to build than anything I’d have designed from a description.

He also mentioned something else: the client was skeptical that automation could handle the complexity. Usage-based billing mixed with subscriptions, multiple vendor tiers, different pricing logic per customer. They’d assumed it was too messy.

That’s common. The mess is usually not a reason the system can’t be automated. It’s a reason the automation needs to be designed, not guessed.

Understand the mess first. Then build around it.