Why I stopped over-engineering my automations

For a long time my default move was to build the complete version. If a workflow had five edge cases, I'd handle all five before it ever ran once. It felt responsible. It was mostly a way of avoiding the part that actually matters: shipping something a real person uses.

The automations that have created the most value for the teams I work with were almost never the elegant ones. They were small, slightly embarrassing, and live.

The simplest version that ships

A Clay table with one enrichment step and a Claude prompt that writes three lines is not impressive. But if it saves a rep ten minutes a day and they actually open it, it beats the version with confidence scoring and fallbacks that's still sitting in draft.

Shipping a rough thing teaches you more in a week than planning the perfect thing teaches you in a month.

Once it's running, the real requirements show up on their own. Reps tell you where it's wrong. You learn which edge cases actually occur versus the ones you imagined. That feedback is worth more than any amount of upfront design.

What I do now

A loose rule of thumb before I build anything:

• Ship the version that handles the common case and nothing else.
• Put it in front of one real user the same week.
• Only add complexity that a real failure justifies.

It's less satisfying to build, and far more useful. The goal was never a clever system — it was a rep who gets their afternoon back.