How to Run Your First Internal Hackathon: A Decision Guide

In the first half of 2026, requests for internal hackathons made to AngelHack jumped over 350% compared to the whole of 2025, and most start in the same place. A company wants to lift AI adoption across its workforce, decides a hackathon is the way to do it, but does not have much idea how to plan and run one that works.

At AngelHack, we usually advise clients looking into an internal hackathon to work through six critical questions before anything else. Answering them gives a much clearer picture of what the hackathon will actually look like, and it makes the rest of the planning considerably easier.

What is the main goal of your internal hackathon?

The goals set your metrics, your executive sponsor and the shape of your challenge statement, so it is the first thing to settle.

Purpose	Typical goal	Program built around	Usually owned by
Innovation	Usable prototypes and new use cases	A specific business problem	Innovation or product lead
Learning	Confidence with new tools	Hands-on practice and support	L&D or talent
Adoption	Daily use of a specific tool	The tool itself, in real workflows	IT or the tool owner

Questions to consider

Innovation, learning, or adoption? Innovation means prototypes solid enough to take into review, learning means people who can use the tools in their own work, and adoption means a platform in daily use.

What business problem or skill gap does it feed? State it in one sentence and the challenge statement almost writes itself.

Who owns the outcome after demo day? Ideally one person with a budget, since follow-through depends on someone authorizing the next step without another round of approvals.

🌟 Our advice

• Pick one primary goal and let the other two be side benefits, so the criteria, the challenge and the metrics point the same way.
• Match the scoring to that goal. A learning event judged on commercial viability can leave beginners with nothing to show.
• Name the sponsor before the announcement, so winning ideas have somewhere to go from the start.

Who is taking part in the internal hackathon, and what can they build?

Your audience sets the challenge design, the support level and the length of the day. Skip it and the common outcome is a brief pitched at the wrong level, where experienced builders drift away and beginners spend the day stuck on setup instead of building.

Questions to consider

Technical, non-technical, or mixed? A technical audience can handle challenges that involve coding, and can work to shorter timelines. A non-technical audience needs a lower bar, more mentors and a worked example of a finished submission.

How do we assess skill level beforehand? Ask about tools already used, comfort level and training completed. Those signals sort a non-technical group better than a seniority field.

Voluntary or expected? Voluntary skews toward people already interested, which lifts quality but shrinks reach. Expected widens reach and needs manager sign-off first.

🌟 Our advice

• Run a short pre-hackathon survey to assess skill level and comfort with different types of challenge, so you size the mentor pool and the difficulty from real signals.
• Set the build bar from what your least experienced team can finish and demo. If the survey shows a roughly even split, run a beginner and an advanced track so people can join the one they are comfortable with.
• Put at least one person with prior tool experience on every team, so no group loses the morning to setup problems.

How do you design the internal hackathon challenge?

The challenge statement decides what teams build, how you score them, and whether anything usable comes out by the end of the program. A good statement names a real problem and leaves the approach open, so teams could answer differently and still stay on brief. A weak one either names the technology without the problem, or specifies the solution so tightly that every submission looks the same.

Questions to consider

How open or narrow should the challenge be? Narrow keeps submissions comparable and gives beginners a clear starting point. Open produces more variety and suits audiences who already know the problem well.

What tools will be used? Non-technical audiences usually work with what is already licensed, such as Microsoft Copilot or ChatGPT, plus a no-code builder like Power Apps or Zapier. Technical audiences tend to bring their own tool suite.

How long should the hackathon be? One day suits most first internal hackathons, with 24 to 48 hours for technical audiences.

What are the judging criteria? Four or five criteria, typically: problem fit, working demo, business impact, feasibility and pitch clarity, with the weighting shifting by purpose. Publish at kickoff so teams can aim at them while they build.

🌟 Our advice

• Run one challenge for a first event and name the constraint inside the theme, so teams solve the problem instead of inventing one.
• Introduce the tools before the event so nobody spends build time working out the basics, and have mentors demo the strongest use cases and features on the day.
• Communicate the judging criteria clearly in advance. Honorable prizes for most creative, best pitch and best teamwork spread recognition beyond one single winner.
• Fix the pitch format to problem, solution, live demo, expected impact and next steps in three to five minutes, which keeps judging consistent.

How do you get people to join the internal hackathon and finish?

Sign-ups are harder than they look unless attendance is mandated. People have to give up a full day of their own workload to join, and it depends on whether people really find the hackathon relevant and helpful to their actual work.

Questions to consider

How do we get people invested in the hackathon? Show the challenge early, name the problem it solves for each function, and make clear what participants get in return, from prizes to recognition.

Who approves the time? Line managers, and they need to hear about it before their teams do.

Is the day protected? Where it sits on top of a normal workload, the gap between sign-up and submission tends to widen, often losing the functions you most wanted in the room.

What do participants need beforehand? Tool access, the challenge statement, and enough familiarity that the start of the day is not spent reading documentation.

🌟 Our advice

• Check that the challenge reads clearly to every function taking part, and that solving it would remove real frictions in their work.
• Brief line managers first and open registration afterwards, so everyone signing up already has permission to be there.
• Send resources one to two weeks ahead: tool guides, prompt examples, the challenge and two or three sample use cases.
• Keep it all in one participant guide, because scattered emails make it likely that part of the room arrives without access to something.

Which resources do we need to run an internal hackathon?

Almost all of the work sits in the two to four months before the event, covering challenge design, platform setup, comms, judge briefing and access clearance. Five aspects shape how smoothly it goes:

• Budget is driven by scale, format and support level, and the planning months are where most of it goes.
• Platform handles registration, submissions and judging, and needs to work cleanly across all three.
• Mentors and judges come from inside your organization, usually experts in their respective fields.
• Staffing splits three ways: run of day, platform, and participant support.
• Logistics depend on format. Virtual needs a comms cadence and support channel, on-site adds venue, power and wifi, catering, check-in and AV.

Questions to consider

Where do judges and mentors come from? From inside your organization. We brief them and run the comms, but the panel is yours, and a non-technical company often needs to look beyond IT.

Do we have the bandwidth? Single-site and single-theme with one owner is realistic in-house. Multi-site, multi-track, or an event nobody on the team has run before is where the planning load starts to outgrow the day job.

Do we need outside help? Some teams need extra hands and infrastructure to deliver it. Others have the people but not the expertise, and want an experienced partner like AngelHack, who are already familiar with the format.

What are the fallbacks if something slips? Access issues, a judge dropping out and a platform outage surface most often, and each is worth a named owner.

🌟 Our advice

• For in-person hackathon, confirm the venue’s wifi and electricity capacity can carry everyone building at once, and prepare a contingency plan for both. 
• Walk the platform end to end before the event, from sign-up through submission to judging, so friction surfaces while there is still time to fix it.
• Brief mentors to coach and unblock rather than build, which keeps the work with participants.
• Model your own numbers with our hackathon budget calculator before committing to a format.
• Reach out to vendors early, so they have enough time to plan and prepare their services accordingly.

How do you measure internal hackathon success?

Set your metrics before the announcement. Confidence levels and current tool usage in particular need measuring beforehand, because both are comparisons and you cannot recover the starting point afterwards. Other metrics follow the purpose you picked at the start:

• Innovation: submissions received, prototypes completed, ideas taken to review, pilots started, funding committed.
• Learning: registration against attendance, completion rate, confidence scores before and after, people still using the tools 30 days later.
• Adoption: active users at 30, 60 and 90 days, license utilization, workflows automated, time saved as estimated by teams.

Questions to consider

What number will leadership ask for later? Usually participation rate against headcount, completion rate, use cases generated, estimated time saved, and ideas progressed to a pilot.

What happens to the winning submission? Name who reviews it, who funds it and who builds it, because a prototype with no owner tends to stop moving.

How do we get immediate, in-depth feedback from participants? Collect it in the room before people leave, keep the form under two minutes, mix rated questions with two or three open ones, and make one channel anonymous.

🌟 Our advice

• Collect the confidence baseline before the event, or the learning outcome ends up with no number attached to it.
• Name the review, funding and build owners before demo day, so the gap between the last pitch and the first follow-up stays short.
• Publish the follow-up route to participants ahead of time, which can lift the standard of submissions.
• Send a feedback survey immediately after the event, then again at three to six months to measure how much skill and tool adoption held.

UBS Bank ran its internal hackathon with 500+ employees across New York, London, Zurich, Singapore and Hong Kong. Winning teams pitched to UBS executives, and the top ideas received funding and a place in a post-program accelerator. Deciding the route before the build is what turned winning submissions into deployed solutions.

At a glance: the six decisions

Decision	Aspects to consider	Questions to answer	What it decides
What are the goals?	• Innovation, learning or adoption • Sponsor ownership and budget	• Which purpose? • What problem or skill gap? • Who owns the outcome after demo day?	Result metrics
Who is taking part?	• Technical, non-technical or mixed • Skill signals at registration • Voluntary or expected	• Who is in the room? • How do we assess skill level? • Is attendance mandated?	Program planning
How do we design the challenge?	• Challenge scope • Team size and formation • Scoring criteria and event length	• One challenge or tracks? • Who forms teams, and how big? • What are we scoring, over how long?	Program planning
How do people join and finish?	• Manager approval • Protected time • Pre-event resources	• Who approves the time? • Is the day protected? • What goes out beforehand?	Result metrics
What do we need in place?	• Tooling and IT clearance • Platform scope • Budget and lead time • Internal bandwidth	• Where do judges and mentors come from? • Can we run it in-house? • What are the fallbacks?	Program planning
How will we know it worked?	• Metrics by purpose • Baselines collected in advance • Deployment limits	• What will leadership ask for? • What happens to the winning submission? • What can we deploy internally?	Result metrics

Once the six questions are settled, our AI internal hackathon playbook takes you through the execution side: building the run of day, briefing mentors and judges, managing submissions, and handling what comes after demo day.

Run your first internal hackathon with AngelHack

We have run hundreds of programs over 15+ years, with a community of 500,000+ developers behind them, and every one is designed around the client’s purpose and audience rather than a template. Take the full build, from program design through to post-event follow-up, or just the parts your team cannot cover.

Tell us the outcome you are aiming for and we will design the program that gets you there. Book a consultation and we will map your six decisions with you, then send back a program outline and budget that matches your needs.