Preparation does not mean building the whole project before an event. It means removing avoidable friction so you can use the time to collaborate. This guide is useful for a workshop, a short build sprint or a hackathon. ETH Tunis’s challenge format is still to be confirmed.
Arrive with a question, not a giant specification
Choose an area you want to explore: verifying a record, improving an onboarding journey or coordinating a shared decision. Write down the problem and the person affected. Leave room for teammates to challenge your first idea.
Define the smallest demonstration that would help you learn something. A complete action for one user is usually more useful than several unfinished screens. Keep a separate list of optional features so the core flow stays visible.
Remove setup problems early
Check your laptop, charger and development environment before you arrive. Make sure you can run a basic application and understand how to share code with a collaborator. Follow the current documentation for the tools you choose.
If a workshop publishes prerequisites, complete them and bring any installation questions early. A browser-only exercise and a contract development session can require very different preparation.
- A working laptop, charger and backup access to project notes.
- A version-controlled project with clear setup instructions.
- Separate test accounts and fictional sample data.
- A short explanation of the learning goal and your current blockers.
Give the team a simple working agreement
At the beginning, agree what you want to demonstrate and who owns each part. One person might focus on the interface, another on contract behavior and another on testing and the story. People can share roles, but each task needs a clear next action.
Agree how to combine changes and how often to show progress. Keep a visible list of working features, open questions and decisions. If a dependency is blocked, reduce the demonstration or replace it with a clearly labelled simulation.
Plan time for integration and explanation
Do not leave the first end-to-end run until the final hour. Connect the interface and the contract early, even if both are very simple. Save a stable demonstration path before adding optional features.
Prepare a fallback recording or screenshots in case a connection fails, while explaining clearly what was recorded. A fallback supports a demonstration; it should never be presented as a live action when it is not.
Finish with an honest handover
Explain the problem, show the result and describe what remains unfinished. Include setup instructions, tests and known limitations in the repository. Credit libraries, teammates and other contributions.
After the event, choose one next step: fix a usability issue, ask a potential user for feedback or continue a technical investigation. The project does not need to become a company to be valuable. Learning and a new collaboration are useful outcomes too.
Resources & further reading
Primary documentation and references for further learning. Linking to a resource does not imply a partnership.
Something to contribute?
Propose a workshop, share your project or tell us how you’d like to take part.
Contribute to ETH Tunis