What a hackathon brief needs: the user, current process, data, constraints, expected outcome, judging criteria and answers for teams.
·5 min read·
A hackathon brief should let a team start work without guessing what the organization wants. It needs a user, the current situation, available resources, constraints and an outcome that can be presented at the final. If teams have to find this information through private messages, they start with different conditions.
Identify a challenge owner within the organization. This person is responsible for the content and approves changes. Separately, appoint someone to publish answers for participants. An expert may know the subject well but have no time to monitor a chat around the clock.
Describe the current process
Start with a specific process. Who receives a request, what do they check, which tool do they use and where do they pass the result? Where does a delay or error occur? Give an example that can be discussed without revealing confidential information.
An example for practice: "A coordinator receives consultation requests from several forms and manually looks for duplicates using contact details. Propose a way to merge repeated requests while preserving the original records." The user, action and constraint are already visible here.
Do not estimate the scale of the problem unless you can support it. Instead of "thousands of employees lose hours every day," describe the established process and separately state which measurements you have. If there is no data yet, ask teams to test a hypothesis rather than prove an effect announced in advance.
Define the expected outcome and its scope
Specify what will be accepted at the final: a working prototype, research, a mockup, a set of experiments or a hardware demonstration. If a concept is enough, do not suddenly judge the quality of production code. If the project must run, describe the environment and access procedure.
Define the required scenario. For the request example, this means uploading the source file, finding possible matches and viewing a merged record with a way to check where it came from. Export, calendar integration and messaging can remain optional features.
State what is outside the challenge. Teams benefit from knowing that they do not need to migrate an entire internal system or connect to a production database. These boundaries reduce unnecessary questions and help compare solutions with the same scope.
You can start the document with the Stavleak partner challenge brief template: fill in the current situation, outcome and constraints, then download a DOCX for approval.
Prepare the data before the event opens
For each dataset, describe its source, structure, format, size and known limitations. Include a small example that opens without special access. If real data is unavailable, provide an approved anonymized or synthetic dataset and explain what it can be used to test.
Check participants' permissions as well as the link. Who grants access? When is it valid? Can the data be stored locally, sent to an external API or included in a public repository? The answers need to be part of the challenge or its related rules.
For a technical integration, prepare test keys with restricted permissions, an explanation of the limits and a support contact. Do not give out shared privileged access. If the service becomes unavailable, define an acceptable fallback in advance so that the solution does not depend on when the service happens to recover.
Align constraints with judging criteria
The criteria need to reflect the challenge's goal. If you want request processing whose results can be explained, judging may consider search quality, the ability to verify a result and how easily an error can be corrected. An arbitrary criterion such as "use as many technologies as possible" will encourage different work.
For each criterion, describe the evidence you expect. A demonstration supports a working scenario; processing quality is checked against agreed examples; usability can be discussed through observable user actions. Do not promise a measurement that judges will not have time to perform.
Give the brief to someone who did not help write it. Ask them to explain the challenge in their own words, name the first step and list the information that is missing. Do not explain the text beforehand: otherwise, you will be testing your spoken introduction rather than the document.
Then ask a technical specialist to open the files and make a simple request to the test service. If the example needs an unavailable account, an unspecified library version or manually granted permission, fix the path before launch. Participants should not be the first to discover that the instructions cannot be followed.
Check that the language is understandable. You can keep professional terms if you provide a definition and an example. The Russian, Kazakh and English versions must have the same conditions. Translating "recommended" as "required" changes the rules even if the rest of the text reads smoothly.
Publish clarifications in one place
Keep a question log with the date, question, approved answer and the affected part of the challenge. If one participant asks about an allowed way to process data, every team needs access to the answer. Private consultations must not create hidden mandatory requirements.
Once work has started, distinguish a clarification from a change. Correcting a typo usually does not change a team's plan. A new mandatory integration changes the scope and participation conditions. For a substantial change, explain the reason, identify the brief's version and state how the change applies.
Before publication, assemble one pack containing the main challenge, data, criteria, submission format and contacts. Follow the participant's path with ordinary access permissions. The brief is ready to launch when it lets someone name the first verifiable result and obtain all the materials needed to achieve it.
