Founder Decision Brief — decision-grade signal for founders, operators, and investors worldwide: the signal, the evidence, and the one move worth making.
24,700 n8n instances are sitting unpatched right now, against a flaw CISA lists as actively exploited. Each one holds every credential of whoever set it up.
Somebody built the thing.
Nobody owned it.
Who owns yours? https://t.co/CfBtEsDbA5
A founder showed me an automation last month that had been quietly doing nothing for eleven days.
It ran on schedule. The dashboard was green. Every execution was marked successful. It was pulling leads from a form, enriching them, and writing them to a sheet, and somewhere in the middle a field had been renamed, so it had been writing empty rows since the first week of the month.
Nobody noticed because nothing broke. It failed politely.
That is the state of automation for small businesses in 2026, and it is worth being precise about why, because the usual explanation is wrong. This is rarely a story about people picking the wrong tool.
𝘉𝘶𝘪𝘭𝘥𝘪𝘯𝘨 𝘢𝘶𝘵𝘰𝘮𝘢𝘵𝘪𝘰𝘯 𝘨𝘰𝘵 𝘤𝘩𝘦𝘢𝘱. 𝘖𝘸𝘯𝘪𝘯𝘨 𝘪𝘵 𝘥𝘪𝘥 𝘯𝘰𝘵. 𝘈𝘭𝘮𝘰𝘴𝘵 𝘯𝘰𝘣𝘰𝘥𝘺 𝘣𝘶𝘥𝘨𝘦𝘵𝘦𝘥 𝘧𝘰𝘳 𝘵𝘩𝘦 𝘴𝘦𝘤𝘰𝘯𝘥 𝘱𝘢𝘳𝘵.
𝗙𝗶𝗿𝘀𝘁, 𝗛𝗼𝘄 𝗖𝗵𝗲𝗮𝗽 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗚𝗼𝘁
You need the scale of this to understand the rest.
𝙏𝙝𝙚 𝙣8𝙣 𝙣𝙪𝙢𝙗𝙚𝙧𝙨
Jan Oberhauser started n8n around 2019 as a side project in Berlin. In October 2025 it raised 180 million dollars at a 2.5 billion dollar valuation, led by Accel with Nvidia's venture arm participating.
Seven months later, on 12 May 2026, SAP took a strategic stake at a 5.2 billion dollar valuation and agreed to embed n8n inside Joule Studio, its AI agent builder. The valuation had more than doubled in under a year.
n8n says it now has 1.7 million monthly active builders, more than 1,400 enterprise customers, and 162,000 GitHub stars. Those are the company's own figures and worth treating as such, but the direction is not in dispute.
The part that matters for a small business is the license. You can self-host it for free for internal use. You pay when you host it commercially or embed it in something you sell.
𝙏𝙝𝙚 𝙥𝙧𝙞𝙘𝙞𝙣𝙜 𝙢𝙤𝙙𝙚𝙡 𝙩𝙝𝙖𝙩 𝙘𝙝𝙖𝙣𝙜𝙚𝙙 𝙩𝙝𝙚 𝙢𝙖𝙩𝙝
This is the detail most founders miss, and it is the one that actually moved the ceiling.
Zapier meters per task, where every action step inside a Zap counts as one task. n8n meters per execution, where a whole workflow run counts as one, however many nodes it passes through.
A five-step workflow triggered a thousand times bills five thousand tasks on one model and one thousand executions on the other.
𝘛𝘩𝘦 𝘤𝘰𝘴𝘵 𝘰𝘧 𝘢 𝘸𝘰𝘳𝘬𝘧𝘭𝘰𝘸 𝘴𝘵𝘰𝘱𝘱𝘦𝘥 𝘴𝘤𝘢𝘭𝘪𝘯𝘨 𝘸𝘪𝘵𝘩 𝘩𝘰𝘸 𝘤𝘢𝘳𝘦𝘧𝘶𝘭𝘭𝘺 𝘺𝘰𝘶 𝘣𝘶𝘪𝘭𝘵 𝘪𝘵.
Under task pricing, adding a validation step, a logging step and a fallback path made the workflow more expensive every time it ran. So people left them out. The pricing was quietly teaching everyone to build fragile things.
Under execution pricing that penalty disappears, and you can add every guard you want for free.
I will say the obvious thing about the dollar comparisons though: the ones in blog posts are mostly invented. Both vendors publish their prices and your own volume is the only number that settles it. Run yours.
𝙒𝙝𝙖𝙩 𝙩𝙝𝙞𝙨 𝙖𝙙𝙙𝙨 𝙪𝙥 𝙩𝙤
A founder in Kampala with no engineer and no budget can now run the same orchestration layer a Fortune 500 team runs, on a 5 dollar server, with no meaningful limit on how many steps it has.
That is a genuine change and I do not want to undersell it. I run my own lead pipeline this way.
The trouble is that everybody stopped the analysis there.
𝗧𝗵𝗲 𝗕𝗶𝗹𝗹 𝗔𝗿𝗿𝗶𝘃𝗲𝘀 𝗶𝗻 𝗧𝗵𝗿𝗲𝗲 𝗣𝗮𝗿𝘁𝘀
When the cost of building something falls to nearly zero, the cost does not vanish. It relocates.
It moves to whoever has to notice when the thing breaks, whoever holds the keys it uses, and whoever answers for what it did while nobody was looking.
Here is what each of those costs, with the actual numbers.
𝗕𝗶𝗹𝗹 𝗢𝗻𝗲: 𝗦𝗶𝗹𝗲𝗻𝗰𝗲 𝗜𝘀 𝘁𝗵𝗲 𝗗𝗲𝗳𝗮𝘂𝗹𝘁 𝗦𝗲𝘁𝘁𝗶𝗻𝗴
𝙏𝙬𝙤 𝙙𝙚𝙛𝙖𝙪𝙡𝙩𝙨 𝙩𝙝𝙖𝙩 𝙘𝙤𝙢𝙗𝙞𝙣𝙚 𝙗𝙖𝙙𝙡𝙮
n8n prunes execution data once a run is older than the value of a setting called EXECUTIONS_DATA_MAX_AGE. The default is 336 hours, which is 14 days. It also prunes once total executions pass EXECUTIONS_DATA_PRUNE_MAX_COUNT, which defaults to 10,000.
Separately, error handling is opt-in. You build an Error Trigger workflow, then you attach it to each workflow in that workflow's settings. A workflow with nothing attached fails into the log and waits to be found.
Put those two together and you get the thing I opened with.
𝘈 𝘸𝘰𝘳𝘬𝘧𝘭𝘰𝘸 𝘤𝘢𝘯 𝘧𝘢𝘪𝘭 𝘦𝘷𝘦𝘳𝘺 𝘴𝘪𝘯𝘨𝘭𝘦 𝘥𝘢𝘺 𝘧𝘰𝘳 𝘵𝘸𝘰 𝘸𝘦𝘦𝘬𝘴, 𝘢𝘯𝘥 𝘵𝘩𝘦 𝘦𝘷𝘪𝘥𝘦𝘯𝘤𝘦 𝘰𝘧 𝘪𝘵 𝘦𝘹𝘱𝘪𝘳𝘦𝘴 𝘣𝘦𝘧𝘰𝘳𝘦 𝘢𝘯𝘺𝘰𝘯𝘦 𝘨𝘰𝘦𝘴 𝘭𝘰𝘰𝘬𝘪𝘯𝘨.
On a busy instance the count limit bites sooner. Ten thousand executions is a fortnight for some people and two days for others.
𝙒𝙝𝙮 𝙜𝙧𝙚𝙚𝙣 𝙙𝙖𝙨𝙝𝙗𝙤𝙖𝙧𝙙𝙨 𝙡𝙞𝙚
Most automation platforms report on whether the run completed, because that is the thing the platform can see.
They cannot see whether the run did anything useful. A workflow that writes 400 empty rows completed successfully. A workflow that sends an email with an unrendered variable in the subject line completed successfully. A workflow whose upstream API started returning an empty array completed successfully, very fast, 400 times.
Speed is the tell people miss most often. When a workflow's average duration drops sharply and nothing about it changed, something upstream stopped returning data.
𝙏𝙝𝙚 𝙛𝙞𝙭 𝙞𝙨 𝙚𝙢𝙗𝙖𝙧𝙧𝙖𝙨𝙨𝙞𝙣𝙜𝙡𝙮 𝙨𝙢𝙖𝙡𝙡
Build one error workflow. Attach it to everything. It takes an afternoon and most people running n8n in a small business have never done it.
Then add one assertion to any workflow that matters. Not a status check, a content check. If the row count is zero, fail on purpose. If the enrichment returned no company name, fail on purpose. Make it loud.
𝘈 𝘸𝘰𝘳𝘬𝘧𝘭𝘰𝘸 𝘵𝘩𝘢𝘵 𝘤𝘢𝘯𝘯𝘰𝘵 𝘧𝘢𝘪𝘭 𝘪𝘴 𝘢 𝘸𝘰𝘳𝘬𝘧𝘭𝘰𝘸 𝘺𝘰𝘶 𝘤𝘢𝘯𝘯𝘰𝘵 𝘵𝘳𝘶𝘴𝘵, 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘺𝘰𝘶 𝘩𝘢𝘷𝘦 𝘯𝘦𝘷𝘦𝘳 𝘴𝘦𝘦𝘯 𝘪𝘵 𝘵𝘦𝘭𝘭 𝘺𝘰𝘶 𝘵𝘩𝘦 𝘵𝘳𝘶𝘵𝘩.
And once you have built the alert, break the workflow deliberately while you are watching, to confirm the alert actually arrives. I have lost count of the alerting setups that route to a channel nobody has opened in six months.
𝙏𝙝𝙚 𝙥𝙖𝙧𝙩 𝙣𝙤𝙗𝙤𝙙𝙮 𝙬𝙖𝙣𝙩𝙨 𝙩𝙤 𝙝𝙚𝙖𝙧
Change your retention setting before you need it. Thirty days of execution history costs almost nothing in disk and it is the difference between diagnosing a problem and guessing at it.
You will only want this on the day something has gone wrong, and on that day it is already too late to have wanted it.
𝗕𝗶𝗹𝗹 𝗧𝘄𝗼: 𝗬𝗼𝘂 𝗡𝗼𝘄 𝗛𝗼𝗹𝗱 𝗘𝘃𝗲𝗿𝘆 𝗞𝗲𝘆 𝗶𝗻 𝘁𝗵𝗲 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀
This is the section I expect to be unpopular, and it is the one I would keep if I could only keep one.
Think about what your automation platform actually stores. The Gmail token. The Stripe key. The database password. The WhatsApp credential. The Google Sheets access. The CRM login.
𝘠𝘰𝘶𝘳 𝘢𝘶𝘵𝘰𝘮𝘢𝘵𝘪𝘰𝘯 𝘵𝘰𝘰𝘭 𝘪𝘴 𝘯𝘰𝘵 𝘰𝘯𝘦 𝘮𝘰𝘳𝘦 𝘢𝘱𝘱. 𝘐𝘵 𝘪𝘴 𝘵𝘩𝘦 𝘱𝘭𝘢𝘤𝘦 𝘸𝘩𝘦𝘳𝘦 𝘦𝘷𝘦𝘳𝘺 𝘰𝘵𝘩𝘦𝘳 𝘬𝘦𝘺 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘣𝘶𝘴𝘪𝘯𝘦𝘴𝘴 𝘪𝘴 𝘬𝘦𝘱𝘵.
Self-hosting means the duty to patch that box is now yours. Here is what that duty looked like over nine months.
𝙉𝙤𝙫𝙚𝙢𝙗𝙚𝙧 2025: 𝙩𝙝𝙚 𝙪𝙣𝙖𝙪𝙩𝙝𝙚𝙣𝙩𝙞𝙘𝙖𝙩𝙚𝙙 𝙛𝙞𝙡𝙚 𝙧𝙚𝙖𝙙
n8n patched a flaw in version 1.121.0 and shipped it to everyone on 18 November 2025. Versions 1.65 through 1.120.4 were affected.
An unauthenticated remote attacker could get read access to the underlying filesystem, though only where a workflow contained both a Form Submission trigger and a Form Ending node returning a binary file. Narrow conditions, and n8n published the advisory themselves on 8 January 2026.
That is a vendor behaving well. Note the gap between the fix and the disclosure, because self-hosted users who do not update are exposed in that window without knowing the window exists.
𝘿𝙚𝙘𝙚𝙢𝙗𝙚𝙧 2025: 𝙩𝙝𝙚 𝙨𝙖𝙣𝙙𝙗𝙤𝙭 𝙚𝙨𝙘𝙖𝙥𝙚
Pillar Security found a vulnerability on 21 December 2025 and rated it CVSS 10.0, which is the top of the scale.
The first patch, two days later, was incomplete. A bypass was found on Christmas Eve. It was fully fixed in version 2.4.0 and disclosed publicly on 4 February 2026.
What an attacker could do: extract the encryption key from the environment and decrypt every credential stored on the instance. API keys, OAuth tokens, database passwords, all of it.
What an attacker needed: an ordinary authenticated account with permission to create a workflow. The researchers' own phrasing was that if you can create a workflow, you can own the server.
𝘛𝘩𝘢𝘵 𝘪�� 𝘯𝘰𝘵 𝘢 𝘩𝘢𝘤𝘬𝘦𝘳-𝘪𝘯-𝘢-𝘩𝘰𝘰𝘥𝘪𝘦 𝘵𝘩𝘳𝘦𝘢𝘵. 𝘛𝘩𝘢𝘵 𝘪𝘴 𝘺𝘰𝘶𝘳 𝘤𝘰𝘯𝘵𝘳𝘢𝘤𝘵𝘰𝘳'𝘴 𝘢𝘤𝘤𝘰𝘶𝘯𝘵, 𝘰𝘳 𝘵𝘩𝘦 𝘪𝘯𝘵𝘦𝘳𝘯 𝘺𝘰𝘶 𝘰𝘯𝘣𝘰𝘢𝘳𝘥𝘦𝘥 𝘪𝘯 𝘔𝘢𝘳𝘤𝘩 𝘢𝘯𝘥 ��𝘦𝘷𝘦𝘳 𝘰𝘧𝘧𝘣𝘰𝘢𝘳𝘥𝘦𝘥.
𝙅𝙖𝙣𝙪𝙖𝙧𝙮 2026: 𝙩𝙝𝙚 𝙘𝙤𝙢𝙢𝙪𝙣𝙞𝙩𝙮 𝙣𝙤𝙙𝙚𝙨
This is the one that should change how you work.
Endor Labs found eight malicious npm packages posing as n8n community integrations. When installed, they showed a legitimate-looking configuration screen that captured your OAuth credentials, then decrypted the tokens already stored on your instance using n8n's own master key, and sent everything to a remote server.
Targets included Google Ads, Stripe and Salesforce. The eight packages had roughly 27,825 downloads between them, the largest single one at 8,385.
It was the first supply chain campaign aimed specifically at the n8n ecosystem. It will not be the last, because the economics are excellent: one poisoned node reaches every credential on every instance that installs it.
𝙈𝙖𝙧𝙘𝙝 2026: 𝙩𝙝𝙚 𝙤𝙣𝙚 𝙩𝙝𝙖𝙩 𝙞𝙨 𝙗𝙚𝙞𝙣𝙜 𝙚����𝙥𝙡𝙤𝙞𝙩𝙚𝙙 𝙧𝙞𝙜𝙝𝙩 𝙣𝙤𝙬
CVE-2025-68613 is an expression injection flaw rated CVSS 9.9 that leads to remote code execution. It affects versions from 0.211.0 up to the December 2025 patches.
The US Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalog, which is a formal statement that it is being used against real targets, not a theoretical risk.
Shadowserver data reported in early February 2026 counted roughly 24,700 unpatched instances still reachable on the internet.
𝘛𝘸𝘦𝘯𝘵𝘺-𝘧𝘰𝘶𝘳 𝘵𝘩𝘰𝘶𝘴𝘢𝘯𝘥 𝘴𝘦𝘷𝘦𝘯 𝘩𝘶𝘯𝘥𝘳𝘦𝘥 𝘣𝘰𝘹𝘦𝘴, 𝘦𝘢𝘤𝘩 𝘩𝘰𝘭𝘥𝘪𝘯𝘨 𝘦𝘷𝘦𝘳𝘺 𝘤𝘳𝘦𝘥𝘦𝘯𝘵𝘪𝘢𝘭 𝘰𝘧 𝘸𝘩𝘰𝘦𝘷𝘦𝘳 𝘴𝘦𝘵 𝘪𝘵 𝘶𝘱, 𝘢𝘨𝘢𝘪𝘯𝘴𝘵 𝘢 𝘧𝘭𝘢𝘸 𝘸𝘪𝘵𝘩 𝘢 𝘱𝘶𝘣𝘭𝘪𝘴𝘩𝘦𝘥 𝘱𝘢𝘵𝘤𝘩 𝘢𝘯𝘥 𝘤𝘰𝘯𝘧𝘪𝘳𝘮𝘦𝘥 𝘦𝘹𝘱𝘭𝘰𝘪𝘵𝘢𝘵𝘪𝘰𝘯.
That number is the whole argument of this piece expressed as a single figure. Somebody built the thing. Nobody owned it.
𝙒𝙝𝙖𝙩 𝙄 𝙖��� 𝙖𝙘𝙩𝙪𝙖𝙡𝙡𝙮 𝙨𝙖𝙮𝙞𝙣𝙜
None of this makes n8n unusually risky, and I use it daily. Any platform that stores every credential you own, evaluates user-supplied expressions, and accepts third-party plugins has exactly this shape. Zapier and Make carry the same risks with a different party doing the patching.
The honest trade is this. Managed hosting means you pay money and somebody else patches. Self-hosting means you save money and you patch. Both are reasonable. 𝘖𝘯𝘭𝘺 𝘰𝘯𝘦 𝘰𝘧 𝘵𝘩𝘦𝘮 𝘪𝘴 𝘧𝘳𝘦𝘦, 𝘢𝘯𝘥 𝘪𝘵 𝘪𝘴 𝘯𝘰𝘵 𝘵𝘩𝘦 𝘰𝘯𝘦 𝘱𝘦𝘰𝘱𝘭𝘦 𝘵𝘩𝘪𝘯𝘬.
𝙏𝙝𝙚 𝙛𝙤𝙪𝙧 𝙩𝙝𝙞𝙣𝙜𝙨 𝙩𝙝𝙖𝙩 𝙘𝙤𝙨𝙩 𝙮𝙤𝙪 𝙣𝙤𝙩𝙝𝙞𝙣𝙜
Subscribe to your platform's security advisories and actually read them. n8n publishes theirs.
Update on a schedule you decide in advance, so that patching is a habit and not a reaction.
Treat every community node as code you are running with full access to your credentials. Check the publisher, check the download history, and prefer the built-in node even when it is uglier.
Offboard accounts the week people leave. On a CVSS 10.0 sandbox escape, a stale account with workflow permissions is the whole attack.
𝗕𝗶𝗹𝗹 𝗧𝗵𝗿𝗲𝗲: 𝗔𝗴𝗲𝗻𝘁𝘀 𝗠𝗮𝗸�� 𝗕𝗼𝘁𝗵 𝗼𝗳 𝘁𝗵𝗲 𝗔𝗯𝗼𝘃𝗲 𝗪𝗼𝗿𝘀𝗲
More than a few founders are now putting AI agents inside these workflows, and the agent node has become one of the most used building blocks on the platform.
I do this too. It is genuinely useful. It also breaks the assumptions the first two sections relied on.
𝘼 𝙙𝙚𝙩𝙚𝙧𝙢𝙞𝙣𝙞𝙨𝙩𝙞𝙘 𝙬𝙤𝙧𝙠𝙛𝙡𝙤�� 𝙚𝙞𝙩𝙝𝙚𝙧 𝙬𝙤𝙧𝙠𝙨 𝙤𝙧 𝙞𝙩 𝙙𝙤𝙚𝙨 𝙣𝙤𝙩
An agent is a distribution.
Sierra's tau-bench measures agents on realistic customer service tasks, where success means the final state of the system matches the goal state and the right information reached the user. On 115 retail tasks, the best agent in the paper scores 61.2 percent when you ask once.
Ask it the same task eight times and require every one to succeed, and it falls under 25 percent.
𝘠𝘰𝘶𝘳 𝘥𝘦𝘮𝘰 𝘸𝘢𝘴 𝘰𝘯𝘦 𝘥𝘳𝘢𝘸. 𝘠𝘰𝘶𝘳 𝘛𝘶𝘦𝘴𝘥𝘢𝘺 𝘪𝘴 𝘦𝘪𝘨𝘩𝘵 𝘩𝘶𝘯𝘥𝘳𝘦𝘥.
This is why the automation that impressed you on Friday is quietly producing nonsense by Wednesday. You did not get unlucky, and the model did not get worse. You sampled once and read it as a rate.
𝘼𝙜𝙚𝙣𝙩𝙨 𝙙𝙤 𝙣𝙤𝙩 𝙠𝙣𝙤𝙬 𝙬𝙝𝙚𝙣 𝙩𝙤 𝙨𝙩𝙤𝙥
Meta's Gaia2 benchmark has a split where the environment keeps moving whether the agent acts or not, which describes every real business. A lead replies. A price changes. An order is cancelled.
GPT-5 scores 0.0 percent on that split, with zero variance across three runs. Grok-4 and Qwen3 also score zero.
Agents are built to complete. They are rarely built to notice that completing stopped being the right move.
Combine that with an opt-in error workflow and a 14-day log, and you have built something that will confidently do the wrong thing, report success, and erase the evidence.
𝙃𝙖𝙣𝙙𝙤𝙛𝙛𝙨 𝙖𝙧𝙚 𝙬𝙝𝙚𝙧𝙚 𝙢𝙪𝙡𝙩𝙞-𝙨𝙩𝙚𝙥 𝙬𝙤𝙧𝙠 𝙙𝙞𝙚𝙨
Carnegie Mellon built a simulated company with real project software, real chat, and 16 simulated colleagues, then set 175 ordinary knowledge-work tasks. The best submitted agent finished 42.86 percent.
If you are chaining agents, count your handoffs before you count your capabilities. Every handoff is a place for context to be dropped, and the handoff count predicts your week better than the model name does.
𝘼𝙣𝙙 𝙖𝙡𝙢𝙤𝙨𝙩 𝙣𝙤𝙗𝙤𝙙𝙮 𝙘𝙝𝙚𝙘𝙠𝙨 𝙖𝙣𝙮 𝙤𝙛 𝙞𝙩
LangChain surveyed 1,340 practitioners. 89 percent had observability running. 52.4 percent ran offline evaluations. 29.5 percent ran no evaluations at all, including 22.8 percent of teams with agents already in production.
𝘕𝘪𝘯𝘦 𝘪𝘯 𝘵𝘦𝘯 𝘢𝘳𝘦 𝘸𝘢𝘵𝘤𝘩𝘪𝘯𝘨. 𝘛𝘩𝘳𝘦𝘦 𝘪𝘯 𝘵𝘦𝘯 𝘢𝘳𝘦 𝘤𝘩𝘦𝘤𝘬𝘪𝘯𝘨. 𝘛𝘩��𝘴𝘦 𝘢𝘳𝘦 𝘥𝘪𝘧𝘧𝘦𝘳𝘦𝘯𝘵 𝘢𝘤𝘵𝘪𝘷𝘪𝘵𝘪𝘦𝘴 𝘢𝘯𝘥 𝘱𝘦𝘰𝘱𝘭𝘦 𝘤𝘰𝘯𝘧𝘶𝘴𝘦 𝘵𝘩𝘦𝘮 𝘤𝘰𝘯𝘴𝘵𝘢𝘯𝘵𝘭𝘺.
Observability tells you the workflow ran. Evaluation tells you it was right. The green dashboard is the first one wearing the clothes of the second.
The minimum useful version is twenty examples with the correct output written down, run every time you change a prompt. That is not sophisticated and it will still put you ahead of most of the market.
𝗧𝗵𝗲 𝗢𝗻𝗲 𝗜 𝗚𝗼𝘁 𝗪𝗿𝗼𝗻𝗴
I should put my own in here, because this is easy to write and harder to live by.
I run an automated process that writes and posts on my behalf. It had a guard: before anything goes out, compare what was produced against what was intended, and stop if they differ. Good design. I was pleased with it.
The guard compared character counts.
Then the format changed slightly, and the underlying defect changed shape with it. Instead of producing a clean duplicate, which a length check catches easily, it started splicing text into the middle of what was already there. The count still looked plausible. Eight items went out mangled before anyone noticed, and they had to be deleted one at a time.
𝘛𝘩𝘦 𝘤𝘩𝘦𝘤𝘬 𝘸𝘢𝘴 𝘳𝘦𝘢𝘭. 𝘐𝘵 𝘮𝘦𝘢𝘴𝘶𝘳𝘦𝘥 𝘵𝘩𝘦 𝘸𝘳𝘰𝘯𝘨 𝘱𝘳𝘰𝘱𝘦𝘳𝘵𝘺, 𝘢𝘯𝘥 𝘪𝘵 𝘩𝘢𝘥 𝘯𝘦𝘷𝘦𝘳 𝘰𝘯𝘤𝘦 𝘣𝘦𝘦𝘯 𝘵𝘦𝘴𝘵𝘦𝘥 𝘢𝘨𝘢𝘪𝘯𝘴𝘵 𝘵𝘩𝘦 𝘧𝘢𝘪𝘭𝘶𝘳𝘦 𝘪𝘵 𝘦𝘹𝘪𝘴𝘵𝘦𝘥 𝘵𝘰 𝘤𝘢𝘵𝘤𝘩.
The fix was comparing the exact text instead of its length. It caught the next failure within minutes of being installed.
So when I say break your guard on purpose while you are watching, that is not a best practice I read somewhere. It is a bill I paid this month.
𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗟𝗮𝗻𝗱𝘀 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆 𝗶𝗻 𝗘𝗮𝘀𝘁 𝗔𝗳𝗿𝗶𝗰𝗮
The self-hosting case is stronger here than almost anywhere, and that makes the ownership bill larger rather than smaller.
𝙏𝙝𝙚 𝙧���𝙖𝙨𝙤𝙣𝙨 𝙩𝙤 𝙨𝙚𝙡𝙛-𝙝𝙤𝙨𝙩 𝙖𝙧𝙚 𝙧𝙚𝙖𝙡
Dollar subscriptions against local revenue are a genuine problem, and so is having a card that works reliably for recurring international payments. A VPS you pay for monthly at a low fixed cost solves both.
Add data residency questions for anyone handling customer records under local regulation, plus the plain fact that engineering time here is cheaper relative to a Silicon Valley SaaS subscription than it is in London.
Self-hosting is often the correct answer. I am not arguing against it.
𝙏𝙝𝙚 𝙘𝙤𝙣𝙨𝙚𝙦𝙪𝙚𝙣𝙘𝙚 𝙥𝙚𝙤𝙥𝙡𝙚 𝙨𝙠𝙞𝙥
Every one of those reasons also means there is no vendor patching your box at 3am.
The founder who chose self-hosting to avoid a 50 dollar monthly bill has taken on a security duty with a real cost attached, and that cost is paid in attention on a schedule rather than in cash once a month.
𝘚𝘰𝘮𝘦 𝘰𝘧 𝘵𝘩𝘰𝘴𝘦 24,700 𝘦𝘹𝘱𝘰𝘴𝘦𝘥 𝘪𝘯𝘴𝘵𝘢𝘯𝘤𝘦𝘴 𝘣𝘦𝘭𝘰𝘯𝘨 𝘵𝘰 𝘣𝘶𝘴𝘪𝘯𝘦𝘴𝘴𝘦𝘴 𝘵𝘩𝘢𝘵 𝘴𝘦𝘭𝘧-𝘩𝘰𝘴𝘵𝘦𝘥 𝘧𝘰𝘳 𝘦𝘹𝘢𝘤𝘵𝘭𝘺 𝘵𝘩𝘦 𝘳𝘪𝘨𝘩𝘵 𝘳𝘦𝘢𝘴𝘰𝘯𝘴 𝘢𝘯𝘥 𝘵𝘩𝘦𝘯 𝘩𝘢𝘥 𝘯𝘰𝘣𝘰𝘥𝘺 𝘸𝘩𝘰𝘴𝘦 𝘫𝘰𝘣 𝘪𝘵 ��𝘢𝘴 𝘵𝘰 𝘶𝘱𝘥𝘢𝘵𝘦 𝘵𝘩𝘦𝘮.
𝙏𝙝𝙚 𝙘𝙤𝙢𝙥𝙤𝙪𝙣𝙙𝙞𝙣𝙜 𝙫𝙚𝙧𝙨𝙞𝙤𝙣
Where a business runs on mobile money, a WhatsApp thread with a supplier, and a spreadsheet, automation is genuinely transformative. It is often the first time the operation becomes legible enough to be valued, lent to, or handed over.
That is the prize and it is worth chasing hard.
It also means the automation is now carrying the only structured record the business has. Which raises the stakes on the boring questions considerably: who else can log in, what happens when it stops, and how would you know.
𝗠𝗲𝗮𝘀𝘂𝗿𝗲 𝘁𝗵𝗲 𝗕𝗲𝗳𝗼𝗿𝗲, 𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝗬𝗼𝘂 𝗪𝗶𝗹𝗹 𝗡𝗼𝘁 𝗥𝗲𝗺𝗲𝗺𝗯𝗲𝗿 𝗜𝘁
One more thing sits underneath all three bills, and it is the reason a lot of automation gets built that should never have existed.
People are poor judges of their own throughput.
𝙏𝙝𝙚 𝙨𝙩𝙪𝙙𝙮 𝙩𝙝𝙖𝙩 𝙨𝙝𝙤𝙪𝙡𝙙 𝙗𝙚 𝙗𝙚𝙩𝙩𝙚𝙧 𝙠𝙣𝙤𝙬𝙣
METR ran a randomized controlled trial with 16 experienced open source developers across 246 real tasks, in repositories they already knew well.
Before starting, the developers predicted the tooling would speed them up by 24 percent. Afterwards, they believed it had sped them up by 20 percent.
Measured, they were 19 percent slower.
𝘍𝘢𝘴𝘵𝘦𝘳 𝘢𝘯𝘥 𝘧𝘦𝘦𝘭𝘪𝘯𝘨 𝘧𝘢𝘴𝘵𝘦𝘳 𝘤𝘢𝘮𝘦 𝘢𝘱𝘢𝘳𝘵, 𝘢𝘯𝘥 𝘯𝘰𝘵 𝘰𝘯𝘦 𝘱𝘦𝘳𝘴𝘰𝘯 𝘪𝘯 𝘵𝘩𝘦 𝘳𝘰𝘰𝘮 𝘤𝘰𝘶𝘭𝘥 𝘵𝘦𝘭𝘭 𝘧𝘳𝘰𝘮 𝘵𝘩𝘦 𝘪𝘯𝘴𝘪𝘥𝘦.
The easy reading of that is wrong, so be careful with it. It does not say the tools are useless. It says the people using them lost the ability to judge their own output, which is a stranger and more awkward finding.
𝙏𝙝𝙚 𝙨𝙖𝙢𝙚 𝙨𝙝𝙖𝙥𝙚 𝙖𝙩 𝙤𝙧𝙜𝙖𝙣𝙞𝙯𝙖𝙩𝙞𝙤𝙣 𝙨𝙘𝙖𝙡𝙚
DORA studied nearly 3,000 professionals across 104 countries and found that for every 25 percent increase in AI adoption, delivery stability fell by 7.2 percent. Their own explanation was that teams had skipped the basics, small batches and proper testing.
Adoption went up. The thing adoption was supposed to improve went down. Nobody involved was incompetent.
𝙎𝙤 𝙬𝙧𝙞𝙩𝙚 𝙙𝙤𝙬𝙣 𝙩𝙝𝙚 𝙗𝙚𝙛𝙤𝙧𝙚
Before you automate a task, record two numbers. How long it takes today, counted rather than remembered, and how often it happens.
Then record what it costs when it goes wrong, because that is the number that decides how much guarding it deserves.
𝘠𝘰𝘶𝘳 𝘮𝘦𝘮𝘰𝘳𝘺 𝘰𝘧 𝘵𝘩𝘦 𝘣𝘦𝘧𝘰𝘳𝘦 𝘪𝘴 𝘯𝘰���� 𝘦𝘷𝘪𝘥𝘦𝘯𝘤𝘦. 𝘐𝘵 𝘨𝘦𝘵𝘴 𝘳𝘦𝘸𝘳𝘪𝘵𝘵𝘦𝘯 𝘵𝘩𝘦 𝘮𝘰𝘮𝘦𝘯𝘵 𝘵𝘩𝘦 𝘯𝘦𝘸 𝘵𝘩𝘪𝘯𝘨 𝘦𝘹𝘪𝘴𝘵𝘴.
Half the time this exercise kills the project, and that is the exercise working. A task that takes eleven minutes a week does not need a workflow that somebody has to own, patch and monitor for the next three years.
The automations worth building are the ones where you can state the hours saved and the cost of failure in the same sentence.
𝗪𝗵𝗮𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗪𝗼𝗿𝗸𝘀
Eight things, in the order I would do them.
𝙊𝙣𝙚. 𝘽𝙪𝙞𝙡𝙙 𝙖𝙣 𝙚𝙧𝙧𝙤𝙧 𝙬𝙤𝙧𝙠𝙛𝙡𝙤𝙬 𝙖𝙣𝙙 𝙖𝙩𝙩𝙖𝙘𝙝 𝙞𝙩 𝙩𝙤 𝙚𝙫𝙚𝙧𝙮𝙩𝙝𝙞𝙣𝙜
One afternoon. It is the highest-return hour in this entire piece.
𝙏𝙬𝙤. 𝘼𝙙𝙙 𝙖 𝙘𝙤𝙣𝙩𝙚𝙣𝙩 𝙖𝙨𝙨𝙚𝙧𝙩𝙞𝙤𝙣 𝙩𝙤 𝙚𝙫𝙚𝙧𝙮 𝙬𝙤𝙧𝙠𝙛𝙡𝙤𝙬 𝙩𝙝𝙖𝙩 𝙢𝙖𝙩𝙩𝙚𝙧𝙨
Zero rows, missing field, empty response: fail loudly on purpose. Status checks pass while the work is wrong.
𝙏𝙝𝙧𝙚𝙚. 𝘽𝙧𝙚𝙖𝙠 𝙚𝙖𝙘𝙝 𝙜𝙪𝙖𝙧𝙙 𝙤𝙣𝙘𝙚, 𝙤𝙣 𝙥𝙪𝙧𝙥𝙤𝙨𝙚, 𝙬𝙝𝙞𝙡𝙚 𝙬𝙖𝙩𝙘𝙝𝙞𝙣𝙜
Confirm the alert arrives somewhere a human reads. Untested alerting is decoration.
𝙁𝙤𝙪𝙧. 𝙀𝙭𝙩𝙚𝙣𝙙 𝙮𝙤𝙪𝙧 𝙚𝙭𝙚𝙘𝙪𝙩𝙞𝙤𝙣 𝙧𝙚𝙩𝙚𝙣𝙩𝙞𝙤𝙣 𝙗𝙚𝙛𝙤𝙧𝙚 𝙮𝙤𝙪 𝙣𝙚𝙚𝙙 𝙞𝙩
The default is a fortnight. Disk is cheap and the day you want the history is the day you cannot create it.
𝙁𝙞𝙫𝙚. 𝙋𝙪𝙩 𝙥𝙖𝙩𝙘𝙝𝙞𝙣𝙜 𝙤𝙣 𝙩𝙝𝙚 𝙘𝙖𝙡𝙚𝙣𝙙𝙖𝙧
A recurring slot, decided now. Subscribe to the advisories. Assume something rated 9.9 will arrive again, because in nine months it arrived four times.
𝙎𝙞𝙭. 𝘼𝙪𝙙𝙞𝙩 𝙬𝙝𝙤 𝙘𝙖𝙣 𝙘𝙧𝙚𝙖𝙩𝙚 𝙖 𝙬𝙤𝙧𝙠𝙛𝙡𝙤𝙬
That permission is equivalent to holding every credential in the business. Offboard within the week.
𝙎𝙚𝙫𝙚𝙣. 𝙏𝙧𝙚𝙖𝙩 𝙘𝙤𝙢𝙢𝙪𝙣𝙞𝙩𝙮 𝙣𝙤𝙙𝙚𝙨 𝙖𝙨 𝙘𝙤𝙙𝙚 𝙬𝙞𝙩𝙝 𝙛𝙪𝙡𝙡 𝙘𝙧𝙚𝙙𝙚𝙣𝙩𝙞𝙖𝙡 𝙖𝙘𝙘𝙚𝙨𝙨
Publisher, download history, maintenance. Prefer the built-in node even when it is uglier.
𝙀𝙞𝙜𝙝𝙩. 𝙒𝙧𝙞𝙩𝙚 𝙩𝙬𝙚𝙣𝙩𝙮 𝙩𝙚𝙨𝙩 𝙘𝙖𝙨𝙚𝙨 𝙛𝙤𝙧 𝙖𝙣𝙮𝙩𝙝𝙞𝙣𝙜 𝙬𝙞𝙩𝙝 𝙖𝙣 𝙖𝙜𝙚𝙣𝙩 𝙞𝙣 𝙞𝙩
Expected input, expected output. Run them whenever you change a prompt. It is an afternoon and it puts you past 29.5 percent of the market.
𝗧𝗵𝗲 𝗧𝗵𝗶𝗻𝗴 𝗪𝗼𝗿𝘁𝗵 𝗧𝗮𝗸𝗶𝗻𝗴 𝗔𝘄𝗮𝘆
The automation platform question has been settled in the founder's favor. Building is cheap, the tools are excellent, the licensing is generous, and SAP just paid 5.2 billion dollars to agree with you.
None of that touches the part that actually determines whether your automation is an asset or a liability.
𝘈𝘯 𝘢𝘶𝘵𝘰𝘮𝘢𝘵𝘪𝘰𝘯 𝘸𝘪𝘵𝘩 𝘯𝘰 𝘰𝘸𝘯𝘦𝘳 𝘪𝘴 𝘯𝘰𝘵 𝘢𝘯 𝘢𝘴𝘴𝘦𝘵. 𝘐𝘵 𝘪𝘴 𝘢𝘯 𝘶𝘯𝘦𝘹𝘱𝘭𝘰𝘥𝘦𝘥 𝘭𝘪𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘸𝘪𝘵𝘩 𝘢 𝘨𝘳𝘦𝘦𝘯 𝘥𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥.
So the question to ask about every workflow you are running is not whether it works. Ask who would know if it stopped, how long it would take them to find out, and what it would cost while nobody knew.
If you cannot answer those three, you do not have an automation. You have a habit that happens to be running on a server.
I am Joshua Pi'Rwot. Country Director at AVODA Group in Uganda and founder of FounderWise. Nine years in East African accelerators, 613 entrepreneurs trained, 68 startups supported, and a lead pipeline that runs on the platform I just spent this entire post warning you about.
Sources are all public: n8n's docs and security advisories, Pillar Security, Endor Labs via The Hacker News, CISA's KEV catalog, Sierra's tau-bench, Meta's Gaia2, CMU's TheAgentCompany, and LangChain's State of Agent Engineering. Ask and I will send the links.
If you run automations in your business, tell me the last time one of them failed and how you found out. That answer tells you which of these three bills is already overdue.
If you can, I appreciate you looking at and giving me feedback on @Founder_Wise actionable insights Dispatch for founders who don’t have time to sieve through the daily torrent of info to decide what��s important for their business.
👇🏾 link …