Start narrow, not small

The technology is rarely what fails in AI automation. Instead they are five decisions before the actual build.

🔮 This week’s signals

Your expensive model should be deciding, not typing.
OpenRouter’s new subagent tool lets a frontier model hand a self-contained subtask to a cheaper worker model mid-generation, billed separately at the worker’s rate. Their cookbook example cuts over 80% off generation-heavy subtasks. Most businesses staring at a large agent bill are paying frontier rates for formatting and extraction.

Substack put an AI detector in the reader’s hands
Readers can now scan any post, comment, or reply over 100 words published from 21 July and get an estimate of how much was written by AI. There is also a “How I made this” field for disclosing it yourself, which I did. I would rather state my position than have a detector state it for me. They’re not reliable anyway since you can cheat them easily with tools like Superhumanizer.

Pipedrive shuts off every V1 API endpoint on July 31.
Make.com and Zapier have both re-released their Pipedrive modules on V2, which returns fewer fields than V1 and wants OAuth instead of an API token. Reconnecting takes two minutes, and that is the trap. It hides the fields that quietly stopped arriving. Open the affected scenarios and read the actual output bundle before Friday.

Five mistakes, and none of them are technical

Last year I inherited 150 Make.com scenarios that nobody at the company could explain. No documentation. Half of them inactive or overlapping, a few duplicated across two accounts. The team had stopped trusting their own tools, because tasks kept coming back marked done when they were not.

We rebuilt it down to 18. An 88% reduction, documented, cheaper to run.

They were not careless, either. A niche leader running Make.com with Pipedrive and SmartSuite, two years into building. The real cost of a bad implementation is never the subscription or the build fee. It is the compounding tax on every future change, paid in engineering hours nobody budgeted for.

In over 2,500 automations I can count on one hand how many have been a failure of the tool itself rather than a failure that emerged from one of the five decisions made before anyone even opened a builder.

The usual advice is to start small. Pick one annoying task, automate it, prove the value, expand. It is good advice and it does get a first automation live. Where it breaks is the second one. And the ninth. And the fortieth. Automating task by task builds a system with no map, where every scenario is locally correct and globally unaccountable. That is how a company reaches 150 scenarios in two years without anyone making a bad decision.

Small was never the problem. Unmapped was.

Here is the list, in the order the mistakes actually happen:

1. Choosing a solution before defining its business value. The problem in one sentence, the baseline as a number, the threshold that counts as success. Thirty minutes. No baseline means you have a measurement problem, not an automation problem.

2. Expecting judgment from a tool that has none. One task, one input format, one output format, plus a written list of what the model is not responsible for. Twenty minutes, and expect to be correcting output for the first few weeks.

3. Building at the task level instead of the workflow level. Draw the full path from trigger to final state, including every place the work waits on a human. Forty-five to ninety minutes. Only works if the process has a stable shape, so stabilize a weekly-changing one before you map it.

4. Automating the ideal process instead of the real one. Document the As-Is, workarounds included. Twenty minutes per process, and the exception list is the deliverable, because a clean linear capture means you interviewed the manager. That twenty minutes routinely prevents thirty hours of debugging.

5. Feeding the AI a source nobody owns. Which system is the record, and who owns its accuracy. Fifteen minutes. Last month a client called because their system was selling a discontinued product. The build was correct. The documents they had given us still listed it as available.

That is the whole list for anything under roughly 500 operations a month.

Successful implementation is not talent and it is not luck. It is the absence of five specific mistakes, each avoidable in under ninety minutes of work you do before you build anything.

You already know how to build. What you have now is the order to decide in.

All five are decisions, not builds. That is the good news, because decisions are cheap to change and builds are not.

Build a calmer business,

– Yuri

P.S. On my LinkedIn I share short tech updates and early previews of topics before they become newsletter issues.

Yuri Vonchitzki
LinkedIn · YouTube

🔧 Tools & Resources

GitHub: version control and source of truth Every project I run lives here, process documents included, so a workflow map has one version instead of four. Wrong home for anything a non-technical colleague edits weekly.

Brevo: transactional email and CRM I moved my transactional email over recently and have been happy with it, mostly for the EU infrastructure. New accounts need deliverability warming before you route anything time-sensitive through them.

SQLite: embedded relational database Smaller projects now start here instead of on PostgreSQL, and most never need to move. It stops being right the moment you need concurrent writers or managed backups.

---

Reach 21,000+ business founders and operators implementing AI: sponsorship details are here.