In May 2026 we took our whole team up into the mountains in Rizal, in the Philippines, for a day of vibe coding. That means building apps by telling an AI what you want in plain English, rather than writing the code yourself. Almost nobody in the room was a software developer. We had 31 people in 14 small teams, and between them they built 10 apps. One of them, a payroll tax reconciliation tool, replaced a workpaper at year end and cut that work by 70%

That was a nice result, but it wasn't the point. The point was to change how people think about their everyday work

Why run a hackathon in an accounting firm

Accounting and bookkeeping firms are full of work that's repetitive, follows the same rules every time and eats up hours. Activity statements. Tricky reconciliations. Payroll. The people doing that work know exactly where it hurts, because they deal with it every day

What they usually don't know is what can be done about it. Getting from "this is tedious" to "a computer could do this" takes a kind of translation most accountants and bookkeepers have never been asked to do. They can explain the problem in accounting terms. They can't yet explain it in a way someone technical could pick up and build a fix for

That translation is what we wanted to teach. Not how to build apps. Not a stream of new internal tools. Just the ability to look at a manual task, spot the parts a computer could do, and explain them clearly enough to hand over. Accountants who can talk tech

AI tools are now good enough that you can teach this by doing it instead of explaining it. Someone who has never written code can tell Claude what they want and watch it appear. The learning happens when what they get isn't quite what they asked for

Be clear about what you are not doing

Say this out loud on the day, because people may assume the opposite. We weren't asking anyone to become a developer. We weren't building systems to run the firm on. We weren't setting things up so every team ends up looking after its own half-finished app

The goal was for people to get comfortable and see what's possible. If something useful came out of it, great. If it stayed a rough draft that proved a point, that counted as a win too

If you don't say this, people tend to do one of two things. They freeze, because they think they're being asked to do a job they aren't qualified for. Or they overreach and try to build something polished enough for clients in six hours. Both come from the same misunderstanding

Build a starter kit

This was the single biggest thing we did, and the one I'd recommend if you're planning your own. Sit someone non-technical in front of an empty folder and they'll spend the whole day on everything except their actual problem. Setting up where the code lives. Working out how to get it online. Fighting with logins. Staring at an error message with no idea whether it's serious or nothing

So we built a starter kit, a small ready-made app for everyone to build on. It already handled the hard, boring parts: putting the app online, saving every version, logins, encryption and security, plus some basic tools for tracking down problems. All people had to do was save their work to git and the rest took care of itself

That meant every hour went into the thing they cared about, which was solving their own problem. It also meant that when something went wrong, it was usually because they hadn't described the problem clearly enough. That's exactly the lesson you want them to learn

You don't need anything elaborate. A working skeleton with the plumbing already connected is enough

Get to know git

Git keeps track of every version of your code, and it matters even more when AI is doing the writing. Think of it as a workpaper history for code. Every change is recorded and dated, and you can go back to any earlier version. Claude or Cursor writes the code on your computer. Git records what changed. Sending those changes up to GitHub, an online home for your code, is what puts the app live. And git is how you get back to safety when someone's third request to the AI breaks what the first one built

Get comfortable with how Claude, Cursor and git fit together before the day. You'll run into it within the first hour

On the day it gives you three things. Several people can work on the same app without overwriting each other. Anyone can undo a bad change instead of starting again. And putting the app online becomes one step instead of a technical project, so someone who has never coded can see their idea working minutes after describing it

At a minimum, set up a GitHub account your firm owns, create a repository (a project folder on GitHub) for each pair before the day, and connect them to a hosting service so saved changes go live automatically. Whoever runs the room should have gone through the whole cycle themselves at least once: describe it, build it, save it, see it live

Keep the problem small

People often start out ambitious, wanting to solve every problem at once. Start small

We've seen this go wrong at other hackathons. Someone turns up with a big, important problem, spends the morning finding out how many exceptions and special cases it has, and ends the day with a slide describing the problem and nothing built. They go home a bit flat and no more confident than when they arrived

Picking a big problem is a good instinct almost everywhere else. Here it's the main thing that ruins the day

Push people toward the smallest, clearest task they can find. One reconciliation. One report. One spreadsheet clean-up that currently takes forty minutes. The value comes from getting all the way from problem to something that works, because doing that once is what makes it click. A small thing that's finished teaches far more than a big thing that isn't

If people send you their problem in advance, you can help them shrink it to something doable before the day starts

Set up guardrails and a safe sandbox

People need to feel safe to experiment, knowing they can't break anything or expose anyone. In our industry that mostly means keeping client information private

Put guardrails in place so nothing anyone builds can reach real client data. Then go a step further and prepare some practice data ahead of time. Sample files, made-up ledgers, whatever suits the problems people are likely to pick. If someone has to stop and wonder whether they're allowed to upload a file, you've lost their momentum and their willingness to try things

Feeling free to experiment is most of what makes the day work. That only happens if the boundaries are set before anyone starts

Pair people up

Nobody works alone. When one person gets stuck, they stall. When a pair gets stuck, they talk, and that conversation is where the learning happens. One suggests a different way to describe the problem, the other pushes back, and between them they land on something neither would have got to alone

Pairing also builds confidence. Watching someone at your own level work through a problem is far more encouraging than watching an expert make it look easy

Have experts in the room

Have technical people in the room, walking around, ready to answer questions. Their job is to get people unstuck, not to build things for them. There's a big difference between "here's what that error message means" and grabbing the keyboard. The first teaches. The second makes a better demo, but people learn less

The technical questions were rarely hard. Mostly people wanted to hear they were on the right track, or needed a nudge when they'd gone down a dead end

Plan for the day after

Most hackathons end at the demo. That's where most of the value disappears, because everyone goes back to their day jobs and the apps quietly die

We encouraged people to keep building afterwards, and backed that up with time set aside and group chats. Several teams kept going. The payroll tax reconciliation tool is the one that made it all the way to year end

Oh, and one thing to remember. An app that stays in the sandbox is a learning exercise. The moment one is used on real client work, your firm is professionally responsible for it like anything else, and the TPB's guidance on AI is clear that using AI doesn't change that. We work under those same rules ourselves

If you want anything to last, decide before the day who's responsible for following up, and give people who want to keep going the time to do it. Otherwise you've run a nice team-building day, which is fine, but it isn't what you told everyone you were doing

A rough shape for the day

  • Before. Collect problems in advance, and help people cut them down to size
  • Open. Explain what the day is and isn't for
  • Demo. Show everyone the tools and the starter kit
  • Define. Have each pair pick their problem and describe it before building anything
  • Build. Two building sessions with experts walking the room, and a proper break in between
  • Show. Everyone shows what they built, with leadership in the room
  • Close. Tell people clearly what happens next

What we'd change

More check-ins during the day. Get everyone set up with Claude and git before they arrive. The demos were good, but the most interesting part was how people worked through problems, and hardly anyone outside each pair saw that. A couple of quick mid-day show-and-tells would have spread the learning further

Beyond that, the format held up. A day, a starter kit, small problems, pairs, experts on hand