Loading article...
Prepare for a Web3 hackathon with a realistic project scope, a clear demo, tested code, and a submission plan.
A blockchain hackathon is a short build event, usually organized around a theme, a set of sponsors, and a submission deadline. Events such as those hosted by ETHGlobal often give participants access to workshops, mentors, and project bounties. They can be an effective way to learn because a team must make technical choices, build a usable flow, and explain it to someone outside the team.
The goal for a first event should be a finished demonstration and a clear account of what you built. A prize is possible, but it depends on judging criteria, sponsor requirements, other submissions, and timing. A project that does not win can still become a strong portfolio piece if the repository, demo, and lessons are honest and reproducible.
Start with the event page. Record the start and end time in your time zone, submission platform, required fields, eligibility rules, team-size rules, code-sharing policy, and every bounty deadline. Some events require a public repository, a deployed contract, a video, a slide deck, or a particular technology. A good prototype can be disqualified if it is submitted to the wrong track or misses a required link.
Read sponsor pages closely. A bounty may require a project to call a particular contract, use a specified SDK, deploy to a named chain, or demonstrate a certain feature. Do not infer requirements from a sponsor logo. Save the official documentation links in a shared note and assign one person to confirm that the final project meets them.
Ask whether the event permits prior work. Many hackathons allow pre-existing tools but require the project itself to be built during the event. If your team starts from a boilerplate, describe it accurately. A hidden dependency or exaggerated claim can hurt a submission more than a modest scope.
Teams of two to four people are often easier to coordinate than a large group. There is no required role mix, but someone should own the core product decision, someone should own the on-chain or backend logic, and someone should own the interface and demonstration. One person can cover several areas when the project is small.
Choose collaborators based on communication and follow-through, not only a long list of tools. Before the event, discuss available hours, time zones, preferred communication channel, and whether each person wants to code, design, present, or organize. Agree that the team will cut features when time is short. This prevents a common problem in which everyone starts building a different version of the product.
Set up a repository, issue board, and chat channel before the opening ceremony. Add a README with local setup steps, an environment-variable example that contains no secrets, and a basic license if appropriate. Confirm that every contributor can clone the repository, install dependencies, run the app, and open a pull request.
Working alone is also valid. A solo builder has fewer coordination costs and can make decisions quickly. The tradeoff is that the scope must be smaller. Pick one user flow, use familiar tools, and schedule time for the video and submission rather than spending every hour on code.
Prepare a development environment in advance. Install an editor, Node.js or the runtime you use, Git, a contract framework, a browser wallet, and test dependencies. Create a separate development wallet with no meaningful funds. Obtain testnet tokens if the event uses a public test network, but keep a local-chain plan in case faucets or RPC providers are unavailable.
It is reasonable to prepare generic components: wallet connection code, a basic Next.js shell, a testing configuration, a deployment script template, and a design system you already understand. Avoid preparing the event's central feature if the rules forbid it. Keep boilerplate small enough that you can explain every file during a review.
Run through one practice deployment. Compile a trivial contract, deploy it locally or on the intended test network, call a read function, send a transaction, and find its hash in an explorer. This removes a category of avoidable setup errors. If a sponsor's SDK is central to your idea, build a tiny proof of concept with it before the event if the rules allow research.
Good hackathon ideas begin with a specific actor and a specific moment of friction. "Improve DeFi" is too broad. "Let a small group split a shared expense after each member signs the same settlement" is narrow enough to prototype. The problem statement should identify who acts, what information they have, what action they take, and what result they receive.
Use a short scoring exercise when the team has several ideas. Ask whether the project can be demonstrated by one person in three minutes, whether it uses the sponsor technology in a meaningful way, whether the core action can be completed on a test network, and whether the team can test the risky part before the deadline. Reject ideas that need an oracle partnership, a large user base, legal approval, or a custom protocol before the demo can work.
Write the minimum viable product as a sentence. For example: "A user creates a payment request, another user approves it, and the request becomes visibly settled after the transaction confirms." Everything beyond that is optional. Social feeds, governance systems, referral programs, mobile apps, and elaborate token economics can wait.
Spend the opening hours agreeing on scope rather than immediately typing. Create a simple user-flow diagram or numbered list. Identify the contract functions, the frontend screens, the data that lives on-chain, and the data that can remain in a local or hosted database. List the one risk that could prevent the demo, such as an unfamiliar contract call or an unreliable third-party API.
Turn the plan into small tasks with a named owner and a checkable result. "Build contract" is not a useful task. "Add createRequest, reject a zero amount, and write tests for creator and non-creator actions" is. Keep a visible backlog with a must have, should have, and only if time remains section. Delete optional items as soon as they threaten the core flow.
Agree on interfaces before parallel work begins. The frontend needs a contract address, ABI, function names, expected events, and error cases. The contract engineer needs to know what inputs the interface can collect safely. A five-minute written interface note prevents hours of integration drift.
Implement the smallest end-to-end slice before adding screens or polish. If a contract is central, write its simplest correct version, test it locally, deploy it, and call it from a rough interface. If the project depends on an external protocol, prove the integration works early. A beautiful landing page cannot compensate for an untested core transaction.
Keep contract state and permissions simple. Define who can call each function and what must be true before it runs. Emit events for actions the interface needs to observe. Use established libraries for standard tokens and access control rather than rewriting standards under time pressure. Do not put private data, API secrets, or personally identifying information on a public chain.
Test the happy path and a few failure paths. At minimum, test invalid input, an unauthorized caller, a repeated action, and the state after completion. In the interface, show wallet rejection, wrong network, pending status, successful confirmation, and a readable error when a transaction reverts. A small system that handles those cases is more credible than a larger system that only works in a recorded demo.
Commit regularly and use pull requests when the team can do so without delay. A teammate should read the code touching funds, permissions, or external calls. Review is useful even if it only catches a mismatch between a button label and a contract method.
Mentors can save time when the question is concrete. Before asking, write the failing command, error message, relevant code, network, dependency version, and steps already attempted. Ask one question at a time. "Our call to this documented method reverts on Sepolia with this error; does the protocol require an approval first?" is easier to answer than "Why does our integration not work?"
Attend a sponsor workshop if the technology is central to your prototype, but do not attend every session by default. Watch recordings later when available. The team should protect build time, meals, rest, and a short daily check-in. Exhaustion produces mistakes in credentials, deployments, and submissions.
Keep a decision log. Note why you chose a test network, what you left off-chain, which sponsor requirement you satisfied, and what limitation remains. This material becomes the README, pitch, and post-event write-up.
Judges and reviewers need to understand the problem before they can evaluate the technical work. Start the presentation with the user and the friction. Show the working product soon after. Narrate only the actions that matter: connect the wallet, perform the main action, approve the transaction, wait for confirmation, and show the resulting state.
Record a backup video even if a live presentation is planned. Browser wallets, test networks, and Wi-Fi can fail at inconvenient moments. The recording should show the real application and, where useful, a transaction hash or explorer page. Do not present a mockup as a deployed feature. State clearly if a contract is on a test network or if a feature uses simulated data.
Keep slides sparse. One architecture image can help if it explains which parts are on-chain, off-chain, and third-party. A slide with every framework logo rarely helps. End with the repository, deployment link if available, and setup instructions. If the project is unfinished, demonstrate the completed core path and name the missing work directly.
Treat the submission as a product feature. Several hours before the deadline, open the judging form and fill in the project name, team members, description, repository, video, and deployed links. Verify permissions in an incognito browser or with a teammate. Check that the repository is public if required and that no .env file or private key was committed.
Compare the submitted project against each selected bounty. Include a sentence that explains how the project uses the sponsor's technology and a direct link to the relevant code or deployment. Confirm that contract addresses and network names are correct. A reviewer should not have to search through the codebase to find the claimed integration.
Reserve time to fix a broken link, rerun the demo, and submit early. A late change can break a stable build. Once the required material is complete, prefer reliability over adding a feature that has not been tested.
After the event, clean up the repository while the decisions are fresh. Improve the README, add setup instructions, list known limitations, and write a short explanation of the contract's permissions and tests. If a critical path was mocked for the demo, label it and describe the work needed to make it real.
Review what happened with the team. Which estimate was wrong? Which tool caused delay? Which feature should have been cut sooner? Which test or check would have caught a bug earlier? A concise retrospective improves the next event and gives you a concrete story for an interview.
Follow up with people you met by referring to a real conversation or shared project. Thank mentors who solved a specific issue. Continue an open-source contribution if the hackathon code revealed a reusable improvement. The practical value of a hackathon comes from the code, relationships, and engineering judgment you carry into the next project.
Explore more guides and career playbooks