In May we took our whole team up into the mountains in Rizal, in the Philippines, and spent a day vibe coding apps using AI. Almost none of the people in the room were software developers. By the end of the day people showed off some of the apps they had built, one of which we used to replace a workpaper that helped finalise year end

That outcome is nice, but it wasn't really the point. The point was to change how people think about the work they do each day

Why run a hackathon in an accounting firm

Accounting and bookkeeping firms are full of work that can be repetitive, rule-based and chews up a lot of time. Activity statement preparation. Complex reconciliations. Payroll processing. Everyone who does that work knows exactly where the friction is, because they feel it every day

What they don't typically have is a sense of what can be done about it. The gap between "this is tedious" and "this could be automated" requires a kind of translation that most accountants and bookkeepers have never been asked to do. They can describe the pain in accounting terms. They can't yet describe it in a shape that a technical person could pick up and build a solution for

That translation skill is what we wanted to teach. Not app development. Not a pipeline of internal products. Purely the ability to look at a manual process, recognise the parts of it a machine could do, and articulate that clearly enough to hand over. Tech-savvy subject matter experts

AI tools have reached a point where you can teach this by doing rather than by explaining. Someone with no programming experience can describe what they want to Claude and watch something appear. The learning happens in the gap between what they asked for and what they got

Be clear about what you are not doing

Say this out loud on the day, because people may assume the opposite. We were not asking people to become developers. We were not building production systems. We were not starting a shadow IT function where every team maintains its own half-finished tool

The goal was comfort and understanding. If something useful came out the other side, good. If it stayed at the level of a rough prototype that proved a point, that was a success too

Without this framing, people either 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 production-grade in six hours. Both failure modes 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 a non-technical person down in front of an empty folder and they will spend the entire day on everything except the problem. Setting up a repository. Working out what deployment means. Fighting with authentication. Getting stuck on an error message with no idea whether it's serious or trivial

So we built a small code base for them to start from. It handled deployment, version control, login, data encryption and security, and had basic debugging scaffolded in. All people had to do was push to git and the rest sorted itself out

That meant every hour of the day went into building the thing they cared about, which was the logic of their own problem. It also meant the failures they hit were interesting failures. When something went wrong, it was because they hadn't described their problem clearly enough, which is 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 is a cornerstone of app development, and even more important if vibe coding as it manages version control. Think of it as a workpaper history for code. Every change is recorded, dated and referenced, and you can roll back to any earlier version. Developers start there because everything else builds off it. Claude or Cursor writes the code on your machine. Git records what changed. Pushing that record to a hosted repository like GitHub is what triggers the code to build and deploy. Git is also how you recover when someone's third prompt breaks the thing the first one built

Get familiar with how Cursor, Claude and git fit together before the day, because you will run straight into it within the first hour

For a hackathon it unlocks three things. Several people can work on the same code without stomping on each other's work. Anyone can undo a bad change instead of starting over. And deployment becomes a single step rather than a technical project, which is what lets a non-developer see their idea running live minutes after describing it

As a minimum setup, establish a GitHub organisation your firm controls, a repository per pair created before the day, and a hosting service connected to those repositories so a push deploys automatically. Whoever runs the room should have done the describe, build, push, deploy loop themselves at least once

Keep the problem small

People often start ambitious, wanting to solve the world's problems. Start small

We've watched this go wrong at other hackathons. Someone arrives with an important problem, spends the morning discovering how many edge cases it contains, and finishes the day with a slide describing the problem and nothing built. They leave slightly deflated and no more confident than when they arrived

The instinct to pick a big problem is a good instinct in every other context. Here it's the main thing that kills the day

Push people toward the smallest well-defined unit they can find. One reconciliation. One report. One data transformation that currently takes forty minutes. The value of the day comes from completing a full loop, from problem to working thing, because that loop is what embeds the understanding. A finished tiny thing teaches far more than an unfinished significant thing

If you have people submit their problem in advance, you get a chance to shrink it before the day starts and make it more achievable

Set up guardrails and a safe sandbox

People need to feel they can experiment without breaking anything or exposing anyone. In our industry that mostly means client confidentiality

Contain the environment so nothing anyone builds can touch live client data. Then go one better and prepare a corpus of test data ahead of time. Sample files, dummy ledgers, whatever fits the problems people are likely to pick. If someone has to stop and think about whether they're allowed to upload a file, you've lost both their momentum and their willingness to try things

The freedom to experiment is most of what makes the day work. It only exists if the boundaries are set before anyone starts

Pair people up

Nobody works alone. When a single person gets stuck, they stall. When a pair gets stuck, they talk, and the conversation is where the learning happens. One person suggests a different way to describe the problem, the other pushes back, and between them they arrive at something neither would have reached on their own

Pairing also spreads confidence. The person who is slightly less comfortable with technology watches someone at a similar level work through a problem, which is far more encouraging than watching an expert do it effortlessly

Have experts in the room

Have technical people present, circulating, available for questions. Their job is to unblock people, not to build for them. There's a real difference between "here's what that error message means" and taking the keyboard. The first teaches. The second produces a better demo but compromises the learning

We found the technical questions were rarely deep. Mostly people needed reassurance that they were on a sensible path, or a nudge in a different direction when they'd gone down a dead end

Plan for the day after

Most hackathons end at the demo. That's the point at which almost all of the value evaporates, because everyone goes back to their real work and the prototypes quietly die

We encouraged people to keep building afterwards and backed that up with build time and group chats. Several teams did keep going. The payroll tax reconciliation tool that came out of the day was used at year end

Oh, and one thing to remember. A prototype in the sandbox is a learning exercise. The moment one touches real client work it carries the same professional obligations as anything else your firm relies on, and the TPB's guidance on AI and the Code is explicit that using AI doesn't shift that. We work under those obligations ourselves

If you want anything to survive, decide before the event who owns the follow-through, and give the people who want to continue some room to do it. Otherwise you've run a nice team-building exercise, 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. Give a short demo of the tools and the starter kit
  • Define. Have small groups or pairs pick their problem and describe it before writing anything
  • Build. Run two working blocks with experts circulating, and a proper break between them
  • Show. Present demos at the end, with leadership in the room
  • Close. Provide a clear message about what happens next

What we'd change

More check-ins during the day. Make sure people have their environment set up with Claude and Git before they arrive. The demos were good, but the interesting part was watching how people worked through problems, and that was mostly invisible to everyone outside each pair. A couple of short mid-day shares would have spread the learning further

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