The Buildathon Operating System: Brief, Teams, Judging and Follow-through

A buildathon works when a temporary room produces something that can continue in the permanent organisation. That requires more than an agenda. It needs an operating system: decisions, roles, boundaries and hand-offs that connect the brief to the work after the event.

This is the version I would use as a starting point.

The operating sequence

1. Define the change the organisation needs.

2. Select owned problems with evidence.

3. Prepare tools, data, access and safety boundaries.

4. Form teams around complementary roles.

5. Build in short cycles with visible checkpoints.

6. Demo the working path and the failures.

7. Judge against the original objective.

8. Hand over ownership, decisions and next tests.

9. Review continuation after one week and thirty days.

1. Write a brief that can produce a decision

The brief should fit on one page. It names the user or workflow, current friction, desired change, constraints, available evidence and accountable owner. It also says what is out of scope.

• Situation: what happens now?

• Objective: what should be observably better?

• User: who experiences the problem?

• Evidence: what supports the claim?

• Boundaries: data, security, policy, time and platform constraints.

• Output: what must be demonstrable by the end?

• Owner: who can make the next decision?

If the brief cannot support a decision, the event will produce ideas without a destination.

2. Select problems, not pitch topics

Use a short intake before the event. Reject problems that are purely inspirational, depend on unavailable data or have no owner. Combine duplicates. Aim for a portfolio with different workflows but similar enough infrastructure that mentors can help.

A strong candidate is frequent, painful, bounded and testable. It does not need to be glamorous.

3. Prepare access and safety

Run a technical rehearsal. Confirm accounts, permissions, repositories, APIs, model access and analytics. Decide whether teams will use synthetic, anonymised or approved production-like data.

• Publish an approved-tool list.

• Name prohibited data and actions.

• Keep secrets server-side.

• Prepare test accounts and sample data.

• Define who reviews authentication, database access and external calls.

• Create a fallback for every critical dependency.

4. Form teams for the work

Do not form teams only around technical seniority. A useful team has problem knowledge, product judgement, building ability and somebody willing to test the result. Four or five people is usually easier to coordinate than a large group.

Make roles explicit without making them rigid: problem owner, builder, tester, evidence lead and storyteller. People can hold more than one role.

5. Build in cycles

Use the same loop throughout the day: situation, objective, build, review. The problem may change as the team learns; the procedure stays visible.

• Checkpoint one: can the team explain the user and the core path?

• Checkpoint two: does one thin vertical slice work?

• Checkpoint three: have success, failure and recovery been tested?

• Checkpoint four: is there evidence for the final claim?

Mentors should ask what the team is trying to prove before suggesting another feature.

6. Demo the work, not the deck

Each team shows the real flow. The demo includes the problem, the working path, one important failure or compromise, evidence collected and the next test. Limit slides so the product has to carry the story.

7. Judge what matters

• Problem clarity: is the need real and understood?

• Usefulness: would the proposed change improve the workflow or user experience?

• Working evidence: can the team demonstrate the core path?

• Learning: did the team test assumptions and respond to failure?

• Safety and feasibility: are data, access and operational risks understood?

• Continuation: is there a credible owner and next step?

Do not let visual polish dominate the score. A beautiful interface attached to an unowned problem is not the strongest outcome.

8. Close with decisions

Before people leave, classify every project: continue now, run a specific test, preserve the learning, or stop. Record the owner, next action, required support and decision date.

Share one concise record per project rather than a folder of presentations. Link the brief, build, evidence, risks and decision.

9. Review at one week and thirty days

After one week, remove blockers and confirm the next test happened. After thirty days, review what was used, changed, integrated or stopped. Feed the patterns into the next brief and the organisation’s approved ways of working.

The facilitator’s control panel

• Time remaining and current checkpoint.

• Teams blocked by access or decisions.

• Mentor coverage and repeated questions.

• Projects touching sensitive data or high-impact decisions.

• Owner and next-step completeness.

• Evidence captured for the final review.

What to reuse

Reuse the intake form, brief, security checklist, team roles, event plan, judging rubric and follow-up record. Do not reuse last time’s problems without checking that they still matter.

This operating system brings together the practical guides on what an AI buildathon is, how to avoid theatre and how buildathons support adoption.

I also teach the format in How to drive AI adoption with a buildathon. For a tailored version, talk to CraftingProduct.