Read the rules before building
Confirm eligibility, team size, judging criteria, required tools, submission format, intellectual property terms, and the exact deadline. Rules differ widely between events.
Identify what must be created during the competition and what prior work is allowed. Ask the organizer when a rule is unclear rather than making a risky assumption.
- Eligibility and team limits
- Judging criteria and required theme
- Permitted datasets, APIs, and prior work
- Submission files and deadline
Build a balanced team
A useful team covers problem understanding, implementation, design or communication, and presentation. One person can cover more than one area, but every responsibility needs an owner.
Agree on communication tools, availability, and decision rules before the event. A smaller coordinated team often moves faster than a larger team without clear ownership.
Reduce the scope early
Define the user, the problem, and the single result your prototype must demonstrate. Build the smallest complete path before adding secondary features.
Keep a visible task list and test integrations early. Technical risk discovered near submission time is much harder to fix.
- One clearly defined user
- One problem supported by evidence
- One complete prototype flow
- One measurable reason the solution matters
Prepare the submission while building
Collect screenshots, sources, setup instructions, and contribution notes as work progresses. Do not leave the entire presentation and documentation until the final hour.
A strong pitch explains the problem, the user, the solution, what was built, and what evidence supports the impact. Practice within the official time limit.