Skip to main content
A Singapore Government Agency Website How to identify
Official website links end with .gov.sg
Government agencies communicate via .gov.sg websites (e.g. go.gov.sg/open). Trusted websites
Secure websites use HTTPS
Look for a lock () or https:// as an added precaution. Share sensitive information only on official, secure websites.
Hack for Public Good

About Hack for Public Good

Our approach and process

Last updated 5 May 2026
OGP officers look at problem statements on the wall.

What is Hack for Public Good?

Hack for Public Good is Open Government Products' annual hackathon. Every January, the whole organisation sets aside its regular work for a month to focus entirely on problems that people on the team genuinely care about but don't always get space to work on.

Over the course of the month, teams talk to real users, build working prototypes, and present what they've made –– picking up new skills and ways of working along the way.

We run it because the best ideas don't always come from the top. It's one of the best learning and development opportunities we can give our people, and what teams discover during hackathon often pays dividends for years to come.

About seventy percent of our product portfolio started here. Products like Redeem, ScamShield, AskGov, and go.gov.sg all started as someone's frustrated observation tackled during hackathon. Today, they're critical digital infrastructure used across Singapore.

Grid of OGP product logos

Discovering real problems

The problems can come from anywhere as long as they’re for public good. Sometimes from the personal experiences of people on our team; sometimes from citizens, public officers, or partner agencies.

To make sure we're not just solving problems we already know about, we run Learning Journeys throughout the year, putting OGP staff alongside public officers and people from all walks of life in Singapore.

OGP officers talk with a member of the public.

Building, testing, and iterating

Once teams have a problem worth solving, they move fast. They build prototypes grounded in real needs, test them with actual users, and use what they learn to sharpen their ideas. Regular check-ins along the way help raise the quality of the work ahead of the finale: Demo Day.

Prototypes

During hackathon, some teams release early versions of their products for public officers or members of the public to try out. These are prototypes: early-stage tools designed to generate feedback, not finished products. Things might be missing, some features might be simulated, and the team won't always be able to offer support. If something isn't working quite right, that's expected. The point is to find out whether the idea is worth building properly.

Demo Day

Demo Day is the finale. Teams set up booths in a science fair-style exhibition, sharing live demos, presentations, and write-ups about what they've built. Public service leaders and officers from across the government come to see the work, give feedback, and help us figure out which products are worth taking further.

Demo Day is a celebration of what public officers can do when they're given the space and trust to solve real problems.

Set in a crowded hall, OGP officers pitching their prototypes during HFPG demo day

What happens next

After Demo Day, OGP leadership reviews every product against three criteria before deciding next steps:

  • Opportunity – What this solves, who it affects, and why it is worth solving

  • Velocity – What the team accomplished in the last month

  • Traction – Whether real people are using it, and what has changed as a result

This keeps our decisions consistent, focused on the most promising ideas, and leads to one of four outcomes.

  1. Keep building it – If a product is solving a real problem and people want it, we put a team behind it and keep building. We set up regular reviews to track whether the investment is paying off.

  2. Absorb it into an existing product – If a project fits naturally alongside something we're already building, we fold it into that team rather than run it as a separate effort.

  3. Limited Release – If a product is mostly done and doesn't need much to keep running, we open it up as a Limited Release. People are welcome to use it, but it's not officially resourced, so don't expect regular updates and we may shut it down eventually.

  4. Document it and wind it down – If we decide not to take a product further, we make sure the learnings are properly documented, so that if anyone wants to pick up a similar problem in the future, they're not starting from scratch. Then we shut it down cleanly.

Browse the projects

Many of our products have moved on from hackathon into fully resourced teams. Many more are documented and discontinued. Whatever the outcome, everything gets written up. The learning matters as much as the product.

Browse the latest projects as well highlights from past years.