All you need to know for an exciting and rewarding Hackathon. Reach out with questions, feedback or for support: info[at]

v1.0 (01.06.2023)

What makes a good Hackathon?

Build, test and improve – fast

During two days, interdisciplinary teams collaboratively build data-driven prototypes to tackle real-life challenges within a given topic e.g. legal (since 2021), politics (2015), mobility (2012), media (since 2021), energy (since 2019) or farming (since 2020).

How? By working together on Challenges, initiating projects and creating prototypes based on concepts brainstormed in a team setting. Hackathons such as these are used all over the world to respond to crises.

Some notable examples from the Swiss context:

Challenges, People, Technology

For our hackathons to be successful, we consider these elements to be essential:

  • Challenges, a set of comprehensive descriptions of current issues, of what we want to build, improve or repair.
  • People, those who are involved daily with challenges, and those who are willing to (help) solve them. Public administration, programmers, designers, activists, politicians, journalists and other interested parties are all invited to participate.
  • Technology: The available data, information, technology related to a challenge, together with known requirements of the solution(s) (e.g. accessibility, security), as well as tools through which available resources are combined together to make use of new information, and to transform raw ideas into neatly designed concepts that respond to a challenge.

What makes for a (good) Challenge?

We want to work on real problems and ideas. These should be formulated as “Challenges”. Challenges stand at the core of our hackathons. They are like sparks that ignite projects. Challenges can be of different types and put a range of deliverables in focus:

  • an interesting technological challenge
  • an organisational challenge, related to social or cultural issues, even those you may not even think at first glance are addressed with technology
  • a global challenge that we are dealing with as a society (e.g. linked to Sustainable Development Goals)
  • an ongoing project, struggling to deliver or that may benefit from external support, user input and feedback
  • an issue or need articulated by users or stakeholders, which needs to be further understood together with others
  • …an intriguing idea of some other kind that needs to see the light of day

Form – Tell a story

Good form is, however, dramatically important to launch effective projects:

  • Pains: Why is the challenge… a challenge? For whom? In which situation?
  • Impact: What would it mean i.e. what would be different if the challenge could be addressed, or what will happen if the challenge is not addressed
  • Small enough: Package small challenges that can be translated into a manageable set of actions. E.g.: «The public sector should improve its API is, probably, too generic.»
  • Context: Who are the stakeholders? What are the restrictions?
  • History & context: Share a little bit of history about which solutions were already tried.

… and of course, leave room for creativity. Formulate rather open, tricky challenges. Not a clearly defined ‘patch’ that you could actually commission to a programming company. The participants choose their own path around your challenge – trust the process!

Keep in mind that it can always happen that a challenge is not selected to work on: each participant is free to decide on which challenge(s) they want to work on, and they may also change their mind and switch tracks. This does not mean that a challenge is not relevant: every open challenge gets archived and can be proposed again at a later hackathon.

Challenges: An example

As a citizen, I would like to be able to follow a specific parliamentary proceeding or topic: at what time, where, in which parliament will it be handled? Interested parties and the public need an overview on which topics are on the agenda and when, with an overview of how parliaments have voted. Government personnel may want an overview about which initiatives were formulated for a topic.

Currently, among cantons, municipalities and the national level there’s a variety of different structures and quality for parliamentary data. Some data is not machine-readable, some are not fully accurate, some lack documentation and data is hardly comparable.

For this purpose, a consistent standard (a “client”) is needed for querying parliamentary data, on all levels of state politics. As successfully introduced in archiving (SRU interface), it is necessary to create a domain standard for parliamentary data. OPARL is an open standard and thus a good candidate.

The Parliamentary services set a good example by offering an open, machine-readable ODATA interface to the most important data on parliamentary activities. The city and canton of Zurich currently offer interfaces with a vendor standard. Other parliaments are currently being analyzed.

Under – the central platform for Hackathons – you can find example challenges from past hackathons.

Checklist for a successful Challenge

  • Accessibility of “own” resources: Are the data, APIs, etc. technically and “legally” (terms of use, NDA, etc.) accessible to the participants (at least) during the hackathon in order to successfully complete the challenge? Consider accessing websites/services from outside and within (blacklist) the administration. If possible, link the available data sources on your respective project page on our hack platform
  • Accessibility of third-party resources: Are the data, APIs, etc. of third parties that you need to tackle the challenge accessible within the hackathon? We recommend that you make the appropriate assessment in advance of the hackathon and, if necessary, get in touch with the data owners. If possible, link the available data sources on your respective project page on our hack platform. We are happy to provide support (info[at] 
  • Scope: Is the challenge doable in the (short) time? Have I set the right focus: core of the problem, “creative” approaches, prototyping instead of “execution work”?
  • Repository and communication: Propose a repository and communication channel for the team (e.g. both on Git(Hub)).
  • Challenge Owner Presence: Ideally, the challenge owner (or a proxy) is on-site during the whole hackathon and accompanies the team (occasional calls or similar are of course no problem). If this is not possible, he/she or the proxy must at least present the Challenge on-site and be available afterward on-site or by phone (give them your number) for questions about the challenge or the resources.
  • Sustainability: what happens to the results after the hackathon? (How) can we involve the participants beyond the hackathon? → Motivation for the hackers 
  • Expectation management: It’s possible that your challenge will not be picked by a team. In that case please don’t be mad or offended and join another team. Maybe we can tackle it next time! 

“People”: Why you should be part of our hackathons?

We want to bring people together who can actively tackle challenges.

There’s a very common misconception that hackathons are only for hackers, for techies, developers, nerds or in general for people with a big technical know-how.

While such profiles are important to tackle challenges and build quickly, we need more than that: We need people bringing domain knowledge, we need people sharing their challenges, we need people with a problem-solving attitude and willing to learn.

Having relevant stakeholders, as users and providers, may help tackle the challenge. Don’t hesitate inviting them or let us know should you need any support.

At the beginning of the hackathon these talents will be combined in different projects and will work together in teams, to create, test and improve prototypes. It shows time and again: a good toolbox, high diversity and a hard deadline are an excellent innovation recipe.

At our hackathons there are different roles. One person can have multiple roles/hats.

Formulate and share a challenge. Pitch your challenge during the hackathon’s launch. At the beginning, stay with the project teams who decided to tackle the challenges you formulated. Be available to answer possible follow-up questions.
Help solving one or more challenges. Let us know what your specialties are (design or tech expertise, domain knowledge, other skills), and what role and learning opportunities you seek. Important: Tech-expertise (e.g. API, Data Science) is welcome, but not a prerequisite.
Share your (tech-)expertise and support multiple teams. We will get in touch to explain how to mentor during this hackathon. Tech-expertise in such fields is welcome: API, data analysis, web,…

When attending our hackathons every participant will be able to pick a challenge. This information, together with some more information about their particular skill, experience of each participant, will help the organising team before and during the teambuilding phase, that is putting together effective and thriving project groups, maximizing the appeal and fun-factor of the Hackathon.


We gather data, knowledge and tools to empower people.

Accessible, complete and comprehensible data and interfaces are essential for innovation, but even more so at Hackathons.

What Data? 

  • If you can, open. Open data and open APIs are the most efficient and powerful way to enable collaboration. E.g. provides a walkthrough on how to open data.
  • To determine whether data can be made open or not is the responsibility of the data owner, who interprets the legal framework related to these data. If the data cannot be made fully open due to legal constraints, you could still make them available for a limited amount of time or for a specific group of users.
  • Note that they do not have to be available through an API. Building a new or improving an existing API could also be part of an interesting challenge. 

Reach out to info[at] if you need any help making your data available at the hackathon.

How do our Hackathons work?

You can find the definitive program on the event page of the hackathon on or on dribat. These are the most relevant steps:

Day 1 Day 2 
Opening remarks
Presentation of challenges
Team building
Presentation of projects
Social event / reception

What happens to the results of the Hackathon?

The following conditions apply to works created at our hackathons:

No transfer of rights | everyone retains the rights to anything he or she has created. It is up to the Hackathon teams to collaborate with challenge owners to continue their work.

Waiver | No one will exercise any rights of exclusivity with respect to information he brings in, even if he otherwise could exercise such right of exclusivity under the law.

Open-Source | All participants are required to submit results (Pitch, Prototype code co-developed with the team, Images – not the entire extent of the solution stack) produced under a recognized open source license (

Courtesy | Give credits. Ask if you can, but by default assume to include all those who have somehow contributed to the project.

Publication | We require teams to publish the insights and results of the Hackathon openly.

In consultation with the event organizing team, well-founded exceptions to these rules are possible.