How we build

Many OGP products that are widely used across Singapore today, including RedeemSG, ScamShield, Go.gov.sg, ParkingSG and KampungSpirit, began at the same place: Hack for Public Good, OGP’s annual month-long hackathon held every January.

What is Hack for Public Good?

Hack for Public Good is an annual fixture of OGP’s way of work to keep us identifying and working on building tech to deliver public good in its various shapes and forms.

Every January, OGP officers set aside non-core work to tackle a public good problem. Teams start with problems they care about, speak to users, test ideas, and turn early concepts into working prototypes by the end of the month, while picking up new skills along the way.

What happens during Hack for Public Good?

1. Discovering real problems on the ground

We spend much of the year getting out of the office and into the field, working with public agencies, social service organisations, community partners and the citizens they serve to uncover problems worth solving. The problems we work on do not come from sitting in a room and guessing.

• Month of Good: Around the middle of the year, OGP officers volunteer with social service agencies and community organisations, including those they have personally suggested. The aim is not to solve every problem in a month, but to bring officers closer to the communities, systems and constraints that public good products are meant to serve.

• Learning Journeys: At the end of the year, OGP officers spend time with public officers across the service to understand the realities of day-to-day work, what gets in the way, and where technology could make a meaningful difference.
  

Having our officers understand what the ground is feeling and facing allows us to align the solutions we build to actual experiences, and deliver public good.

2. Building, testing and iterating

Once teams find a problem worth solving, they move quickly. They build prototypes based on real needs, test them with actual users, and use the feedback to sharpen their ideas.

Some teams release early versions for public officers or members of the public to try during the month. These are not finished products. They are early prototypes built to learn what works, what does not, and whether the problem is worth taking further.

The month ends with Demo Day, a booth-style showcase where teams present their work to public service leaders and officers from across government.

3. What happens next?

Each project then takes one of four paths:

1. Keep building it. A dedicated team takes it forward, with regular reviews to check whether the investment is paying off.

2. Fold it into an existing product. If it fits naturally with something we already maintain, we absorb it instead of running it separately.

3. Release it in a limited way. If a product is useful, mostly complete and low-maintenance, we may open it up for use. But it is not officially resourced, so updates will be limited and it may eventually be shut down.

4. Document and wind down. If we decide not to continue, we write down what we learnt so future teams do not have to start from scratch.

Whatever the outcome, everything gets written up. The learning matters as much as the product.