Hackathons Playbook

Two layers on purpose

playbook.md is the checklist and sources/ is the archive, and nothing crosses between them by accident. Each source gets one file named after the piece and its author. It opens with the link, the author, the date it was added and a one line summary, then keeps the raw takeaways in the source’s own structure rather than mine. Nothing is ever deleted from a note. Only the points that are useful and not already covered get folded into playbook.md, filed under the phase where that decision actually gets made. The checklist stays short and every line in it stays traceable.

What the playbook covers

Eight numbered sections, ordered by when you need them. Mindset opens, on the argument that curiosity and a genuine desire to build are the whole game and the rest is mechanics. Getting the idea follows: talk to sponsors first, work problem first rather than solution first, mine your own pain points, and do not force originality. Planning is about defining the exact demo flow up front and prioritizing visual impact over technical depth. Implementation covers splitting frontend from backend, mocking peripheral APIs but never the core, and keeping main working while risky work sits on a branch. The demo section is the longest, because that is where the result is decided. Team and logistics close it.

The default stack

The last section is a table of defaults, and it exists so that the first two hours do not go into setup arguments.

These are not claims about the best tools. They are picks that start quickly, deploy quickly, and are familiar enough that nobody reads documentation at two in the morning. Any of them can be swapped. The point is that a swap should be a decision rather than the resting state of the repository.

Choices and their cost

• Two layers instead of one file. A checklist with no provenance is only as trustworthy as whoever wrote it, so every line stays traceable to something I can reread. The cost is a second file to write for each source.
• The playbook is opinionated rather than balanced. It takes a position, for example that a team of two or three beats a team of four, instead of listing considerations. That makes it usable at midnight and wrong for some events.
• Advice is filed by phase, not by source. Someone asking what to do next finds it in one place. The cost is that a single source ends up scattered across sections, which is exactly why the notes stay whole in sources/.
• Nothing is removed from a note, even when the playbook rejects the point. Rejected advice is the useful part later, when I want to know why I decided against it. The cost is that sources/ grows without limit, which is fine, since nobody reads it end to end.

Where it stands

sources/ currently holds one note, taken from a write-up on winning hackathons published on the browser-use blog. So the playbook today is one careful piece of reading plus my own retrospectives, not a survey. It is opinion with citations rather than evidence. Nothing in it is measured, and none of it is anything more than Markdown: no site, no tooling and no automation. New material enters by hand in the same four steps every time. Capture the note, compare it against what is already there, fold in what is new, then edit for length. The repository is open source under the MIT licence.