Corporate hackathon: what the challenge owner must decide before registration opens
A checklist for a corporate track owner: the challenge, data access, judging criteria and the next step after the final.
·6 min read
What you’ll learn
Decisions to resolve before a corporate track opens to participants
An example connecting judging criteria to verifiable evidence
A process for checking the brief, material access and the next step after the final
Teams are already signing up, but the business is still debating which problem to give them. One department promises the data, another writes the judging criteria, and nobody has decided what happens with a pilot. A polished announcement does not close these gaps. Before registration opens, the corporate track owner needs a challenge that teams can test within the event and an agreement with the people whose support they will need.
At Stavleak, we suggest starting with a simple decision: is this track ready to open? That takes a clear brief, available materials and an agreed verification process, rather than forty pages of technical requirements. Here is a practical way to prepare.
Appoint someone who can take responsibility for the challenge
The track owner decides the content: which scenario is required, what falls outside the scope and what change the business actually needs. The coordinator manages published materials and questions from teams. These can be different people, but participants must know whom to contact.
Also name the person responsible for the data and the person who will review possible continuation after the final. If nobody can authorize access or the next experiment, resolve that before the announcement. "We'll introduce you to the right colleague" is not a substitute for an internal agreement.
Do not automatically give the challenge owner every judging role. The domain expert explains the context; projects are assessed against criteria published in advance. Include possible conflicts of interest and the process for handling them in the event rules.
Check that the brief is ready
Work through this list with the business representative, technical specialist and coordinator. For each decision, record an answer or a link to prepared materials. An unanswered item identifies work to complete before registration opens.
Decision: User and situation. Record: Who performs the action, when it happens and what gets in their way.
Decision: Current process. Record: A short sequence of actions before the proposed solution exists.
Decision: Required result. Record: One scenario the team will demonstrate at the final.
Decision: Scope. Record: What is not required: production integration, migration or a complete product.
Decision: Source materials. Record: Files, field descriptions, a sample and access conditions.
Decision: Verification. Record: Input data, the expected result and signs of an error.
Decision: Criteria. Record: What you will assess and what evidence you expect from a team.
Decision: Answers to participants. Record: The channel, responsible person and process for shared clarifications.
Decision: After the final. Record: Who reviews projects, what they check and how they communicate the decision.
The challenge brief guide explains how to describe users and constraints in detail. The owner's task here is different: make sure every item is backed by prepared materials and an agreed decision.
Reduce the challenge to one testable scenario
Consider a task involving duplicate customer requests. "Automate customer service" leaves too many possibilities. A more workable brief asks the team to upload a test file of requests, display possible matches and let an operator confirm or reject a merge.
This is an example for completing a brief. It does not require connecting to the company's production system. At the final, judges can see what happens to a new request, why a match was suggested and whether a mistake can be corrected. Employee authentication, complex reporting and telephony integration remain outside the required result.
Ask the owner to distinguish an acceptable error from a dangerous one. Missing a match and merging records belonging to different people, for example, need different checks. This gives you a meaningful criterion instead of a generic "innovative solution" score.
Check the materials before teams receive them
The person responsible for the data should open the files with the same permissions a participant will have. Check their contents, format and field descriptions, and whether the simplest scenario can be completed. If an external service is needed, test how to obtain access and state its limits before the event.
Specify separately what teams may upload to external tools, keep in their own storage or show in a public demo. Do not make participants guess the data-handling rules. If production information cannot be shared, prepare a safe dataset and explain which properties of the task it preserves.
A backup must also exist before the start. If a service becomes unavailable, that might be a prepared file or an agreed demo mode. Teams need to know what will be accepted in that situation and how judges will account for the limitation.
Connect criteria to evidence
For each criterion, write down what judges can actually check within the available time. For the customer-request example, that looks like this:
Criterion: Match detection. Evidence at the final: Results on test examples agreed in advance.
Criterion: Explainability. Evidence at the final: The team shows the features that led to a suggested merge.
Criterion: User control. Evidence at the final: The operator rejects an incorrect match without losing the original records.
Criterion: Limitations. Evidence at the final: Participants identify cases the solution still handles poorly.
Do not introduce a hidden criterion after the demonstration. If the business wants to assess operating costs or a mandatory integration, the conditions must say so. A requirement introduced at the final changes the competition after teams have done the work.
Run a short readiness check
Before opening the track, give the brief to someone who was not involved in the discussion. Ask them to identify the first step, the required result and the verification method. Next, the technical specialist checks access to the materials. The coordinator compares the brief with the submission form, schedule and judging criteria.
If the answers differ, return the document to its owner with a specific question. If a resource is inaccessible, assign someone to fix it and set a deadline. Open the track after resolving gaps that would prevent teams from starting or judges from assessing the work fairly.
After the final, compare projects with the original challenge and choose the next testable step. Winning does not by itself establish readiness for deployment. A pilot needs its own owner, resources and conditions.
Want to host a corporate hackathon on Stavleak? We can run the event for you, help with selected stages or provide the event workspace for you to organize it yourself. If you currently need a starting pack, open the organizer materials: you can begin with the rules, checklist and judging criteria.
