← Back to my profile
Case study · Autonome

How I built Autonome, so small teams can hand over the busywork

After years of supporting teams, I kept seeing the same thing. Great people were stuck copying invoices, chasing forms and re-typing the same details into three different systems. Autonome is my answer to that.

You tell it the weekly job in plain words, like “every Monday, chase the invoices more than 30 days overdue”. It drafts a plan you can read, shows you exactly what it would send using your real figures, and only starts when you switch it on.

The part I care about most is trust. If you’re going to let something near your accounts and your inbox, you need to know it won’t go off and do its own thing. Here’s how I made sure of that.

My role: I designed and built it, from the first sketch to the website · Nov 2025 to now

At a glance

A few numbers I’m proud of

500+apps you can connect, from your accounting to your inbox
0passwords or logins the AI ever gets to see
$100Kin revenue from enterprise delivery projects
10client portals I built and looked after on Autonome 1.1
8,000+donut deliveries through the platform I built for Rebel Donuts
2public build challenges, then a feature in Bubble’s Launch Lab

$3,999 to one sentence

In 2025, getting a customer set up on Autonome 1.1 cost $3,999. Every portal was its own standalone build, and I set up each one by hand. It worked well, but every new customer meant starting again.

Today it’s one shared platform, and customers set up their own automations by describing them in a sentence. That change is the whole story of Autonome.

How it works

Six things I got right early

1. The AI suggests, and a person decides

The need
AI is brilliant at drafting, but nobody wants it pressing buttons on their behalf without asking.
What I built
The AI writes a plan in plain English, and one steady, well-tested engine runs it the same way every time. If a plan asks for something it’s not allowed to do, you find out the moment you save it, not at 6am on a Monday.
Good to know
Adding a brand new kind of step takes a little longer, because every part of the app needs to know about it. I’m very happy with that trade.

2. Your passwords stay locked away

The need
Automations need access to things like your accounting, CRM and email. Anyone who’s worked in IT support knows how easily a login ends up somewhere it shouldn’t.
What I built
Logins live in their own secure service and are only used at the exact moment a step needs them. The AI never sees one. When a job needs a bit of custom code, it runs in a sealed-off space with no logins and no way to reach your apps.
Good to know
Custom code gets its data handed to it by a normal step, rather than fetching it itself. It’s a small extra step that keeps everyone safe.

3. Every company’s data stays in its own lane

The need
Lots of companies share the same platform, so each one has to be completely sure it can only ever see its own things.
What I built
Early on I ran a security review of my own code and found a couple of spots where the rules on paper didn’t quite match what the code did. I fixed them, wrote the rules down, and added automatic checks that stop a release if anything (or anyone, me included) slips.
Good to know
Every new feature follows the same careful pattern. It’s a little more work each time, and it means I sleep well.

4. Try it without the nerves

The need
A diagram doesn’t tell a business owner much. They want to see what it would actually send, using their own figures, before anything goes out.
What I built
A test run looks at your real data but sends nothing, then shows you exactly what it would have done. If a plan reads someone’s personal inbox, only that person can test it.
Good to know
A test can’t promise the other app will accept every change, so the first real run is always started on purpose by an admin.

5. Upgrading the engine without anyone noticing

The need
The engine that runs every plan needed a new home, and customers shouldn’t feel a thing while it moves.
What I built
I recorded real runs, every step and every message, and the new engine had to match all of them exactly before it was allowed to run anything. Both engines stay live side by side, and I move one company across at a time, starting with my own.
Good to know
For now there are two engines to keep in step. That’s a small price for a move nobody notices.

6. Checking my own work

The need
The engine should never be tricked into calling somewhere private, no matter how a web address is written.
What I built
While reviewing, I found an unusual way of writing an address that two parts of the engine read differently. I closed it off, added a test so it can never come back, and made the same check run when a plan is saved.
Good to know
A handful of very unusual addresses are now politely refused. I’d much rather explain that than a breach.
How I work

Working with AI the way I’d lead a team

AI does a lot of the typing these days, and I think that’s fantastic. My job is the same one I’ve always had leading support and IT teams: set clear standards, check the work, and make sure nothing reaches a customer until it’s right.

What’s next

What I’m working on now

Get in touch

Let’s chat

If any of this sounds useful for your team, I’d love to talk it through. I’m available for senior IC and tech leadership roles, full-time or contract.