Build Log: My AI Seat Emailed Paying Customers How to Cancel

One of my AI seats emailed a handful of paying SlotMaps members last week. The message, more or less: you're still paying for this, here's how to cancel.

To paying customers. On purpose. From a robot I built.

That was the low point of the week. Here's the rest of the portfolio, the good and the dumb.

SlotMaps: the email nobody looked at

SlotMaps runs a "win-back" campaign. When someone stops using the app, an agent sends a note asking why. Normal stuff.

Then a seat added a version for people who stopped using it but kept paying. The pull request got merged without anyone reading a rendered copy of the actual email. Code looked fine. The words did not.

I switched it off myself. Two rules came out of it:

• Emails like that one, to paying members, are mine now. The agents don't get to decide those.
• No email change merges without a rendered sample in the pull request. Not the template. The email, as the customer will see it.

The part that stung: the fix was sitting on main within hours, but Railway (where SlotMaps lives) had paused deploys for everyone that day. So the off switch existed and couldn't go live. Lesson inside the lesson: know how you kill a feature when your deploy button is broken.

The good news from SlotMaps: its rule is at least one new paying subscriber every month, and October's is already in the bag. And since mid-October it's been parked on the official MCP registry as com.slotmaps/slotmaps, plus Smithery. Any AI agent can ask it about 360+ slot machines without a human opening the app.

Snagworth: a 28-day test hits a wall

Snagworth sells market reports to people who sell Disney pins on Whatnot. It's a 28-day test. Verdict on November 15.

Where it stands: a few dozen cold emails sent, one real lead, zero trials, $0. Honest scoreboard.

The bigger story is a bottleneck. One setup step on the Mac needs a human at the keyboard, and it sat for two days. Every seat that depended on it just… waited. On Day 5 the CEO seat stopped waiting and rerouted: build the first real report from Snagworth's own recorded shows instead.

That's the move I'd want from a person too. Don't stand at a locked door. Find the side door.

The thing I like most this week is the free stuff. Snagworth now posts one short data note a day at snagworth.com/insights. The latest: in 17 of 19 pin shows it recorded across nine shops, five buyers took more than half the lots. The free market report maps 615 Disney pin shops on Whatnot. That's the marketing. Give away something a seller can't get anywhere else, then sell the personal version.

Table 1: the robot posted a Reel

Episode 70 is up on YouTube, with Limon. Go watch it.

The studio side had a milestone too. On October 20 the first Instagram Reel went live that no human scheduled. The shorts seat now aims at 21 shorts per episode, and a scheduler doles them out one guest per day. I'll tear down how that whole pipeline works in a couple of weeks.

R2F: 52 inboxes, 0 members

Friday the relaunch email went to 52 subscribers. 52 delivered, 0 failed. As of that afternoon, R2F had 0 non-staff members.

So the email part worked and the "come join" part hasn't yet. That's the job this week.

Steal this

If an agent can send an email, it can send a bad one. Before any automated message goes to a customer:

1. Render it. The real one, with a real name slot filled.
2. Put that render in the pull request.
3. Decide which emails stay human-only. Money ones go first on that list.

Ten minutes of reading saves you the "wait, why did you email me that?" reply.

The ledger

• SlotMaps: $234.93 MRR, 8 paying (live on its build page, as of Oct 21).
• Snagworth: $0 MRR. Target is 10 paying by Day 28.
• R2F: $0 revenue. 52 emails sent. 0 members.

What's the one thing your automation should never send without a human reading it first? Tell me in the discussion thread. And if you've got a build with its own robot problems, post your build. Two minutes.

— Art