AI Hackathon
Field Guide↗

1. You can hack much more than code

European AI hackathons can be pretty wild. They are different from hackathons before the AI era, and there is much more to them than coding all night. Here are the main formats:

• Hack Night: A 3–5-hour event, usually built around a sponsor's API or a specified stack. You quickly build a demo, then everyone pitches. Hack Nights tend to suit solo builders and small teams. Understanding the challenge and building quickly matter most. They are a good starting point for newcomers. Bring your own configured coding agent; don't pin all your hopes on the sponsor's free API credits.
• Build Hackathon: The classic format, usually 24–48 hours, with defined tracks, open-ended projects, or both. You go from idea to MVP to a live demo. Larger events attract many teams, so there is usually a demo submission or preliminary judging round before finalists reach the stage. Your submitted demo has to pass that first assessment to earn a live pitch. Competing for the overall final stage while also pursuing side tracks is genuinely difficult.
• Startup / GTM Hackathon: Coding and building an MVP are only the foundation. The focus is market research and taking a product to market: deploying to production, finding users, running ads, generating traffic, signing letters of intent, or even earning your first real payment. These events tend to run longer and judge GTM skills and results. Try them once you are comfortable building and want hands-on GTM practice, ideally with some social distribution capability already in place.
• Themed Hackathon: Focused on a field such as AI agents, voice AI, or climate tech, sometimes with real datasets and APIs. Technology companies, developer communities, and research organizations often host them. Alongside promoting their ecosystem, organizers may be seeking solutions to specific problems or recruiting. Follow these if a particular company or technology interests you.
• Invitation-only Hackathon: Usually for experienced builders or previous winners. Strong competitors, a fast pace, and intense competition. Very exciting.

2. There is more than one prize, and you can stack them

Many European hackathons do not have just one winner.

• Overall Winner: The overall ranking, usually a top three selected from the teams on the final stage.
• Side Track / Sponsor Challenge: A sponsor sets its own challenge, perhaps requiring particular software, models, APIs, or a stack. One project can enter several challenges.
• Wildcard: Some events give extra final-stage slots to promising or distinctive teams outside the regular judging process.
• Final Stage: After initial scoring of submitted demos, finalists give a live demo and pitch. You have 3–5 minutes to explain several days of work, mainly by showing the product and its results. Fewer teams rely on PowerPoint now; opening your landing page and demonstrating the product as you talk is the usual approach.
• You can win both an overall prize and sponsor challenges, stacking cash prizes and credits.

3. Sponsors offer more than prize money

OpenAI, Anthropic, Google, Cursor, Lovable, n8n, Nebius, Entire, SLNG, and many others: events I have attended or followed have involved both large technology companies and startups. Check each event's published sponsor list.

Rewards usually combine cash, API credits, cloud credits, and mentorship. The funniest prize I have seen was breakfast with a sponsor's CEO, haha. Both overall prizes and sponsor challenges can include cash, depending on the organizers and sponsors.

1. Luma: my main source

This is the platform I use most often to find European AI events. Berlin, Paris, Barcelona, Amsterdam, London, and Copenhagen all have plenty of AI hackathons and build nights.

Start by following local AI and startup communities, then follow their organizers to discover more events. It is an efficient approach.

Tip: Following organizers works better than simply searching for hackathons. Many competitions review applications and ask for an open-source project or product, usually alongside a LinkedIn profile. An RSVP does not necessarily get you in. Before your first event, prepare your LinkedIn profile and personal projects.

2. Devpost: the traditional hackathon hub

An established platform with many large competitions, online events, and corporate challenges. A good place for experienced competitors willing to travel across Europe or internationally for prizes and experience.

Rules, prize pools, and sponsor challenges are usually clearly documented, and organizers tend to be professional and experienced. The downside is that small local European hack nights may not appear there, and finding local events takes more effort because discovery is not centered on cities.

3. Meetup / Eventbrite: find local builders

Useful for discovering local developer events. They may not be called hackathons: look for AI Build Night/Day, Agent Jam, or Vibe Coding Session too.

If you are new, start with these smaller events and find teammates there. They are an easier way to gain experience than jumping straight into a large competition.

4. LinkedIn & X: follow indie hackers

Organizers, developer relations teams, and participants often announce events on social media. This is especially true for invitation-only hackathons, which may have no public application page at all.

5. Specialist hackathon organizers: follow them directly

Beyond event platforms, Europe has teams and communities dedicated to organizing hackathons. A few to follow:

• Tech:Europe: An active European AI and startup community that frequently hosts AI hackathons and builder events.
• Hackathon Hub: A hackathon events and developer community platform. Follow its LinkedIn updates for competitions across Europe.
• Hackathons International: Focuses on international hackathons and developer events.

6. Sponsorship: bring support with you

Another useful approach: some AI companies provide API credits, compute, or travel funding for developers using their technology at third-party hackathons.

Contact AI companies directly with the event link, your project idea, and estimated API usage.

Tip: Don't just ask for free credits or travel support. Bring a concrete project to the conversation.

You found an event. Is it worth attending?

• Organizers / Sponsors: Their professionalism and business resources directly shape the experience. Organizers with several years of events behind them tend to be more reliable.
• Format / Tracks: Open-ended or a defined challenge? Build or GTM? Choose product-development events to practice building, and sales hackathons to develop go-to-market skills.
• Judging Criteria: What backgrounds do the judges have? Judges from technology companies and AI sponsors usually bring solid expertise.
• Prize Pool: Cash, credits, or other resources? Hackathon credits have covered a large share of my personal development costs. Some model API gateway providers have been particularly generous.
• Travel Support: Is transport or accommodation covered? Events offering travel support usually have a high bar for entry, and many are invitation-only.

One final lesson:

Join an AI community first, then look for hackathons! I have discovered many good competitions and teammates through community events.

Once you have found a suitable event, the next question is who to enter with and how to build a team that works well together.

1. Who is in the room?

• Students / Researchers: University students, PhD students, and researchers, especially in CS, AI, CV, and NLP. Strong technical foundations and plenty of energy. Many started with university hackathons.
• Software Engineers: Engineers at big tech companies and startups, chased by Jira tickets and sprints during the week, building something they enjoy at the weekend. Many hope to launch their own startup; others are looking for jobs or connections.
• Indie Hackers / AI Builders: They arrive with coding agents and established workflows, and ship fast. Most are hackathon veterans; some already run several products.
• Founders / PMs / Designers: More focused on product, UX, and GTM. Many founders bring a startup idea, or even a finished product, to find technical cofounders or VCs. They are strong networkers, often aiming to meet the investors on the judging panel.
• Serial Hackathoners: Experienced competitors who know the rules, judging priorities, and pitch format. The European AI builder circles I know are closely connected. You keep running into familiar faces in different cities, haha.
• High School Students: The AI startup and hackathon scenes have felt noticeably younger in recent months. At my latest event, a third of the participants were under 20, including many still in high school. One of my teammates was 17. Beyond exceptional initiative and execution, they had excellent product taste and market instincts, with none of the hesitation or embarrassment around GTM. Watching them interview more than 20 passersby on the streets of Sweden in an hour blew me away.
• You will also meet DevRel professionals, VCs, and angel investors looking for projects, recruiting talent, or simply getting to know more builders.

2. Solo or team?

My short answer: a larger team of 3–4 for large events; solo is completely fine for a hack night lasting a few hours.

With AI coding agents, hardly anyone builds everything by hand anymore. It is tempting to think you can do a whole team's work yourself. But after competing solo in my first three events, I learned something: people liked the products, yet without a team, juries either doubted that one person could do all the work or questioned whether the project could continue. I felt this even more strongly when speaking to VCs and accelerators. One VC liked my project but explicitly told me to find a cofounder before discussing next steps. That experience made me pay more attention to a team's ability to work together over the long term.

For 24–48-hour competitions, I prefer a team of 2–3: low communication overhead, flexible responsibilities, and fast delivery. Having a clear decision-maker is essential. Agree at the beginning who makes the final call when you disagree. Otherwise, many teams fall apart while choosing an idea. I have even seen teams break up over models or tech stacks.

A team usually needs to cover:

Engineering / Product / Design / GTM / Pitch

One person can take several roles. Add teammates if the technical challenge calls for it. But you need a strong technical lead, ideally with architecture experience, who can set up the system quickly, manage Git, and review PRs. You don't want the event starting with someone who cannot open a PR or push code. Someone can focus on marketing or pitching, but being able to build with AI and turn documents into an HTML pitch deck is already a basic skill for AI hackathons.

The worst setup is five teammates: three in meetings and two writing code.

3. Where do you find teammates?

• Discord / WhatsApp: Organizers often create participant groups in advance, with #team-formation or #looking-for-team channels. Post your stack and idea, or find a team with an open spot.
• Idea Pitch / Team Formation: Many events arrange team formation after kickoff. Pitch your idea or project in 30 seconds, and interested people join you. An extrovert's paradise.
• Networking: Talk to people at the event or at the meetup the day before a large hackathon. Exchange ideas and stacks; if you get along, build together.
• LinkedIn / X: Contact participants ahead of time, especially active builders and previous competitors.
• AI Communities: Invite builders you have met at other AI events when you find a good fit.

Tip: For short events, form your team beforehand if possible. The cost of figuring out how to work together can really affect your experience.

4. How can you tell whether someone is reliable?

I pay little attention to titles now. I look for:

• Execution: Can they build independently? Do they have personal projects? Can they deliver on time?
• Ownership: Can they solve complex problems independently, or at least use AI tools to investigate and find solutions?
• Decision Making: Are they decisive, direct, quick to commit, and able to work through differences without nitpicking?
• Scope Control: Will they cut features when time is short and focus on what matters, without odd fixations?
• Tech Fit: Do your stacks, goals, and working rhythms match? At minimum, they should know their AI tools and Git.

One more essential point: align your goals beforehand!

Some people want the overall prize. Others specifically want a sponsor challenge. Some just want to try a new API or socialize. When your goals match, revisiting them during a disagreement often resolves the issue.

5. My team formation routine

Before the competition, I spend ten or fifteen minutes aligning four things with teammates:

• Target: Overall prize or side track?
• Scope: What will the final demo show?
• Ownership: Who owns build, design, GTM, and pitch?
• Deadline: When is each deliverable due, and how complete must it be?

Hackathons are too short for elaborate project management. A lightweight PRD is enough; sometimes a paragraph describing the product will do. Don't turn the event into sprint planning unless it lasts a week or two, or longer. The time spent writing a traditional development ticket might be enough for a quick conversation and delivery at a hackathon.

My takeaway: Good teammates >> Fancy tech stack.

With goals and responsibilities aligned, the team can evaluate ideas and plan a strategy around the competition rules.

1. Read the rules before brainstorming

Once you get the challenge, don't immediately open your coding agent and start firing off prompts. Read the rules first. If there are several tracks, I shortlist the ones that fit our skills and interests.

Then we put every candidate idea on the table, score them, and vote.

We often use ICIP, scoring each idea from 1–5 across four dimensions:

• Impact: How significant is the problem? Is the value clear? Will judges relate to it?
• Implementation: Is it technically feasible? Can we build a complete demo in the available time?
• Creativity: Is it fresh? Does it offer something surprising?
• Pitch: Can we explain it in a few minutes? Will the demo be visually compelling?

We combine the scores, select the top 2–3 ideas, and each take one for a quick proof of concept lasting no more than 30 minutes, working in parallel.

Test the core API, technical risks, and demo path, then settle on a direction quickly. Some organizers provide judging criteria and weights. In that case, use the official criteria; there is no need to invent your own.

Tip: Endless brainstorming is the biggest danger here. Set a deadline for discussion, then make the decision.

2. Study the prize pool

This might sound pragmatic, but if your goal is to get on stage and place, remember that many events offer sponsor challenges and side-track awards alongside the overall prize.

I usually research:

• Tracks: Which fit our skills and experience? Crucially, can we show the product effectively in a two- or three-minute demo and possible final pitch?
• Sponsors: Can their APIs, models, or platforms fit naturally into the project? Get familiar with their stack quickly too.

Tip: A project can sometimes qualify for several challenges, improving your chances. But don't force irrelevant APIs or software into it just for another sponsor prize. Tools such as CI/CD pipelines can be easier to combine because most developers need them anyway.

3. Demo value beats feature count

I like ideas with three qualities:

• A specific pain point: One sentence explains why the product is needed. Its audience is clear and reachable. Avoid invented needs.
• Simple interaction: Ideally, people can use it immediately: capture attention in 10 seconds and demonstrate core value in 60.
• An obvious result: It should be immediately clear what goes in, what the AI-powered part does, and what problem gets solved. Show the workflow in the repo or on the landing page.

If your idea has these qualities, you are already halfway there.

Everyone is getting good at coding agents, so building a functional AI app is becoming easier. What makes the difference is product judgment, taste, the demo experience, and, crucially, your ability to demonstrate and pitch it live.

The next step is turning that idea into a product you can build, launch, and demonstrate in two days, or even a few hours.

1. Align on the product before you build

In the AI coding era, PRDs are starting to look like relics nobody wants. One prompt can get development moving. But wishful prompting does not work very well at a hackathon.

When working with a team, I always spend 15–30 minutes aligning on:

• Product Vision: What problem are we solving, and who is it for?
• Core Features: What must the MVP include, and what do we cut outright?
• Demo Flow: How will the interaction work, and which core interaction is most worth showing?
• Tech Architecture: Which stack, how do we divide frontend and backend work, and how do agents, workflows, and APIs connect?
• API Contract: How will modules communicate? What are the data structures?

You do not need a 40-page PRD. A page of Markdown or HTML, or even a whiteboard, is enough. You can also turn on your chatbot's recording mode and let it summarize the team discussion.

2. Bring your technical groundwork

How quickly you build and launch depends heavily on the technical foundation and product/GTM experience you have accumulated. I usually arrive with a proven stack:

• Coding Agent: Claude Code or Codex configured with my skills, rules, and workflows.
• AI Architecture: Established approaches for agent orchestration, LangGraph, agent workflows, RAG, tool calling, and so on.
• Boilerplate: Familiar frontend and backend frameworks, UI components, authentication, and databases.
• Infrastructure: Know your CI/CD and deployment setup in advance. Running on localhost is often insufficient, especially for interactive products and GTM hackathons. Users and judges need access to a deployed product. For straightforward deployments, I recommend Vercel + Supabase or a tool such as Lovable. Don't spend precious build time wrestling with infrastructure.

Tip: Many events I have attended require the competing product to be built during the event. Some allow open-source frameworks, existing technical architecture, and configured coding agents. Check the specific event rules for permissions and disclosure requirements.

Check the actual rules, especially restrictions on prewritten code. But you should not need to research agent architecture from scratch or set up an entirely new CI/CD system at the venue.

3. Build in parallel, know Git, and keep meetings short

The worst team bottlenecks leave everyone waiting on someone else. For a team of two or three, I usually split work by module:

• Frontend / UX: Core interactions, primary product pages, and user experience.
• Backend / AI Agent / AI Engine: APIs, agent workflows, and data processing.
• Integration / QA / Testing: Integration, testing, and deployment. Usually the backend developer handles these too, unless the team is larger or the project complex.
• Product / GTM: Landing page, early market research and user feedback, and pitch pages. I do not recommend preparing a conventional slide deck; a well-designed landing page is the best presentation material.

Tip 1: One person can cover several roles. What matters is clear ownership of each module and an overall technical lead who manages the Git repository and architecture decisions. Let the most experienced engineer own code review. Even if Claude or Codex reviews every PR, you still need someone capable of making technical decisions and checking the work.

Tip 2: Agree on API contracts and data structures first, then work independently and sync regularly. Waiting until the end to integrate is a quick route to integration hell.

4. Time management: deploy early and freeze on time

For a roughly 24-hour competition, I tend to use this rhythm:

• First 15%: Technical validation, task breakdown, and project setup.
• Middle 55%: Core development, integration, and deployment.
• Next 15%: Testing, bug fixes, and experience improvements.
• Final 15%: Feature freeze, pitch preparation, and live demo.

Adjust the proportions to the event. The key is to get an end-to-end product working early. I deploy a dependable baseline as soon as possible, then iterate.

5. Launch before perfection: a hackathon product cannot be perfect

We often say to finish first and perfect later. A one- or two-day hackathon simply cannot deliver a perfect product. At a hackathon in Sweden, my team completed the build, landing page, distribution, and user validation in under eight hours.

Within an hour of posting on Reddit, we received positive feedback from a real user in São Paulo. We had 49 beta signups in eight hours. Chasing perfection at any one step would have slowed the whole chain.

6. Reliability: don't let your demo die at the last minute

This matters a lot to me.

Launching a product only to have it crash during the final pitch, or sending judges a link they cannot open during screening, is painful. Beyond coding, basic product engineering experience helps: testing, validation, deployment, and operations.

My checklist:

• E2E Testing: Walk through the complete real user journey.
• Production Check: Confirm that production behaves like your local environment.
• Logs / Monitoring: Add logging and monitoring while building, so you can locate and fix problems quickly. Don't make AI reread the whole codebase every time a bug appears. Debugging time is especially expensive at a hackathon.
• API Limits: Check credits, rate limits, and model latency. I have seen more than one competitor run out of tokens halfway through a pitch, especially with limited sponsor credits.
• Cross-device: Test on another device and in a private browsing window.
• Fallback: Prepare a demo recording. This has saved me before. Judges usually understand when you switch to a recording after an occasional product stall. Have fallbacks for critical AI calls too, such as alternative models or APIs.

An expired API key, exhausted free credits, or a sleeping database can ruin your event. Nobody cares that it worked on your laptop.

7. Mistakes I have made

• Overengineering: Beautiful architecture, but the core feature still does not work.
• Scope Creep: More and more features, with no center or focus.
• Integration Hell: Every module works alone, but the combined product breaks.
• Localhost Syndrome: Perfect locally, full of errors after deployment.
• Last-minute Changes: Changing core logic just before the deadline and breaking the demo.

I have made every one of these mistakes. I hope my experience helps you avoid them and ship faster.

Once the product is live, the final step is making its value clear through a dependable demo and a focused pitch.

The preceding chapters covered ideas, teams, development, and delivery. This chapter tackles the final hurdle: demo, submission, and pitch.

Most final pitches at hackathons I have attended last three minutes, with occasional five- or two-minute slots, plus two or three minutes of Q&A. Hours or days of development and preparation have to fit into those few minutes.

1. Demo video and live demo: make it work, polish it, then record

You should consider the final demo as soon as you begin designing the product. I plan the demo flow in advance and show only the most important path:

• Wow Moment: Ideally, impress the judges in the first 30 seconds.
• Demo Data: Prepare test accounts, inputs, and scenarios. Don't spend stage time logging in or loading data.
• Live Demo: Demonstrate live when you can. Check network access, permissions, and devices beforehand.
• Fallback: Prepare recordings and screenshots so you can switch immediately if the product crashes.

Tip: AI agents may take ten or more seconds to return a result. Prepare intermediate states and outputs, or plan what you will say while waiting. My trick is to visualize the agent workflow and briefly explain the stack and workflow during the wait, so judges do not spend half a minute staring at a spinner.

2. Submission: don't stumble at the last step

Many organizers collect projects through Devpost, their own platform, or even a Google Form.

Typical submission materials include:

• Project Description: Name, problem, and core features.
• Demo URL: A directly accessible product link.
• GitHub Repo: A repository with the required access permissions. Some technically focused events require a document such as build_log.md.
• Tech Stack: Models, APIs, frameworks, and sponsor integrations.
• Team & Tracks: Team member information, competition tracks, and sponsor challenges.
• Demo Video: Usually one to three minutes, depending on the rules. Record the demo flow you planned earlier.

Tip: Unless the organizer requires a screen-only recording, I strongly recommend recording your camera and screen together, explaining as you demonstrate. Seeing a real person demonstrate a product is much more persuasive than handing a screen recording to AI to turn into a polished launch video. I recommend Loom or Tella: share the link directly, without downloading and uploading to YouTube.

I start a submission draft before recording the demo, then add the video link at the end. If you are targeting a sponsor challenge, check its extra requirements during development. Some require a separate track selection; others require you to demonstrate how you use the API. Discovering this while filling out the final form is too late.

Many events select finalists from submissions. Judges first review your description, demo video, and live URL before deciding who reaches the final stage.

3. Pitch: talk is cheap. Show me your demo.

Most final pitches are three minutes, with a strict cutoff.

When well prepared, I generally use:

Problem → Solution → Live Demo → Impact → Tech

But here is a practical suggestion:

If you have not rehearsed enough, or are unsure about timing, start with the demo as soon as you get on stage. Introduce the product in one sentence, open it immediately, and show its strongest, most impressive feature. Use the remaining time for the problem, technical highlights, and impact.

Being stopped halfway through before showing the most important demo is a terrible waste. I learned this painfully. We once placed third overall after showing only half our demo. Afterwards, a judge told us we could have had a strong shot at first if we had demonstrated the product fully. Such a missed opportunity.

Two useful pitch flows:

• Standard: Problem → Solution → Demo → Impact → Tech
• Demo First: One-liner → Live Demo → Problem → Impact → Tech

Leave more time for architecture in technical competitions. At GTM hackathons, emphasize user feedback and growth data.

When time is short, cut slides, not the demo.

4. Pitch deck / slides: use only what you need

Few events still require PowerPoint. I generally present with a landing page or an AI-generated HTML product overview, covering:

• Problem / Solution: One or two pages explaining the product's value.
• Demo: Switch directly to the product.
• Impact / Traction: User feedback, GTM data, or key metrics.
• Architecture: The core technical approach, especially for sponsor challenges.

A three-minute pitch does not need a dozen slides. Use real product screenshots, architecture diagrams, and data charts wherever possible.

For a complex agent workflow, a clear, possibly animated architecture diagram works well.

5. Delivery: less jargon, more directness

European hackathon judges come from varied backgrounds: engineers, founders, VCs, and DevRel professionals may all be in the audience.

A few things I pay attention to:

• Keep terminology to a minimum except when explaining the stack.
• Use concrete scenarios: Tell judges exactly what problem a user has and how the product solves it.
• Control your pace: Especially when pitching in English. Nervousness makes it easy to speed up. Talking while demonstrating helps regulate the pace.
• Look at the judges: Don't stare at your laptop or read a teleprompter throughout. I have never prepared a script or teleprompter; I rely on the understanding of the product and technology developed while building. Make eye contact with judges, the host, and the audience.
• Rehearse: If presenting as a team, walk through the entire flow together at least once. Confirm roles, timing, the demo, and screen transitions.

Another lesson: ideally, have one main presenter and let teammates support. Consider everyone's feelings and agree in advance. For example, the lead presents the product and demo, while teammates cover the market problem, architecture, or Q&A.

6. Q&A: rehearse the tough questions

Final pitches usually include a few minutes of Q&A. This matters a lot to judges assessing a team's actual capabilities.

I usually run through these questions with teammates beforehand:

• Differentiation: Are there similar products? Why is yours needed? Could a chatbot or foundation model do this directly?
• Technical Depth: What exactly does the AI do, and at which stages? Why this model or architecture?
• Reliability: How do you handle hallucinations, inconsistent outputs, and API costs?
• Business / GTM: Who are your users? How will you acquire them? Do you have real users?
• Sponsor Integration: Where do you use the sponsor's API? Why is it needed? Was it forced in?

Tip: Answer directly first, then explain. Say when you do not know, and don't bluff about features you have not built. If a judge asks a technical or market question, don't turn the answer into a fundraising pitch.

7. A few final lessons

• Before presenting, check browser permissions, microphone, and camera again. Ideally, test your laptop's connection to the large display beforehand. If demonstrating on a phone, you may need to bring your own adapter.
• For voice, vision, and gesture-driven products in particular, changes in equipment and environment can easily affect the result.
• Freeze features before the pitch if possible. Don't break the demo by changing code for one last tiny improvement.

Having walked through the journey from entering an event to presenting a product, one final thought:

The more hackathons I attend, the more I see demoing and pitching as technical skills in their own right. The best part of AI hackathons is the chance to experiment repeatedly and improve your AI skills. Coding agents are bringing everyone's development speed closer together. But competition-tested product communication, live demonstration, and distribution skills are incredibly useful if you want to build an AI startup or a successful independent product. You might even meet the cofounder or angel investor you click with. So go for it, friends. Enter that hackathon.