Harsh Makadia

a business paid an "AI automation guy" $5,000

then they called me to fix it.

their customers had stopped getting pickup emails.

nothing crashed. no errors.

someone had renamed one word in a dropdown.

here's what happened:

the automation sent a pickup email whenever an order's status said "ready."
one day, someone on the team renamed "ready" to "packed."

made sense.

that's what the team actually called it.

but the automation was checking for the word "ready."

no "ready," no email.

$5,000 broken by a dropdown edit.

the fix wasn't more code.

it was separating 3 things that should never have been one:

1. the internal state: ready_for_pickup

2. the visible label: "packed"

3. tags: "priority", "fragile"

the automation listens for the state.

the team can rename the label whenever they want.

tags add context without touching either.

before you make any dropdown editable, ask one question:

is this just a label, or does it decide what happens next?

4 builds i turn down now:

1. "automate everything"

nobody knows what everything means. it ends with a 40 page scope and nobody happy.

2. processes that change every week
you're not automating a process, you're chasing one.

3. "make it work like big billion company system"

they had 50 engineers and 3 years. you have a budget and a deadline.

4. anything nobody owns after launch
if no one checks it, it breaks quietly and i get the blame.

saying no to these made the yes projects better.

less rework, faster launches, happier clients.

10 coding agents don’t give you 10 developers if you can only review one change at a time.

before adding more agents, split the work into:

INDEPENDENT
can ship without another task finishing.

DEPENDENT
needs a decision or change from somewhere else.

SHARED
touches the same files, schema or public interface.

parallelize the first group.
sequence the second.
assign one owner to the third.

then limit work in progress to what you can actually review.

measure merged, tested changes.

not how many agents are running.

a useful structure for a 90-second automation demo:

0–15 seconds: show the messy input.

15–30 seconds: show what someone currently has to do with it.

30–60 seconds: run one example through the workflow.

60–75 seconds: show the finished output and where the team receives it.

75–90 seconds: show one limitation and what happens when it occurs.

example:

an emailed supplier price sheet goes in.

changed prices come out, with the previous price, new price and affected products side by side.

the buyer reviews the changes before anything is published.

keep the tool diagram for questions.

the buyer should understand the job you’re taking off their plate before they learn which tools you used.

a simple way to decide what to automate first:

score each task from 1–5 on:

1. frequency: how often does it happen?

2. friction: how much time does it take?

3. rework: how often do errors send it back?

4. clarity: can someone explain the rules?

multiply frequency × friction.

use rework to break ties.

then check clarity before you build.

if nobody agrees on the rules, document the process first.

example: a 5-minute task done 100 times a week costs over 8 hours.

a 2-hour task done once a month may feel painful, but it’s rarely the best first target.