HEINOUX Journal Portfolio

Journal

Automation has a dependency order and almost nobody sells it that way

I put twenty-two of my own automation guides into a single order this morning and they did not sort by value, they sorted by dependency. Then I checked what the platforms actually charge for and found the same sequence arriving from the opposite direction.

By · · 5 min read

Automation has a dependency order and almost nobody sells it that way

I spent this morning putting twenty-two things I have written about automation into a single order.

Not ranking them. Ordering them. The difference turned out to be the whole exercise.

Ranking and ordering are not the same job

Every piece of advice about what to automate first is a ranking. Score your processes by how often they run and how expensive it is when they go wrong, take the top one, start there. I have written that advice myself and I still think it is correct.

It answers which process is worth the most to fix. It does not answer which process can be fixed yet. And when I laid twenty-two guides out on a table this morning, they did not sort by value at all. They sorted by dependency.

Capture, then reuse, then route, then remind, then report. Each one needs the one before it to be true, or it produces confident output from a bad input.

Reporting is the clearest case. A dashboard is the thing everybody wants and it is last in the chain, because a report is only as good as the record it reads, and the record is only as good as the place the fact was first typed. Automate the report over a spreadsheet that three people type into separately and you have built a fast way to be wrong every month.

The part I did not expect

I went to check what the automation platforms actually charge for, because I wanted the ordering argument to rest on something other than my opinion of it.

Zapier does not bill for deciding. Triggers are free, filters are free, paths are free, formatting and delays are free. What it bills for is a successful action: the moment something gets written somewhere. Its own documentation points out that a workflow polling an app every two minutes runs more than twenty thousand checks a month at no cost at all.

Make bills more strictly, one operation per module run per record, but the shape of the incentive is identical. Watching and deciding are cheap. Writing is what costs.

That is the dependency order arriving from a completely different direction. I got to it by thinking about what breaks. The pricing pages got to it by metering what is expensive to run. Two unrelated routes to the same sequence is a better argument than either one alone.

The number that stopped me

Make documents a worked example on its own operations page. A workflow watches a spreadsheet for new contacts and emails the sales manager about each one. Ten contacts arrive. One operation for the trigger, ten for the emails, eleven in total.

Then the same page restructures it. Add an aggregator so the ten contacts go out as one email instead of ten. Same ten contacts. Same manager. Same information.

Three operations.

Nothing was removed. No feature was dropped, nobody was told to do less work. The shape changed and the cost fell by about seventy-three percent.

I have been describing sequencing as a way to avoid rework. It is also, on the vendor's own published numbers, a way to pay a fraction of the running cost for the identical outcome. That is a much stronger claim than the one I was making, and it is not mine, it is sitting in their documentation.

What I had actually been doing

Twenty-two guides, each one correct on its own subject, and not one of them says where it sits relative to the others. Every one of them assumes the reader already knows which layer they are standing in.

That is a reasonable assumption for someone who reads all twenty-two. Nobody reads all twenty-two. They land on the one that matches the thing annoying them this week, which is almost always a symptom of a layer higher up, and the piece they landed on cheerfully helps them automate the symptom.

The fix is one page rather than twenty-three, which is the part I like about it. The work was already done. What was missing was the order.

The test, if you want one

Pick a customer. Count the separate places somebody typed their details.

If the answer is one, your capture layer is done and you can go looking for the next thing. If the answer is three, then whatever you were planning to automate this month is not your first project, and building it will cost you at every write step, on every duplicate, for as long as it runs.

It takes about four minutes and it has told me more about a business than the first half of most first meetings.

Frequently asked questions

Is dependency order not just common sense? It is, right up until you are the one choosing. Every incentive points at the visible end of the chain, because reporting and reminders are what people notice and capture is invisible when it works. I wrote twenty-two guides before writing the order down.

Does this mean I should not automate anything until my data is perfect? No, and that would be a good way to never start. It means finding out which layer is broken highest up and fixing that one first. Usually it is small, and usually it is not the thing that was annoying you.

Where did the eleven-to-three number come from? Make's own operations documentation, read on 1 September 2026. It is their worked example, not mine, and it compares the same ten records through two different workflow shapes.

Are you saying Zapier is cheaper than Make? No. They meter different things and the right one depends on what you are building. The point is that both of them charge for writing and neither charges much for deciding, which is a useful thing to know before you design anything on either.

Want this kind of build for your business?

I build AI systems, custom company dashboards and automation for growing businesses.

Get your autopsy Email me