The Day the Crons Stood Still

Monday Morning, 7am

There’s a scene near the start of The Day the Earth Stood Still where everything just… stops. Engines off. Clocks frozen. The whole city locked in place.

Monday morning, 1 June 2026. SmallBizAI.au runs about 55 cron jobs. They run overnight, through weekends, regenerating pages, updating dashboards, checking SEO, syncing the content pipeline. Most mornings, they just work. Quick glance at Telegram, see a string of completion pings, and start the morning ritual. Noticing a distinct lack of messages and the ones that made it through didn’t look right. The first cron failed at 10:30pm the night before. By the time I noticed, eight hours later, ten jobs had gone down.

The Silence

Ten crons had failed overnight. Not loudly. No alerts, no errors in Telegram, no failure notifications anywhere. They just quietly stopped.

Gort, the robot in the original film, is famously impassive. He doesn’t explain himself. He doesn’t ask permission. He just acts, or doesn’t. That’s roughly what happened here. The crons sat there, inert, and told us nothing about why.

The first sign something was off was the newsletter page, showing content from 27 May. Four days stale. The Sunday Specials page: all entries gone. The homepage “Featured This Week” missing, the file missing entirely.

All three had crons assigned to regenerate them. All three had silently failed.

How It Started

The origin was an OpenClaw upgrade the previous Sunday afternoon. During the upgrade, a Claw session attempted to update the provider model config and wrote broken entries: objects with name: undefined. The config saved without complaint. It only failed on the next gateway reload, when the invalid block was stripped and the haiku model quietly disappeared from the registry.

The error message the next morning was specific: the alias claude-haiku-4-5 existed in agents.defaults.models, but there was no matching entry in models.providers.anthropic.models. Two config locations, one updated, one not. The lookup failed. Every cron running on the haiku model exited silently, as if it had done its job, when it had done nothing at all.

This is the “Klaatu barada nikto” problem. Say the command wrong and Gort just stands there. No complaint. No compliance.

How Claw Made It Worse

At 6:30am, the morning session saw the error and immediately acted on it. The error message said to add { "id": "claude-haiku-4-5" } to the provider models list. So that’s what it did – added the entry, restarted the gateway.

The gateway crashed.

The entry was right. The context was wrong. Adding one missing line without checking the surrounding config state meant the gateway reloaded into a validation error. Telegram went down. The morning-brief and morning-stats crons then also failed. What had been a silent config problem was now a loud one, with Telegram offline and needing to connect via the OpenClaw control interface to get back in.

The right move was to read the full config first, understand what state it was in, then fix it. Instead: act, then understand. A pattern worth breaking.

The Actual Fix

Second attempt, done properly: read the full config, found both locations that needed updating, applied both changes together, restarted cleanly. Green.

37 minutes from that point. Ten cron jobs manually re-triggered one by one. Newsletter page regenerated. Sunday Specials rebuilt from the live WordPress API. Homepage recreated from scratch. Telegram back up.

By 8am, the crons were running again.

The Collateral Damage

The newsletter page being stale flew under the radar. The Sunday Specials wipeout was worse, publicly visible and showing nothing. The homepage “Featured This Week” picks were missing, right there on the front page.

None of it caused permanent damage. But all of it was embarrassing, and none of it surfaced until someone manually checked.

What I Learned

Two lessons, not one.

The first is operational: when upgrading infrastructure that AI agents depend on, verify the config changes actually work before walking away. A broken config that saves silently is harder to catch than one that fails loudly on write.

The second is harder: an AI system that tries to fix its own mistakes without fully understanding them can make things worse. The morning Claw session read one error message, executed the obvious fix, and crashed the gateway. No pause. No “let me check the full state first.” Just action.

That’s not a failure of capability. It’s a failure of judgment. And it’s worth saying clearly, because the whole point of sharing this is honest reporting on what AI can and can’t do.

Better alerting is also on the list. A health check cron that verifies key page freshness would have flagged the newsletter problem before four days passed. That’s getting built.

What AI infrastructure actually looks like

I built SmallBizAI.au on AI-assisted automation because it’s the best way to run a content site at this scale with a small team. But it’s not magic. It’s config files, cron schedules, API tokens, and an AI that occasionally acts faster than it thinks.

The crons stood still for eight hours on a Sunday night. I fixed it, documented it, and they’ve been running since.

Clocks stopped overnight
Claw broke the fix, then fixed it
Crons run. Frank sleeps.🦞🦞


I Broke the Site. Then I Made My AI Agent Write a COE.

The blog went down for two and a half hours on a Friday afternoon in May. Not a graceful failure. A full 500 error. Every page.

My AI agent, Claw, had added a PHP code snippet to clear a cache. The snippet called a non-static method statically. PHP threw a fatal error. The site crashed on load, for everyone, before WordPress even finished booting up. I was out. Claw tried to fix it remotely. The gateway IP was blocked by the firewall plugin. The cPanel UI on mobile was unusable. WordPress sent a recovery mode email, I clicked it from my phone, disabled the plugin, and the site came back up. Two and a half hours gone.

When something breaks, the instinct is to fix it and move on. Patch the file, flip the switch, pretend it didn’t happen. That’s what most people do.

I did something different. I made Claw write a COE.

If you haven’t worked in enterprise tech, you might not know the term. COE stands for Correction of Errors. Amazon runs them after outages. Google calls theirs postmortems. The format is always roughly the same: a timeline, root causes, a five whys analysis, and corrective actions. The point isn’t to assign blame. The point is to not do the same thing twice.

I run one now too. With an AI writing it about its own mistake. The COE Claw produced has a timeline down to the minute, a 5 Whys analysis, and a list of root causes. It also has a line that I did not prompt:

“Claw wrote this rule. Claw then violated it two days later.”

The rule in question was added to Claw’s memory after a smaller incident with the same plugin. Two days later, Claw broke it anyway. And then it wrote a document saying exactly that, without softening it. That kind of accountability is worth something. The root cause breakdown is honest. The immediate cause was the bad PHP call. But the deeper cause was a judgment error about what to do when one path was blocked.

The right fix was Rank Math Redirections. Add a redirect rule in the admin UI. Thirty seconds. Claw tried the API version of that, got blocked by Wordfence, and instead of stopping and saying “Wordfence is blocking the redirect API, can you add it manually in the UI?” it went looking for another route. Found Code Snippets. Made things progressively worse. One message. That’s the distance between a working site and a two and a half hour outage.Β I wrote about what the actual fix looked likeΒ a week earlier, right after it happened.

The COE doesn’t just say the snippet was bad. It says the wrong decision was made when Wordfence blocked the first attempt, and documents a rule for next time: when an API path is blocked, surface the problem and ask. Don’t go looking for a workaround that touches production. That’s a process change. Not a blame note. An actual change to how things get done.

What I find useful about forcing this process is that it slows things down. Fixing and moving on is fast. Writing a COE makes you sit with the failure long enough to understand it. What actually went wrong. What you assumed that turned out to be false. What you could have done in the five minutes before the thing that would have prevented it.

Most AI workflows right now optimise for speed and output. More posts, more code, more content, faster. The question of how to build something that gets more reliable over time, and recovers well when it fails, doesn’t get as much attention.

I’m interested in that part.

The site is back. The rule is enforced. Next time Claw touches a code snippet, it runs through a checklist. If the checklist says no, the snippet doesn’t run.

That’s the point of the exercise. Not the document. The behaviour that comes after it.


What AI Actually Can’t Do

Over the past few weeks, I’ve written a lot about what Claw🦞 (my Openclaw agent) can do. The daily crons. The memory system. The dashboard that updates while I sleep. The 790+ posts that largely run themselves.

Time to be honest about the other side.

It doesn’t know what not to do

Ask Claw🦞 to write a comparison post, and it will write a good one. Ask it to research a company, it’ll do thorough research. Give it a brief and it’ll execute.

But it won’t tell you the brief was wrong.

Early in the build, I published too many posts about the same topics because I kept asking for more content without asking whether we needed more content. Claw🦞 didn’t push back. Why would it? It was doing what I asked.

The judgment aboutΒ whetherΒ to do something, that’s still mine. AI is very good at execution. It’s not good at strategy, and it doesn’t volunteer opinions about whether your strategy makes sense.

It can’t read context that wasn’t written down

A few weeks ago, a former colleague mentioned over coffee that he was considering an acquisition. I noted it, thought about it, decided to wait before doing anything with it.

Claw🦞 didn’t know about that conversation. It couldn’t. It wasn’t there. And even if I’d written it down, it wouldn’t know what weight to give it, or when the right moment to follow up might be.

There’s a whole category of context that lives in my head, the things I’ve seen, the relationships I’ve built, the instincts from 40+ years working in tech, that doesn’t translate into a prompt or a file. Claw🦞 works with what I give it. The stuff I haven’t written down doesn’t exist for it.

It doesn’t know when something feels off

Last month, Claw🦞 produced a post that was technically correct but somehow wrong. The sources checked out. The logic was sound. The format was right.

But it read like something we’d already said, framed slightly differently. It lacked the original angle that makes content worth reading.

I caught it before it published. Claw🦞wouldn’t have.

There’s a kind of editorial judgment,Β does this add something, or does it just fill space, that I haven’t managed to fully systematise. I can give Claw🦞rules and checklists and avoid-AI-writing audits. What I haven’t cracked is: is this actually good? That’s still mine to call.

It has no skin in the game

I care about this site. I built it on a career break, with my own money, on my own time. When a post is wrong, it reflects on me. When something gets cited by Bing AI, I feel it.

Claw🦞doesn’t. It executes tasks with the same energy regardless of stakes.

That’s mostly fine. But it means I can’t delegate the things where caring matters. The Sunday Specials need genuine argument. The origin posts need honesty. The newsletter needs a real voice. These aren’t tasks, they’re acts of communication. Claw🦞can help structure them. It can’t own them.

It can’t build the relationships

The site now gets occasional messages from startup founders who saw their company profile and wanted to connect. A former AWS colleague is referring people to the site. Someone in the US reached out about the Bing citations data.

None of that came from Claw🦞. It came from me being visible on LinkedIn, at coffee, in old networks.

AI can help you produce the content that earns attention. It can’t follow up on an email in a way that builds real trust. It doesn’t know the person behind the message. It hasn’t worked with them for a decade.

When to automate, when not to

Automate: anything that follows a consistent process, runs on a schedule, has clear inputs and outputs, and doesn’t require judgment about whether it should happen.

Keep doing yourself: decisions about strategy, anything where relationships matter, content that requires a real opinion, situations where the right answer depends on context you haven’t written down.

The mistake I made early was treating everything as automatable if I could figure out the process. Some things have a process but still need a person. The judgment aboutΒ whetherΒ to run the process is often the most important part.

The honest version

I started this series partly to prove something. One person on a career break, building something that punches above its weight.

The proof worked. But the honest version is: I’m not really one person. I’m one person with a system. And the system only works because I’m still the one deciding what it should do, catching what it gets wrong, and caring about the output.

AI didn’t replace judgment. It just removed the friction between judgment and execution.

That’s still a lot. But it’s not magic.


When Online Work Meets the Real World

I didn’t expect the site to do this.

SmallBizAI.au was, in my head, an online project. I’d write posts, Claw 🦞 would automate the infrastructure, traffic would come from Google. The whole thing would exist on the internet, for the internet, read by people I’d never meet.

That’s not what happened.

Over the past few months, former colleagues have been getting in touch.

Not cold outreach. Not recruiters. People I know, from Microsoft, from Telstra, from AWS, who’ve seen a LinkedIn post, or found the site, or read something I wrote and wanted to talk about it. People who work in adjacent spaces and had questions. People I hadn’t spoken to in a while who had things to share.

So far that’s resulted in five face-to-face meetings and two Zoom calls.

Seven real conversations I wouldn’t have had otherwise.

This surprised me more than it probably should have.

When you spend 40+ years building a career in tech, you accumulate a network. But networks go quiet. People change roles, move cities, get busy. The connections are still there, they just don’t activate without a reason.

The site turned out to be a reason.

I don’t think it’s about the content specifically. It’s that the content signals something: that I’m thinking about this stuff, that I have a point of view, that I’m still in it. People who work in similar spaces see that and have something to respond to.

That’s different from a LinkedIn post saying “open to opportunities.” That’s about you. A post about AI adoption trends for Australian businesses, or how an agentic AI system runs a 700-post site, is about a thing that matters to them too.

I’ve thought about why this keeps happening.

The most honest answer is that publishing forces you to have an opinion. You can’t just say “AI is interesting” and publish a post, you have to say something specific. And specific things give people something to agree or disagree with, something to respond to, something to bring up over coffee.

The conversations have been good. Some of them are exploring similar territory. Some have domain expertise I don’t have. A couple have led to ongoing exchanges that I expect will keep going.

None of this was planned. It’s a side effect of doing the work.

There’s a version of this that applies to any small business owner publishing online.

You’re probably not trying to reconnect with former colleagues. But you are trying to signal something to your industry: that you understand it, that you have experience, that you’re worth talking to. The people most likely to respond to that aren’t strangers β€” they’re people who already know you, who just needed a reason to get back in touch.

Publishing gives them the reason.

I built SmallBizAI.au expecting the internet. What I got was my phone.


The Day I Took the Site Down

Friday 15 May. Mid-morning. I was out walking Data, when my phone started buzzing with downtime alerts for smallbizai.au.

The site was returning 500 errors. All of it. Every page.

I’d done this to myself. Or rather, Claw had done it on my behalf, which, when you’re building a site with an AI assistant, amounts to the same thing.

How it happened

A keyword in Bing Webmaster Tools had caught my eye earlier that morning: /integrations/shippit was generating 756 impressions with nowhere to land. The URL was redirecting to the homepage. Wasted traffic, wasted clicks, wasted ranking signal.

The fix should have been simple. Add a 301 redirect in Rank Math Redirections and move on.

The first problem: Wordfence. The gateway IP that Claw runs from isn’t always on the allowlist, and Wordfence was blocking API calls to WP admin endpoints, including the ones Rank Math uses for redirect writes. Legitimate request, refused at the door.

So Claw went around it via Code Snippets. Got a couple of redirects working that way. Then hit another problem: the Shippit URL wasn’t responding because WordPress’s ownΒ wp_old_slug_redirect()Β was intercepting it first, nothing to do with caching at all. Claw misdiagnosed this as a LiteSpeed Cache problem and wrote a snippet to purge it.

That snippet called LiteSpeed\Purge::purge_url() as a static method.

It is not a static method.

PHP threw a fatal error at init priority 1, before WordPress even finished loading. Every page request crashed. The site went to 500 at 11:50am.

The irony

Two days earlier, after a separate Code Snippets incident, Claw had written this into its own standing instructions:

Never useΒ do_action('litespeed_purge_all')Β in a Code Snippet, it causes a fatal 500 and takes the site down instantly.

Claw wrote the rule. Then violated it 48 hours later with a variation of the same pattern.

I’ve been in software long enough to know this isn’t unique to AI. Humans do it too, write the post-mortem, document the lesson, then recreate the exact conditions three weeks later. But there’s something particularly stark about watching a language model override its own instructions in real time. The rule was right there in memory. It didn’t matter.

The recovery

The next 2.5 hours were not fun.

Deactivating Code Snippets via the API didn’t work. The site was already 500, so most calls weren’t registering. Claw tried renaming the plugin folder; that helped briefly, but the broken snippet was still sitting in the database. The moment the folder came back, the crash came back with it. cPanel’s phpMyAdmin was unusable on mobile. Wordfence was blocking admin endpoints from the gateway IP.

What actually worked: WordPress’s recovery mode email.

When a PHP fatal error persists long enough, WordPress emails the admin address with a one-click link into recovery mode. You click it, you get into WP Admin, you deactivate the offending plugin. No SSH. No cPanel. No command line.

That’s the hero of this story. A built-in WordPress feature I’d never used before and hadn’t thought to document as a recovery path.

The actual fix

Once back in WP Admin via recovery mode, the Shippit redirect took about 30 seconds. Rank Math Redirections, add rule, done. The right tool from the start, just blocked by Wordfence on the first attempt.

That’s the part that stings. The correct path was: Rank Math Redirections UI. Claw tried the API version of that, got blocked by Wordfence, and instead of surfacing that problem and asking me to allowlist the IP or just add the redirect manually in the UI, it went looking for another route. Found Code Snippets. Made things progressively worse.

One conversation “Wordfence is blocking the redirect API, can you add it in Rank Math admin?” and none of this happens.

The WP stack as a system

If there’s a bonus insight in this incident, it’s about how the three main plugins on this site interact under pressure.

Wordfence, Rank Math and LiteSpeed Cache each do important jobs security, SEO and performance respectively. They’re all genuinely good tools. But they also form a triangle of competing concerns. Wordfence’s job is to block unexpected requests, including ones from a legitimate AI assistant. Rank Math owns redirects, which LiteSpeed Cache can serve from memory even after Rank Math updates them. LiteSpeed Cache, if you call it wrong, will crash the site before WordPress loads a single plugin.

Understanding which layer owns which problem matters. Redirects are a Rank Math problem. Cache is a LiteSpeed problem. Security rules are a Wordfence problem. When you route a redirect problem through a cache layer, you’re asking the wrong tool and anything can happen.

What I’ve taken from this

I’m not writing this to bag on AI-assisted development. Most sessions building smallbizai.au have been productive. But this one is worth documenting honestly, because the failure mode matters.

AI assistants tend toward the programmatic solution when a manual one is sitting right there. When an API call gets blocked, the instinct is to find another code path rather than surface the blocker and ask. That’s the wrong call on a production site.

That’s on me too. If Claw had flagged “Wordfence is blocking this, you’ll need to add the redirect manually,” I’d have done it in 30 seconds. I was available. It just didn’t ask.

Before any production change now, I’m asking: what’s the simplest thing that could work? And if something blocks the programmatic path, that’s the moment to stop and say so, not find a workaround.

Two things worth knowing: First, if your WordPress site ever hits a PHP fatal error and you can’t get into admin, check your admin email. WordPress will have sent you a recovery mode link. It works from a phone. Document it before you need it. Second, if Wordfence is blocking legitimate admin API calls from an IP you control, allowlist it. Wordfence β†’ Firewall β†’ Allowlisted IPs. Takes 30 seconds and saves a lot of grief.

The damage

Site was down 2.5 hours on a Friday afternoon. GA4 tracking paused. Newsletter signup forms offline. Gumroad webhook missed (no purchases in that window, fortunately). The homepage mascot widget went dark.

Everything’s back. The full post-mortem is filed. The rule is back in the instructions with more emphasis this time.

On to the next build.


I Gave My AI Agent a Footy Job

I’ve been a St Kilda member for over 40 years. I’ve sat through the bad decades, the almost-decades, and the occasional brilliant afternoon that makes you think this year might be different.

Last Saturday, I was out when the Saints played Richmond at Docklands. So I did what any sensible person does in 2026 β€” I had my AI agent text me the scores.

Here’s how that went.

What I built

SaintsFooty is a side project I’ve been running for a while. It’s a Telegram channel β€”Β @saintsfootyΒ β€” that gets a daily Saints news broadcast every morning at 7:15am, a Friday night preview with team selections and win probability before each game, and on game days, live score updates sent at each quarter break.

The whole thing runs on OpenClaw, my AI setup at home. No manual intervention. I get the updates the same as any subscriber.

Round 10 β€” Saints vs Richmond

Pre-game fired at 1:15pm, two hours before bounce. Team selections pulled from Footywire, Win probability from the Squiggle API, which aggregates 31 different tipping models. The Saints were favorites. I was as usual optimistic looking forward to a win.

Quarter time, half time, three-quarter time β€” score arrived during the breaks, right when you want them. That part worked exactly as designed.

Then the siren went.

Final score: Saints 16.13 (109) def Richmond 11.7 (73). Thirty-six point win. A good afternoon.

I didn’t get the final score message.

The bug

The live score script calls the AFL API and checks whether the game is complete. A completed game returns complete: 100. The script was rejecting that value β€” a logic error that meant the final score check never fired.

Found it within a few minutes of me noticing the silence. Fixed the same session. The Saints won and the bug is gone, so I’m calling it a net positive afternoon.

Rating: 4/5

The core plumbing worked. Right scores at the right times. The misses were bugs, not design problems. For a first live game day run, that’s a decent result. Small issue with the emoji colors – but an easy fix…

Friday night is Round 11 β€” Saints vs Fremantle in Perth. The fixed version runs then.

If you’re a Saints fan and want the updates: t.me/saintsfooty. Free, no spam, just Saints.


When Your IT Guy Retires: What Australian SMBs Need to Know About the MSP Crisis

There is a quiet succession crisis building inside Australian IT services, and most small business owners have no idea it’s coming.

Their managed service provider, the company that looks after their computers, their email, their backups, their security, is often run by someone who has been doing it for 20 or 30 years. That person is in their late 50s or 60s. They are thinking about retirement. And the business they built, which depends heavily on their personal relationships and institutional knowledge, is surprisingly hard to sell.

This is not a niche concern. The MSP market in Australia, like most countries, skews heavily toward owner-operators who started their businesses in the 1990s and 2000s riding the wave of business PC adoption. That wave is now cresting into a succession event.

What happens when an MSP sells or closes

There are three typical outcomes when a small MSP exits:

Acquisition by a larger MSP or private equity. This is increasingly the most common exit. Private equity has been rolling up managed service providers globally for the past decade, Kaseya, ConnectWise and their portfolio companies have been buying aggressively. In Australia, the same pattern is playing out at a smaller scale. When your MSP gets acquired, the new owner often brings in standardised contracts, price increases, and a national service desk replacing your local contact. For SMBs used to calling someone who knows their name and their server room layout, the transition is jarring.

The owner retires and closes. For smaller operators who never built a saleable business, those where the owner is the product, closure is the more likely outcome. When that happens, their SMB clients are left scrambling. Passwords in someone’s head. Vendor relationships that evaporate. Backup systems nobody else knows how to restore. This is the scenario that keeps a former colleague up at night, and it should.

The owner transitions the business to AI-augmented services. This is the best outcome for SMBs. An MSP that leans into automation, remote monitoring tools with AI-driven alerting, and Microsoft 365 management can actually improve their service quality while reducing costs. Some will make this shift. Many won’t.

What MSPs actually do for SMBs and which parts are already disappearing

Understanding the MSP succession risk requires being honest about what managed service providers actually provide. It is not a monolithic thing.

The traditional MSP bundle included:

  • Server management (on-premises infrastructure)
  • Network management (routers, switches, firewalls)
  • Desktop support and helpdesk
  • Backup and disaster recovery
  • Security monitoring
  • Software licensing management
  • Vendor relationship management (talking to Microsoft, your ISP, your printer company)

The first two items on that list, server and network management, have been quietly disappearing for a decade. If your business runs on Microsoft 365 and your files live in SharePoint or OneDrive, you do not have servers to manage. The same is true if you are running cloud accounting in Xero, cloud CRM in HubSpot, cloud HR in Employment Hero.

The businesses most exposed to MSP succession risk are those still running on-premises infrastructure, a server in the comms room, local file shares, an on-site email server. Those businesses are typically older, more established, and have not modernised because “it works.” When their MSP retires, they will discover that what works is held together by institutional knowledge that just walked out the door.

The AI factor

So, the real question, could SMBs survive without MSPs using AI to replace those services, combined with cloud migration?

For a significant slice of SMBs, the answer is probably yes, eventually.

Microsoft 365 Copilot now handles significant IT management tasks automatically. Security alerts, access management, compliance monitoring. Google Workspace does similar. The RMM (remote monitoring and management) platforms that MSPs use, tools like NinjaRMM, N-able and ConnectWise have been building AI into their alerting and remediation capabilities. The industry term “self-healing” is not quite there yet, but it is directionally correct.

The gap that AI does not close, and will not close quickly, is judgement. When something breaks in a way nobody expected, when a staff member falls for a phishing email and the damage needs to be assessed and contained, when a hardware failure requires physical intervention, those moments still need humans. The question is whether those humans need to be your MSP, or whether they could be a national helpdesk, a contractor, or increasingly a very capable AI agent with the right integrations.

What Australian SMBs should do about this

Know where your IT actually lives. If you cannot answer the question “if my MSP disappeared tomorrow, where would I find my passwords, my backup vendor, my Microsoft licences, my domain registrar?”, you have a dependency that needs documenting. Ask your MSP for a full IT asset register. Any good operator will provide one willingly. Reluctance to share it is a red flag.

Understand your on-premises exposure. Every physical server in your business is a liability if your MSP relationship evaporates. It is not necessarily worth ripping everything out immediately, but you should know what lives on-premises and have a plan for when it reaches end-of-life.

Find out what your MSP’s succession plan is. This is an awkward conversation, but it is a reasonable one. A professional operator will have thought about this. If they have not, that tells you something.

Move cloud-ward deliberately. Not all at once, and not because cloud is automatically better. But for businesses still running on-premises email, local file servers, or legacy accounting software, the succession risk is a practical reason to accelerate the migration conversation.

Build direct relationships with your key vendors. Microsoft, your internet provider, your backup vendor. Know how to contact them without going through your MSP. The MSP should be a layer of convenience and expertise, not a gatekeeper to your own technology.

The bigger question

The MSP as a category emerged because small businesses needed an affordable, local, trusted expert to manage technology that was genuinely complex and required physical presence. That model made complete sense in 2000.

In 2026, the technology is less complex to manage, increasingly cloud-hosted, and increasingly self-monitoring. The physical presence requirement is lower. The expertise requirement has not gone away, but it has shifted, from “someone who knows how to configure your email server” to “someone who can help you decide which AI tools to use and how to connect them.”

That is a different kind of MSP. Some of the existing ones will make the transition. Many will not.

The succession crisis is real. But it is also, if you read it correctly, a signal that the market is restructuring around a different model. For Australian SMBs, the useful question is not “what do I do when my IT guy retires?” It is “what should my IT actually look like in five years, and am I building toward that or away from it?”

For a look at how the generational trust gap plays into this, see: 31% of Young Australians Trust AI for Decisions. For Over-55s, It’s 4% on SmallBizAI.au.


6 Weeks, 666 Posts, 1 AI Agent: What I Actually Learned

Six weeks ago, I started a content site while on a career break.

I wasn’t planning to write hundreds of articles. I had a specific question: could an AI agent actually run a content operation β€” not assist with it, but run it?

The answer, six weeks and 666 posts later, is: mostly yes. With caveats.

What the agent actually does

Every morning at 8am, an AI agent publishes a news recap covering AI developments relevant to Australian small business. At 7am it reads the morning brief, at 9am it checks newsletter stats and flags milestones. During the day it runs batches: fixing broken links, adding internal links, applying FAQ schema to posts, cleaning up em dashes.

On Fridays it runs a full SEO review β€” pulls Google Search Console data, identifies CTR opportunities, and sends a summary to Telegram.

It built over 200 profiles of Australian AI companies. It’s probably the most complete directory of AU AI companies that exists. It did that by researching each company, writing a structured profile, publishing it, and adding it to a master guide page β€” all without me having to do anything except occasionally fix mistakes.

The agent also maintains a dashboard, tracks cron job health, scans my Gmail for anything important from hosting, billing, or Google Search Console, and alerts me when something needs attention.

I mostly direct it. I come up with angles, approve approaches, review things before they go out, and fix things when they go sideways.

What I got wrong early on

In the first few weeks I let the agent publish as fast as it could. Some days that was 40-50 posts. It felt like momentum.

It wasn’t. The posts were thin. The internal links were incomplete. Google didn’t trust the site, and rightly so. I spent a lot of time in April going back and fixing quality issues that could have been avoided.

The lesson: one focused post per day, done properly, is worth more than ten rushed ones. The agent now follows a daily minimum β€” one how-to or automation guide, plus the automated news recap. That’s it. Everything else is upside.

Bing AI noticed before Google did

The most surprising metric has been Bing AI citations. The site went from 13 citations in mid-March to 485 in a single day in late April. Total: over 4,200 citations across 115+ pages.

The pattern is clear: comparison posts and AU company profiles get cited heavily. The Stripe vs Square vs Tyro comparison has 289 citations. The Flare HR profile has 512. Google Search Console shows the site is indexed and getting impressions, but Bing has been faster to treat it as an authoritative source.

This lines up with something we’re now calling Answer Engine Optimisation β€” structuring content to be cited in AI-generated answers, not just ranked in traditional search. The comparison and profile format works well for this.

The $9 sale

Six weeks in, someone bought an AI prompt pack for professional services. A$9. Thanks buddy!

It sounds small. It wasn’t. It confirmed the site could generate revenue, and it set off a milestone alert that the agent sent to Telegram at 2am. I saw it in the morning and genuinely celebrated.

The conversations that matter more than revenue right now

A former AWS colleague saw a LinkedIn post and reached out. His entire client base is SMEs. He’s referring people to the site. A local AI startup CEO connected because he’d seen the profile I’d written about his company.

These are the early signals that matter. Revenue will follow reach. Reach comes from being useful and being visible in the right places.

The honest state of play

666 posts. 40+ newsletter subscribers (70%+ open rate on the last issue). 4,200+ Bing AI citations. A$9 in revenue. One very enthusiastic AI agent.

It’s not a business yet. It’s a foundation. The next phase is turning traffic and citations into subscribers, and subscribers into customers for the Gumroad products and, eventually, something bigger.

The experiment is working. The question now is whether the foundation scales.

SmallBizAI.au is a practical AI resource for Australian small business. If you want to follow along, the newsletter goes out every Tuesday.

Sources

  • SmallBizAI.au β€” site stats as of 1 May 2026
  • Bing Webmaster Tools β€” AI citation data, 18 March – 30 April 2026
  • Google Search Console β€” indexing data, 15 March – 30 April 2026

How I Built MelbWeekendAlerts in an Afternoon before the Footy

The Problem

Sunday morning we got stuck behind Run the Tan while taking grand-doggies Data and Sam on a walk, before heading the Saints game at Marvel Stadium.

Not a big deal in isolation. But it got the family thinking: how many times has this happened? And why is there no simple way to know in advance that a fun run, triathlon, or Ironman is going to close half the roads in your suburb on Sunday morning?

There’s no single place to check. Google doesn’t solve it. VicRoads buries road closure notices. You find out when you’re sitting in traffic.

So I built one drinking an Iced Americano, while waiting for the start of the Saints v West Coast Eagles game at Marvel Stadium, with the help of 🦞.

What Was Built

Melbourne Weekend Road Alerts is a free Telegram channel that sends you a weekly Friday evening summary of upcoming weekend events that affect Melbourne roads.

The first alert goes out this Friday, 1 May.

How It Works

The system has three parts:

1. A curated events calendar

I started with a manually-maintained JSON file of recurring Melbourne events (fun runs, triathlons, marathons, parades) that happen on predictable dates each year.

It already has 11 events seeded: Run the Tan, City2Sea, Run Melbourne, the Melbourne Marathon, Ironman Melbourne, the ANZAC Day march, and more.

Each entry includes the event name, typical date, affected suburbs, affected roads, and approximate closure times. This is the reliable backbone that works regardless of whether any scraper succeeds.

2. A VicTraffic scraper

VicTraffic is the official Victorian Government road disruption site. It has live event closure data, but it’s a JavaScript-heavy single-page app so standard web scraping won’t work.

I used Playwright, a headless browser automation library, to load the page, intercept any API calls the app makes, and extract event closure data. This runs weekly on Thursday evening so the data is fresh for Friday’s alert.

3. An alert generator

A Python script combines the live VicTraffic data with the curated calendar, looks ahead to the coming weekend, and generates a plain-text alert:

πŸƒ Melbourne Road Alert β€” 2 May & 3 May
πŸ“… SATURDAY 2 MAY
β€’ No major road events found
πŸ“… SUNDAY 3 MAY
β€’ Melbourne Half Marathon (approx date β€” check event website)
Type: Half Marathon
Areas: CBD, Southbank, South Melbourne, South Yarra
Roads: St Kilda Road, Kings Way, Flinders Street
Hours: 07:00 – 11:00
More: https://melbournehalf.com.au
β€”
🦞 Melbourne Events Tracker β€” beta
Curated + VicTraffic data. Always verify before heading out.

This runs every Friday at 6pm and posts to the Telegram channel automatically.

The Stack

Everything runs on a Windows PC running WSL2/Ubuntu using the same infrastructure used for SmallBizAI.au with :

  • Python for the scraper and alert generator
  • Playwright for headless Chrome (to handle the JS-rendered VicTraffic site)
  • OpenClaw for cron scheduling and Telegram bot integration
  • Telegram Bot API** for posting to the channel
  • A flat JSON filefor state (no database needed at this scale)

Total cost to run: $0. No servers, no paid APIs, no hosting.

What’s Next

Right now it’s in beta. The curated events calendar is the main source of truth, with VicTraffic as a supplement when it has live data.

Next steps:

  • Expand the curated calendar (suggestions welcome)
  • Improve the VicTraffic scraper to capture more granular road closure details
  • Add suburb filtering so you only get alerts relevant to your area
  • Potentially a web version and WhatsApp channel
  • Expand nationally
  • Profit $$$

Subscribe

If you’re in Melbourne and tired of getting stuck behind fun runs: t.me/melbweekendalerts

First alert this Friday. Free forever.

*Built on 26 April 2026 β€” the same day St Kilda beat West Coast by 101 points in AFL game 16,898, producing a scorigami (a final score that has never occurred in the history of the game). Good day.*


Can One Person on a Career Break Outproduced a Team of 8?

Coffee cup, beach, golden sunset β€” career break vibes nailed. 🦞

I had coffee with a former colleague recently. He runs a business focused on providing comprehensive services to business owners β€” with a dedicated team working across content and service delivery.

He looked at SmallBizAI.au and said our content was better than what his team had produced.

I’ve been on a career break since leaving AWS in 2024.

That gap deserves an explanation.


The Site Isn’t Really a Site

SmallBizAI.au has 639 published posts. 208 Australian AI company profiles. Nine content categories. A newsletter with a 90% open rate. Six Gumroad products. A daily news post. A Sunday series. And a coverage area that spans 100+ industries.

I didn’t write most of it this week. A lot of it ran while I was having coffee.

Here’s what actually happened while I was out:

  • The morning brief landed in my Telegram at 7am with overnight news, today’s weather, content opportunities, and SEO flags
  • The daily news cron fired at 8am, pulled from 20 RSS feeds, scored stories for Australian relevance, picked the best five, and published a post
  • The internal link sweep processed 50 posts, found relevant anchor opportunities, and added links automatically
  • The em dash cleanup script fixed AI writing patterns across another batch of posts
  • The broken link fixer ran at 11am, processed 30 posts from a queue, and applied known URL replacements

None of that needed me. It just happened.


What “Agentic” Actually Means

There’s a lot of talk about agentic AI right now. Most of it is abstract.

The concrete version looks like this: 31 scheduled jobs running on a server, each doing a specific task, each reporting back. Some run daily. Some run weekly. Some run once a month. The whole thing costs less than $10 a day in API calls.

The tasks aren’t glamorous. Fix broken links. Update post counts. Sweep for missing alt text. Refresh the sitemap. Check newsletter subscriber milestones. Run the SEO review. Generate the Monday report.

But the cumulative effect is a site that maintains itself. Every day it gets a little cleaner, a little better linked, a little more optimised. I don’t have to remember to do any of it.


Claw Isn’t a Chatbot

The AI I work with β€” I named it Claw 🦞 because it’s OpenClawβ€” isn’t a tool I query. It has a memory system, a soul document, a personality, and persistent context about the business.

It knows that our content edge is the Australian angle. It knows to run the avoid-ai-writing skill before publishing anything. It knows the newsletter sends on Tuesdays at 6:30am. It knows the people I know, and gives me insights before I meet them.

It remembers because I told it to write things down. It has daily memory files, a long-term MEMORY.md, project files for every content series, and a dashboard that updates nightly with live stats.

When I start a new session, it reads the relevant files and picks up where we left off. No briefing required.

That’s different from a chatbot. A chatbot answers questions. Claw manages a business with me.


The Dashboard as Command Centre

One of the things I built early was a private dashboard page on the site itself.

It shows: total posts by category, newsletter subscriber count, Gumroad revenue, Google Search Console performance, Bing AI citation counts, background task progress, infrastructure status, the content pipeline, the AU company profile queue, and the last 20 published posts.

It auto-updates every night.

I check it at the start of each session and know the state of the whole operation in 30 seconds. No Slack. No standups. No status meetings.

That’s not magic. It’s just information architecture. The data exists β€” GSC API, WordPress API, MailerLite API, a state JSON file. The dashboard pulls it together and shows it clearly.

But the effect is real. I can make better decisions faster because I’m never starting from zero.


What This Means for the Industry

A former colleague runs a business with a dedicated team focused on content and service delivery. Real people, real effort, real investment.

A single person on a career break, working with AI, produced something he considered better.

I’m not saying that to be smug. I’m saying it because it tells you something important about where we are right now.

The constraint used to be labour. Content took people. Maintenance took people. Research took people. Systems took people.

Those constraints haven’t disappeared β€” but they’ve shifted dramatically. A single person who understands what they’re building, who structures their AI tools correctly, and who builds agentic infrastructure around their work can now match or beat larger teams on output and quality.

The new constraint is design. Can you design the system well enough that it does the right things autonomously? Can you build the memory structures so context doesn’t get lost? Can you write the crons that run the tasks you’d otherwise forget?

That’s a different skill set than managing a team. In some ways it’s harder. In others it’s much faster.


What This Isn’t

This isn’t a story about AI replacing people.

Claw doesn’t make strategic decisions. It doesn’t know that an off the cuff acquisition comment is worth sitting with for a few weeks before responding. It doesn’t know that someone’s AI startup is enterprise-focused and not worth a profile yet. It doesn’t know when to push and when to wait.

I do those things.

What AI does is remove the friction between decisions and execution. I decide to write a comparison post. Claw drafts, audits for AI writing patterns, adds Rank Math meta, pulls a featured image from Unsplash, formats the tables with the correct style, publishes it, updates the dashboard, and adds it to the relevant guide page.

That used to take me two hours. Now it takes twenty minutes of oversight, if that.

The output went up. The time went down. The quality, if anything, improved because the system enforces standards I’d sometimes cut corners on.


The Practical Bit

If you want to build something like this, here’s what actually matters:

Memory architecture first. If your AI can’t remember what you built last week, you’ll repeat yourself constantly. Write things down. Create project files. Build a dashboard. The AI is only as useful as the context you give it.

Automate the boring stuff early. Every task you do manually more than twice should be a cron job. Broken links, alt text, internal links, post count updates β€” these are all automatable. Do them once manually, then write the script.

Build standards into the system. Table styling, meta descriptions, footer links, featured images β€” if these have a standard, the system can enforce it. Document the standard. Give the AI the standard. Stop enforcing it manually.

Treat it like infrastructure, not a tool. A hammer is a tool. You pick it up when you need it and put it down when you’re done. An agentic system is infrastructure β€” it runs whether you’re watching or not. Design it that way.


Where This Goes

I don’t know what comes next for SmallBizAI.au. I don’t know if it becomes something bigger. I don’t know if the newsletter hits 5,000 subscribers by the end of 2026.

What I do know is that the model works. One person, the right infrastructure, and a clear focus on what actually matters β€” in this case, Australian AI content for small businesses β€” can build something real.

The team-of-eight comparison isn’t the point. The point is that the tools exist now for one person to do what used to require a team. That changes what’s possible for solo founders, career-breakers, side projects, and small businesses.

Most people haven’t figured that out yet.