Aaron Steele, South Australia

Most analysts hand you a document.
I hand you the thing that works.

Business analyst since 2015, in mining, policing, federal service delivery and local government. Since 2016 I have also been building the automation myself, so the person who works out what you need is the person who builds it. That is normally two people and a handover, and the handover is where the meaning goes missing.

Analyst since 2015Building since 2016TOGAF certifiedBaseline cleared

What I do Working with AI
Aaron Steele, looking straight at the camera.
Aaron SteeleBusiness analyst & builder

What I do

Usually this takes two people.

Cloud architects are not hard to find. An analyst who can sit with your team, work out what the business actually needs, and then go and build it is much harder. That is the job I do, and everything below came out of doing both halves.

01

I find out what the business actually needs.

Not what somebody asked for in a meeting. The real thing, pulled out of people who disagree with each other, processes nobody has written down, and rules that only exist in somebody's head.

On the National Redress Scheme that meant turning the legislation into the decisions the system makes about who qualifies, written so the people accountable for those decisions could read them and check them. Getting that wrong is expensive, and you find out late. It is the part that gets rushed, and it is most of the value.

02

Then I build it, instead of writing a report about it.

A charity's donor records had been merged on email address instead of the account number their old system used, and their donation totals were out by $3.8 million. Nobody had worked out why.

I found it, then rebuilt 37,729 donations against the right donors myself and reconciled them to the charity's own books. Ten years across HubSpot, Salesforce, Zoho, Zapier, Make and n8n means I can usually just fix a thing like that faster than I could brief somebody else to.

03

I try to break it before your customers do.

Reading code and saying "that looks risky" is not the same as proving it. Reviewing a live shopping platform, I logged into somebody else's account and shut down their broadcast, so nobody had to argue about whether the gap was real. It was closed that week.

On the same review I told them one of the reported problems was not a problem at all. Both halves of that matter: I will not wave something through, and I will not invent a finding to look thorough.

04

And I can explain it to anyone in the room.

A decade of workshops with people who want different answers, executives who want a shorter one, and auditors who want evidence. I have mentored analyst teams through it.

I can talk to a head of sales and a mine site superintendent in the same week without changing what is true, only how I say it. Most of the projects I have watched go wrong did not go wrong on the technology.

Claude Code

Most people paste a prompt in and hope.

An AI coding agent is a delivery team: fast, tireless, literal, and perfectly willing to build the wrong thing beautifully if nobody tells it what right looks like. I have spent ten years writing the brief that stops exactly that happening to a room full of contractors. It turns out to be the same skill.

01

I give it a specification, not a wish.

What it must do, what it must never do, the edge cases, and what finished looks like. The same document I would hand a delivery team, because it is the same problem. That is the difference between output you rewrite and output you ship.

02

I make it prove its work, because it will tell you it is finished.

Both tools further down this page carry a script whose only job is to check the result against something I do not control: a different DNS provider, the original data source, the company's own website. It has caught things my own tests never could.

It has also caught the agent itself overclaiming: documentation describing a test pipeline that did not exist, and a performance report that was structurally incapable of failing. An agent saying "done" is a claim, not a fact.

03

I set it against itself.

One run builds. A separate one, knowing nothing about the first, tries to break it. That is how the security gaps above were found, and how three real defects in my own tool turned up within an hour of it going live, including one where it happily answered a question it should have refused.

04

I give it hands.

Out of the box an agent can only talk. I build it real tools, so instead of guessing about your CRM it reads your CRM, and instead of describing a job it books the job. Two of mine are on this page and you can connect to either one. The same approach reaches a CRM, an accounting system, a field service app, a warehouse, anything with an API.

05

And I make it not look like a machine wrote it.

Left alone, every one of these models produces the same page, the same email, the same report. I work to a written standard and check the finished thing against it, which is why this page does not look like the other forty you have been sent this month.

So in practice

  • An internal tool in a fortnight instead of a quarter, because the specification and the build are the same person and there is no handover.
  • A whole process automated end to end: the intake, the rules, the system it lands in, the exceptions, and the reporting somebody actually reads.
  • A stalled build finished. I am usually the second person on a project, and the first job is working out what the last one meant.
  • Agents wired into what you already run, rather than another tab your team forgets to open.
  • Your own people taught to do it properly, so this does not become one more thing only the consultant understands.
Recent work

$3.8 million
missing.

A national charity's move onto HubSpot had stalled. Their donation history was coming out wrong and nobody could say why. I came in as technical lead.

The earlier migration had merged donors on email address instead of the account number their old system used. Anyone who had changed their email, or who shared one with a partner, ended up merged into somebody else or lost. Against the charity's own books it was out by around $3.8 million.

I rebuilt the whole thing on the right key, reconciled it, and connected their donation platforms and accounting system so it stays right without anyone retyping it.

Client and partner not named, by choice.

Layers of hand-cut amber and grey glass stacked on a dark workbench, raking light catching every edge.
0organisations rebuilt against the right records
0contacts
0donations matched back to the right donor
0rounds of testing with the charity before it went live
Recent work

Finding the holes before customers do.

A live shopping platform, most of it written by AI. I was asked whether it was safe to put customers on it. Rather than read the code and give an opinion, I used the gaps, then went back after they were fixed and tried the same things again. Four of the six are properly closed now. Two are not, and I said so.

Built and shipped

Two you can go and use.

Small tools I built end to end and gave away, free for anyone to use or copy. The numbers below are not a screenshot: your browser asked both of them a question a moment ago, and this is what came back.

— jobs Rain Check can do, answering right now. It tells a trades business whether Thursday's concrete pour will survive the weather
— jobs Doorknock can do. It finds out what a company already uses before a salesperson rings them, and files it in the CRM
0 code repositories anyone can read, nothing hidden
0 made-up test data in either of them. They are tested against the real thing

Rain Check

Not "what's the weather this week". Can we pour the slab in Bendigo on Thursday. It knows concreting and painting fail on different things, checks the daylight and the public holidays too, and when a suburb name is ambiguous it asks instead of picking one and being confidently wrong.

  • MCP
  • OpenAPI
  • TypeScript
  • Serverless
Open it Source
A freshly poured concrete slab on a suburban building site, tools left mid-job, under a breaking storm sky.

Doorknock

Everything a salesperson could usefully know about a company before they pick up the phone, read from that company's own website: what software they already run, who handles their email, whether they look like a fit at all. Then scored against your own rules and filed straight into HubSpot, so nobody has to retype it.

  • HubSpot CRM API
  • MCP
  • Custom GPT Action
  • Rules as data
Open it Source Run one now
A row of weathered front doors along a bluestone terrace at dusk, warm light spilling from one open doorway.

Where I have done it

Since 2015.

Mining, policing, federal service delivery, local government, universities. Mostly the same job in different clothes: take something nobody can quite explain, work out the rules it really runs on, and get them built.

2016 to nowAI and automation consultantIndependent, alongside the day job. HubSpot, Salesforce and Zoho on the CRM side; Zapier, Make and n8n for the plumbing; Claude Code for the agents.
2022 to nowBHPSenior business analyst and architect on critical infrastructure. Mentors the junior analysts.
2021 to 2022City of MarionLead analyst on a council-wide asset management platform.
2020 to 2021SA PoliceProject Shield, rebuilding the systems frontline officers work on.
2020SA Department of EducationLed the technology side of the state's vocational education strategy.
2018 to 2020Services AustraliaNational Redress Scheme, and veterans' entitlements. Designed how the system decides who qualifies.
2018DVE Business SolutionsCRM and ERP rollouts for universities.
2015 to 2018Australian Institute of Business, Dept of IndustryWhere it started. A new CRM, and reforming a federal department's network.