GovTech Hackathon

Bern | 23 – 24 March 2023

All you need to know for an exciting and rewarding (GovTech) Hackathon. Reach out with questions, feedback or for support:

v3.2 (21.03.2023)

What makes a good Hackathon?

Build, test and improve – fast

Electronic interfaces are fundamental drivers of digital transformation. In technical terms referred to as an API (“Application Programming Interface”), they are key for operating digital government services (GovTech) – connecting processes within and outside of public administration. During two days (March 23 and 24), providers and users of government data and services will join forces at the GovTech Hackathon, working outside of their daily business, to jointly implement, test and evaluate, and suggest improved designs for the efficient use and machine-to-machine exchange of data.

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 a hackathon 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 a hackathon. 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 Hackdays – you can find example challenges for this and past hackathons.

Submit your challenge by 6 February! (Deadline passed) We will reach out to support you.

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 (
  • 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
  • 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”?

“People”: Why you should be part of a hackathon.

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 the GovTech Hackathon 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 the GovTech Hackathon 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 the GovTech 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 if you need any help making your data available at the hackathon.

While every team should in principle work to gather the necessary data and APIs they need, we will work, with the help of partners, challenger owners and participants, to collect and provide an overview of available sources for the hackathon, with a particular focus on APIs – such as I14Y API repository (

How will the GovTech Hackathon work?


  • In February you will find an overview of the challenges and the program for the hackathon itself on our website.
  • A “Call for Challenges” has been launched. Do you have an idea or a challenge related to government APIs that you would like to tackle together with other participants? Submit your challenge by 6 February! (deadline passed) If needed, we will reach out to support you and promote your challenge.
  • The gathered challenges will be evaluated by the organization team and, where necessary, completed and adapted.
  • The organization team and the partners of the hackathon will identify the “most valuable challenges”. These challenges will enjoy a particular focus during the preparation, which consists in gathering information, data, best practices and examples from the international context.
  • A team of “Mentors” will be put together and instructed.
  • A jury will be constituted. The jurors will define at the end of the hackathon which projects are the most valuable and inspiring.

Last but not least: We’ll communicate about the hackathon, both on- and offline! A “share kit”, to encourage and support communication is available.


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

Day 1Day 2
Keynote: What is the mission of the hackathon
Q&A Sessions
Pitch and form teams
Challenges are pitched
Mentoring session(s): “Tools and best practices”
Team Forming: Who works well with who
The hacking goes on!
The hacking startsClosing ceremonies
Projects are pitched
Celebrate, socialize, have a drink


  • Celebrate and communicate results
  • Provide visibility to the hackathon and especially the projects. Support the top projects
  • Gathering inputs from the hackathon: Liked, Lacked, Learned

What happens to the results of the Hackathon?

The following conditions apply to works created at the GovTech Hackathon:

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.