Opus Magnum's Three Scores Are a Good Way to Judge a Zap

A friend who runs a two person bookkeeping office asked me to look at her automations last spring. She had built eleven of them over a year, mostly by following tutorials, and she was proud of them. She was also paying for a higher plan than she needed, two of the automations broke every few weeks, and nobody could remember what three of them did. When I asked which ones were "good," she said they all worked. That was true, and it was not the right question.

The way I ended up explaining it to her came from a puzzle game I had been playing in the evenings, Opus Magnum. It does not tell you whether your solution is good. It tells you how it compares on three separate scores, and it shows you that no solution wins on all three. That turned out to be a very practical way to judge a Zap, a Make scenario or any other small automation.

How Opus Magnum scores a solution

Opus Magnum came out in 2017 from Zachtronics, a studio known for puzzle games that feel a lot like programming. You build little alchemy machines from mechanical arms that grab, rotate and combine atoms into molecules. Each puzzle has many valid answers. Once you solve one, the game shows you three numbers and three histograms comparing your result with everyone else who played it.

• Cost is how much gold your parts cost. Fewer arms and simpler pieces mean a lower cost.
• Cycles is how many steps the machine needs to produce the required output. Fewer cycles means a faster machine.
• Area is how many hexagons of the board your machine occupies. A compact machine scores better.

The lesson hits after a few puzzles: optimising one score usually hurts another. The fastest machines are big and expensive, with arms working in parallel. The cheapest machines are slow, because one arm does everything. The most compact ones are often fiddly and slow too. Players compete on each score separately, and a solution that is middling on all three is perfectly respectable.

The same three scores for an automation

Small business automations have almost the same trade offs, just with different names. Here is how I map them.

Cost: money and setup time

The obvious part is subscription price. Most automation platforms charge by usage. Zapier counts "tasks," roughly one for each action step that runs. Make counts "operations." So a Zap with three action steps that runs 60 times a month uses about 180 tasks. Add one "nice to have" step, like posting a message in a chat channel, and the same Zap now uses 240. On a small plan, that is the difference between staying inside your limit and paying for the next tier.

The hidden cost is setup time. My friend's most complex Zap took her about four hours to build. It saved her perhaps fifteen minutes a week. That pays back after about four months, which is fine, but she had assumed it paid back immediately.

Cycles: how long and how often

For automations, cycles is speed and frequency together. How long between the trigger and the result? How often does it check for new data? Some platforms poll every 15 minutes on cheaper plans and every 1 or 2 minutes on more expensive ones. For a weekly report, 15 minutes is irrelevant. For a booking confirmation, it might matter a lot. Paying for speed you do not need is a common way to overspend.

Area: how many things can break

This is the score people never think about, and it is the one that caused her broken automations. In Opus Magnum, area is board space. In an automation, I treat it as the number of separate apps, accounts and connections involved. Each one is a place where a password expires, an API changes or someone renames a spreadsheet column.

Her two unreliable Zaps each touched five different services. Every other automation she had touched two or three. That is not a coincidence. More area means more surface for something to go wrong, which echoes the point in the hidden cost of too many tools.

A working automation is like a solved puzzle. It counts, but it does not tell you whether it is any good.

Scoring her eleven automations

We went through each one with a simple sheet. For cost, monthly tasks used plus the rough hours spent building and fixing it. For cycles, how fast it actually needed to be against how fast it was set to run. For area, how many separate apps it touched. Then, for each, we asked which of the three scores it should actually be optimised for.

The results were useful. Three automations were "high area" with five or more connected apps, and two of those were the ones that kept breaking. We rebuilt both to go through a single spreadsheet in the middle, which cut each to three apps and, at the time of writing, neither has broken in five months. Two automations were set to run every 2 minutes when daily would have been fine, which let her drop down a plan tier and save about $30 a month. And three did things nobody needed anymore. We switched them off.

Eleven became eight. Her monthly task count dropped by roughly 40 percent. Nothing that mattered got slower.

Where the game analogy stops

Opus Magnum is a closed world. Atoms never change shape halfway through a puzzle, and the rules are fixed. Real automations depend on other companies' software, which changes without asking you. A compact, cheap, fast automation can still break tomorrow because a form builder changed its export format. The three scores tell you about risk and expense. They do not guarantee reliability.

And there is a fourth score the game does not have: whether a human still needs to look at the result. For anything that sends money, emails customers or deletes records, I would keep a person checking the output, which is the point of keeping a human in the loop.

Score one automation this week

Pick the automation that annoys you most, or the one you understand least. Write down three numbers. Cost: tasks or operations it uses per month, from your platform's usage page. Cycles: how often it runs, and how often it actually needs to. Area: how many separate apps or accounts it touches. If area is above four, look for a way to route it through fewer services. If it runs more often than it needs to, slow it down. If you cannot explain what it does in one sentence, switch it off for a week and see who notices. For a broader way of thinking about which tools to keep, choosing automation tools without overcomplicating is a good companion read.