Business Grants Portal: Our technical journey

Dong Yangzi
Government Digital Services, Singapore
3 min readMay 5, 2016

The Business Grants Portal (BGP) has been launched in beta. It’s been quite a journey for the team here at Government Digital Services (GDS) and we’re excited for businesses to start using the portal to apply for grants.

Background

BGP allows businesses to apply for government grants through a common portal. When building BGP, our key goal is to create a seamless user experience that will simplify the grant application process.

Getting started with BGP from https://www.businessgrants.gov.sg/get_started

What we’ve learned

As a tech lead for BGP, here are some of my takeaways:

Don’t be afraid to throw code away

Our initial prototype was built in two weeks using Ruby on Rails. As we tackled new features like real-time server-side validation and dynamic form creation, we realised that the traditional MVC monolithic architecture was insufficient for creating the seamless user experience we wanted.

For our front-end, we needed a framework to manage the frequent changes in display state (we chose React after experimenting with Meteor, Angular, and our own homespun solution). On our backend, we started breaking up our monolithic, single-controller design to a API-centric design to reduce payload size and increase client responsiveness.

These changes meant that we had to do major rewrites of our codebase. Although it seems wasteful, these rewrites in fact helped us accelerate learning and create cleaner code.

Design for the right level of abstraction

One of our challenges in building BGP was in choosing when generalisation improves reusability and when it just causes confusion. While it was tempting to create a domain-specific language to generate grant forms from the get-go, we found that our assumptions about the entity-relationship model and the desired user experience were often wrong.

Instead, we found it more productive to start by writing clear, straightforward code, even if it does sometimes violate the DRY principle. We then refactored and generalised when patterns became apparent, relying on emergent design rather than architecting the system upfront. This is where good engineering practices like unit testing pays off — we can refactor fearlessly without worrying about breaking old features.

Use the right processes

We were able to continuously evolve our architecture and design only because we developed BGP using agile methodology. In a big, evolving project like BGP, agile works because there can be many unknowns in the process.

(My colleague Steven has written an excellent series on introducing Agile to your organisation: check out part one here.)

By building iteratively and tackling technical spikes with prototypes, we were able to surface limitations with the tools and design we have chosen quickly. Although these quick-and-dirty prototypes are often discarded, they help us manage risk and understand the tradeoffs between our choices.

What are some of the challenges you’ve faced in developing complex web applications? Want to learn more about our processes and tools? Drop me a note below or contact me at dong_yang_zi@ida.gov.sg!

--

--