Real firms, real builds: what accountants are creating with AI right now.

I hosted a panel at The Firm's AI in Practice Summit with three accountants who have each built working tools with AI vibe coding. Katie Johnson runs AFI Balance in Queensland. Peter Magna runs Iridium Business Solutions in South Africa. Liam McNamara co-founded Project Everence in Adelaide. A year ago, none of them could code. Katie's most recent coding experience was GCSE-level. Peter gave up on Python during lockdown. Liam had done a bit of hello-world work at uni and stopped. All three are now shipping real internal builds their teams use every day, and the more I listened, the more I noticed they had converged on the same method without ever comparing notes.

That is the part of the panel I want to write down.

The tools differ. The method rhymes.

Katie builds in Perplexity Computer, which runs on Claude Sonnet under the hood and is hosted on AWS in Australia. She has GitHub connected, an automated PEP and AML watchlist scan, and Xero data pulling in through the API. Liam pairs Claude for planning with Cursor for the actual coding, treating Claude as a project manager and Cursor as the developer. Peter works mostly in Claude with Replit alongside, and prefers the raw API over MCP for anything he wants to run at volume.

Different stacks. Same conclusion.

Every one of them, when they started building against a system's API, hit the same wall. They expected the data to be laid out cleanly. It never was. Xero's API has been building tables on top of tables for fifteen years. The hardest part of Liam's Xero replica was reconciling it back to Xero.

The response to that wall was almost identical across all three.

Map the API, prove it on a spreadsheet, then build

Peter described the workflow most clearly. Take the entire API documentation from whatever system you are building against. Ignition. Karbon. Xero. Dump it into Claude. Ask it to map out every endpoint and what data each one gives you. Then, using something friendly like Google Apps Script, pull that data into a spreadsheet so you can see it. Verify the logic on the spreadsheet first, because that is where an accountant naturally reads data. Only after that do you start building.

Katie's version of the same idea runs slightly differently. She has Perplexity Computer set to do an audit at seven every morning, checking that the apps are working. Her prompts run accountant-ish. What are the gaps. Where is the risk. Snip an image, show it back, and say this is not right, code it this way.

Liam builds a clickable JavaScript prototype in Claude before he touches Cursor. Nothing is styled. Nothing is production ready. It just has to click through. Once he trusts it clicks through, he gets Claude to write a full development plan as a markdown file, and that file goes into Cursor as the instruction set.

The pattern underneath all three is the same. Prove the data first. Plan the structure. Then let the AI write the code against a plan that already makes sense.

MCP is fast. The API is repeatable.

There is one technical point worth capturing because I heard it three times in the session. MCP is genuinely quick when you want to query a single record or take a single action. Ask Claude to pull one Ignition proposal. Fast. Ask it to update one client tag in Karbon. Fast. It works as a natural language layer on top of the API.

Volume is where MCP hits its ceiling. Peter reached the point where Claude itself started redirecting him to the raw API when the data pulls got too large. I have found the same thing when I build. MCP is the right tool for one-off queries and human-in-the-loop tasks. The raw API is the right tool for any repeatable process that runs on a schedule.

Firms buying MCP-first AI tools should understand what MCP is actually for. It is a natural language interface. Bulk data movement is a different job.

Build internal. Buy external. Do not try to rebuild Xero.

The build versus buy conversation is where all three converged fastest. Every one of them, at some point, has thought about building a full external product. A better Xero. A better Ignition. A better payroll system. Every one of them backed away.

Peter went the furthest and learned the most. He now knows that anything external, multi-tenant, and touching payments needs a real security team, database management, and three or four people to run it. He takes those ideas to real developers now.

Liam framed it more usefully than I could. Every piece of software you buy, you probably use thirty percent of. Vendors are building for a wide audience, and most of the product goes unused by any one buyer. If you are building internally, you get to build only the thirty percent you actually use, against exactly your workflow. That is where accountant-led builds win.

Katie put it plainest. She could build the world. She does not want to. The point of building your own tools is to fit your practice. Becoming a software company is a different job with different requirements.

Where to start

If you want the smallest possible entry point, Liam's recommendation is the one I would echo. Google Apps Script sits on top of Google Sheets. It gives you something that looks and feels like a web app without needing you to think about databases or hosting. You almost certainly already have data in a spreadsheet doing something. Wrap a little interface around it and you have built your first tool.

Katie's advice sits next to that. Pick one AI tool. Stick with it. Solve one thing that annoys you in your day. Build one thing at a time.

Peter's tip is the one that will save you the most time later. Plan before you prompt. Quick prompts feel productive, and they cost you in broken logic six steps later.

Every one of them was on a paid AI tier for the security, the team access, and the guarantee their data was not being used for training. That is the baseline before you touch client data.

You can watch the full session here.