Hackathon dry run: test the path from signup to judge
Rehearse registration, team entry, submission and judge access with a practice project, then repeat the full route after fixes.
Stavleak Team · Updated October 7, 2026
The application went through. So did the project. Yet the judge’s list is empty. Find that break before the event starts: have a colleague go through the hackathon from registration to submission while you still have time to fix things.
In brief
A hackathon dry run rehearses the participant journey using test data. One person registers, finds the task, joins a team and submits a project; another opens it with judge access. Record the expected result, failure and owner at each hand-off. After fixes, repeat the whole journey, not just the broken button.
What exactly should you test before the hackathon?
Take one simple practice submission: a title, description, link and file in the formats your rules require. You do not need to develop anything for the rehearsal. What matters is taking that package through the event’s actual steps and seeing it from the assigned judge’s side.
MLH’s judging plan explicitly recommends testing the system in advance by having organisers act as mock judges, and planning for data backups. Below, we suggest extending this check to the full participant journey. The following scenario is an editorial suggestion from Stavleak, which you can use as the basis for a rehearsal.
Agree on a test environment: a separate event, if the platform supports it, or an organiser’s test that will not enter the real results. Mark the practice team and submission clearly. The person following the journey should use ordinary participant access: administrator permissions can easily hide an error.
Who acts as the participant, and who observes?
Ask a colleague who did not configure the forms to be the test participant. Give them only the instructions a newcomer will receive. If they ask where the task is, do not immediately point it out. Record where they lost their way.
A second person observes and keeps a short log. A third checks the submission with judge access. In a small team, people can take turns in these roles while keeping separate accounts and permissions. Appoint one coordinator to collect the issues and organise the repeat check.
How do you follow the journey from application to judge?
- Registration. Submit the form. The participant should understand whether their application was received, whether approval is needed and what happens next. Failure: the form closes without a clear result. Owner: registration coordinator.
- Task. Find the current brief and submission deadline using the route described in the invitation. Failure: the email contains one version of the task and the page another. Owner: track lead.
- Team. Follow the intended process for creating or joining a team. Compare the membership shown to the participant and organiser. Failure: someone believes they have joined but is missing from the team. Owner: team coordinator.
- Submission. Send the practice project and find confirmation that it was accepted. Failure: only a draft was saved, or a required file was rejected. Owner: submission coordinator.
- Judging. The assigned judge opens the project, materials and criteria. Failure: the project was submitted but not assigned, or its link requires access the judge does not have. Owner: judging coordinator.
For each entry, record the time, expected and actual behaviour, and a link or screenshot. “Submission is broken” starts a conversation. “After uploading the file, the participant still sees a draft; the judge cannot see the project” already helps locate the specific break.
Which errors should you introduce deliberately?
After completing the journey successfully, try submitting without a required field and with an unsuitable file. The participant should understand why it was rejected and how to fix it. Then check the link from a judge’s account: the author having access does not mean the reviewer has it.
Test the deadline passing separately in the agreed test environment. Compare the time shown on the page with when submissions actually close, including the time zone. Do not change the live deadline for this exercise. MLH recommends clarifying deadlines, submission formats and judging procedures in advance. A rehearsal shows whether those statements match the settings.
When is the check complete?
When the practice submission has reached the assigned judge, every break found has been fixed and the full journey has been repeated from the beginning. “Sent to the developer” means the issue is still open. Record its owner, deadline and who will confirm the fix.
Keep the log and the accepted submission package. They will help the support shift see what a successful submission looks like and where to send a similar issue. Carry out additional physical and digital accessibility checks based on participants’ agreed needs.
Preparing an event? Start with the Stavleak organiser workspace. Set up your journey and take a test team through it before inviting participants.
FAQ
Can we check everything from an administrator account?
An end-to-end dry run needs ordinary participant and judge roles. An administrator may be able to see materials those people cannot access.
Do we need a real finished project?
A clearly marked practice package that meets the submission rules is enough. You are testing the route the materials take, not the quality of the development work.
We fixed one error. Do we need to start again?
Repeat the full journey: a change to a form, approval or assignment can affect the next step.
Sources
- MLH: Judging Plan — mock judging and data backups.
- MLH: Rules for Your Hackathon — clear submission and judging requirements.
- Stavleak for organisers — roles, teams, projects and judge assignments.
This article was prepared with AI assistance; its links and recommendations were checked.
