Open-Source Format
How to run a Bio × AI hackathon in your city. A specific format, tested in Berlin.
Section 1
The principles behind the format.
Companies provide real unsolved problems, domain expert mentors, and (in many cases) prizes. Some provide proprietary data, others define open-ended research challenges. Either way, participants work on problems that actually matter.
Challenges should be:
Required for listing. This is the single non-negotiable requirement for being listed as an official European Bio × AI Hackathon edition.
Plan for at least about half of participants to come from outside the host city. Budget ~€300 per non-local participant for travel reimbursement. This is what turns a local meetup into a European event.
Without travel grants, you're running a local hackathon, which is great — but it's not this.
Teams mix bio/health people with computational/AI people. The application process should select for this diversity, and team formation should encourage these combinations.
Accept both pre-formed teams (up to 5) and solo applicants. This is an important feature of the format, since it supports both existing teams and new team formation.
Pre-formed teams don't need to break up — a pair of collaborators, a lab group, a startup team can all apply together. Smaller teams should be encouraged to add individuals from the accepted pool. Individual applications matter just as much: a motivated biologist in Lisbon or a strong ML engineer in Warsaw shouldn't need to already know someone to participate. This is especially important for an interdisciplinary, Europe-wide event where many applicants won't already have a team.
After acceptances, connect all accepted participants in one place (e.g., a shared platform with profiles) so they can find each other and form teams themselves before the event.
24-hour hack → public evening showcase. The hack is closed and focused. The evening is open to the broader ecosystem — VCs, scientists, founders, industry. Participants get deep technical time and public visibility.
Participants should have access to the venue for the full 24 hours. No one should be forced to pack up and leave at midnight — that kills momentum. The venue stays open the whole time. See the Venue section for detailed guidance on layout, breakout spaces, and setup.
Building impressive tech is only half the battle. Teams are judged not just on code complexity or architecture, but on why it matters. Judges should look for context: not just how your tool works, but what problem it solves and for whom.
Things teams should be thinking about:
The "So What?" test: If this existed today, how would it change a scientist's, a clinician's, or a patient's daily life? If you can answer that clearly, you have a translational project. Build for the world, not just the terminal.
Section 2
Four partnership types. But first, some notes on planning.
Start early. Challenge partners should be your first priority — they define the hackathon. Start outreach at least 3 months before the event, especially if you don't already have strong connections in relevant industries. These conversations take time: you're asking companies to commit real problems, mentors, and judges.
After challenge partners are locked in, prioritize:
General sponsors and operational partners are important but more flexible on timing — you can often close these closer to the event.
The most important partnership. One per track (typically 3 tracks). Prioritize challenge quality over sponsorship amount, because the strength of the problems is what makes the hackathon work. Tailor the package to each partner's size and situation; a startup contributing a great challenge and no funding or maybe €2K is worth more than a mediocre challenge at €15K.
We used a Bronze / Silver / Gold structure, but the specifics should be tailored to each sponsor's needs and what they care about. These are a starting framework, but agreements should be individually negotiated. Amounts will depend on your city, costs, and the partners you're working with — as a starting point, you could go with €3K / €5K / €8K or €5K / €8K / €10K.
Branding. Logo on materials, social media mentions, spots at the showcase.
Branding + access. Everything in Bronze, plus access to participants and teams, intros, dedicated social media.
Branding + involvement. Everything in Silver, plus participation in the program (eg as a judge, speaker, or with a booth at the public showcase).
In-kind support: venue, catering, snacks, drinks, or other logistics. In return they get event branding, social media, and spots at the showcase. Scale the recognition to match the contribution.
Section 3
You'll likely need two separate spaces: one for the hack itself, and one for the public evening showcase. These have very different requirements.
The hack venue needs to support 24-hour access — participants should be able to stay and work through the night without being forced to leave. This is non-negotiable; packing up at midnight kills momentum.
Layout matters as much as capacity. You need a central area large enough for everyone to gather — kickoff, meals, announcements — but teams also need space to spread out. In Berlin, having multiple smaller rooms available as breakout spaces made a big difference. Ideally, each team gets a small room to themselves, or larger rooms are shared between 2–3 teams with enough space that they don't disrupt each other. Teams need to be able to talk out loud, brainstorm, and debate without worrying about disturbing the team next to them.
Plan for capacity of 80+ people, with enough breakout rooms or flexible space for all teams to work comfortably.
Tip: Make sure whiteboards are available — teams consistently use and appreciate them for group brainstorming and planning. A few portable whiteboards or even large paper pads across breakout rooms go a long way.
The evening showcase is a different kind of event — it's public-facing, with 200–300 attendees from the broader ecosystem (VCs, scientists, founders, industry). This usually calls for a different venue than the hack space: you need a stage setup for finalist pitches, space for networking, and capacity well beyond the hackathon participants themselves.
It's possible to use the same venue for both if it's large and flexible enough, but in practice, most hack-friendly spaces (university rooms, coworking spaces, labs) aren't ideal for a 200+ person evening event with a stage. Plan accordingly.
Section 4
The Berlin edition ran three tracks (we'd probably recommend 2 or 3, maybe 4 if you're going to have significantly more than 75 participants). You can take this as a starting template, but adapt based on your partners and local strengths.
Important — do not reveal challenges early. The track titles and challenge partners are announced ahead of time (so applicants know what broad areas they're signing up for), but the specific challenge details must stay secret until the kickoff briefing on the day of the hackathon. No early access for anyone; everyone receives the challenge at the same time. This is essential for a level playing field and is a core principle of the format.
Predicting function from sequence, designing proteins with novel or optimized properties beyond natural evolution.
Understanding non-coding DNA, designing synthetic DNA sequences for controlling cell-type-specific expression, decay, and more.
Building agents for scientific discovery, lab automation, healthcare. Accessible to strong computational participants without deep biotech backgrounds.
Worth considering: Making at least one track accessible to people who are strong computationally but don't have deep biology backgrounds. It widens the talent pool and the cross-pollination is real.
Section 5
Mentors: Invite additional domain experts (beyond the challenge partner reps) to be available on Day 1 evening to help teams with their approach. On Day 2 late morning/midday, have a VC or experienced pitch coach available for a few hours to help teams prepare their presentations.
Both rounds use the same judging criteria. The difference is the judges and the format.
Afternoon track evaluations: Challenge partner representatives (or other domain experts) serve as judges, since they understand the technical depth. All teams pitch: 5-minute presentation + 5-minute Q&A. Track winners and the top 3 finalists from each track are selected here; the finalists advance to the evening showcase.
Evening showcase: Separate panel of external judges (VCs, scientists, industry leaders — not the same people as afternoon). Finalist teams give a 5-minute pitch only, no Q&A. Overall winner selected (can be any of the finalist teams; may or may not also be a track winner).
Each pitch should cover:
These are generalized from the Berlin edition. Each challenge partner may tailor the specifics to their track, but the core categories should stay consistent.
How well-engineered is the solution? Are custom pipelines, models, or workflows integrated effectively? Does it demonstrate real understanding of the underlying tech?
Is the rationale compelling? Does the approach actually address a real need — or is it a cool tool in search of a problem?
How sound is the evaluation strategy? Are there sanity checks, clear metrics, and a credible plan for testing whether the solution actually works?
Could this become a product, platform, or research direction? How broadly does the approach generalize, and is there a plausible path forward?
Challenge partners may adjust the specific wording for their track (e.g., a protein design track might emphasize biological rationale; an agentic AI track might emphasize creativity). The four categories and equal weighting should stay consistent across tracks.
Tip: Have all teams submit their decks at 16:00 in the same format (e.g., Google Slides). This makes it much easier to quickly combine the finalists' decks into a single presentation for the evening showcase, since you'll have to do this between 17:00-18:00 once you know the finalists.
Section 6
Allow both pre-formed teams and individuals to apply. This is important — it means people don't need to already know others in the space to participate, which is especially relevant for an interdisciplinary event. Every team member must submit their own application (evaluated individually, accepted together). Small pre-formed teams should be encouraged to add members from the accepted pool.
These are the actual questions from the Berlin edition application form. Adapt to your tracks and context.
Applicants are accepted directly into tracks. Since you need to roughly balance the number of participants per track, applicants who select multiple tracks of interest may be assigned to one based on capacity and fit.
For Berlin, we had a panel of ~10 reviewers evaluate applications — important that decisions aren't made by just 1–2 people. We plan to open-source the tool we built for this (panel-based scoring and admission by criteria) at a later point.
Section 7
This is THE key differentiator that makes it a European event, not just a local one. Plan for at least half your participants to be non-local.
Hackathons typically default to pizza and junk food. We'd strongly encourage providing balanced, real meals instead — especially for participants who are staying up all night. It makes a noticeable difference in energy levels, focus, and overall wellbeing. People who are coding and problem-solving for 24 hours straight need proper food, not just sugar and caffeine.
Plan for more food than you think you need. For a Friday afternoon → Saturday evening format, you're looking at:
Keep snacks available throughout the entire hack — not just at mealtimes. Coffee should be flowing at all hours, and Club-Mate is highly recommended.
Section 8
Challenge partners can offer track-specific prizes. For overall prizes, consider a mix of cash and resources that support continued development — compute credits, seed grants, investor intros, lab access, conference tickets.
One thing to keep in mind: winning teams at a Europe-wide hackathon are often distributed across multiple countries, which makes location-specific prizes (like lab access in one city) less useful than you'd think. Cash and remote-friendly resources tend to be the most universally valuable.
We're still iterating on the best prize structure. Reach out if you want to compare notes.
Section 9
What we used for the Berlin edition. All worked well.
| Landing page | Static HTML/CSS/JS via GitHub |
| Email signup | Tally (embeddable forms) |
| Public event page (evening showcase) | Luma (here's a link to the Berlin evening showcase as an example) |
| Mass email | Mailchimp |
| Applications | Tally or similar form tool |
| Team formation | Shared platform for participant profiles — still iterating on best tool |
| Reimbursement | Tally |
| Participant comms | WhatsApp community |
| Pitch decks | Google Slides (same format for easy combining) |
Section 10
Approximate numbers for a ~75-participant edition. The biggest line items are travel grants, venue, and catering.
| Travel grants | ~€10,000+ | ~€300 × number needing grants (Berlin: ~35 people) |
| Venue | Major cost | 80+ hack space + 200–300 showcase space |
| Catering | Major cost | Meals + snacks for 24h + evening event |
| Photo/video | Smaller cost | Photographer + videographer |
| Prizes | In-kind | Often covered by partners |
| Compute | In-kind | Compute partner |
| Total | ~€40,000–50,000 | Varies by city |
Section 11
Coming soon — guidance on visual identity, naming conventions, and how to maintain consistency across editions while leaving room for local flavor.