Exploring new ways to build digital products

When it comes to building digital products, we face two kinds of problems:

• common problems: very similar across contexts and which commodity solutions exist for
• uncommon problems: unique to a particular policy area or locality, which need us to invent something bespoke

We’re always looking for more impactful ways to use our time and skills. Previously, we would lean on the excellent and much-loved Ruby on Rails framework for nearly all digital product development. But as we deal with increasingly complicated and wide-ranging challenges, we’ve been exploring alternatives that give us more of a head start on those common problems.

Strap in for a rather nerdy look at what we’ve been investigating recently.

Managing content at scale

Content management systems are cool again.

We recently delivered a new “find support near you” tool for Buckinghamshire County Council and explored options for redeveloping their adult social care webpages. With these, we took the opportunity to test new approaches to technical product architecture.

Long dominated by the reliable but boring Wordpress, Drupal and similar options, managing content hasn’t been a particularly interesting topic within digital projects for a long time. They’re a good example of a common problem with a commodity solution.

Headless content management tools like Contentful, Prismic and Sanity chop off the front-end, leaving you with an interface for administrating your content and a flexible API. The idea is that your front-end web developers are then free to build whatever experience they want, without having to “play nice” with the conventions of a particular CMS.

This is particularly enticing to us at FutureGov. While we do have back-end development skills, we’ve always been more about the user experience.

Sadly we found that, in this case, the pricing structures of these tools weren’t promising. Contentful, for instance, starts off free, but would soon move into aggressively priced premium features. It’s always hard for councils to move beyond a commissioning/capital expenditure model of paying for digital work toward an ongoing cost model. Since these are SaaS (rather than self-hosted) tools, there’s a degree of lock-in too. Which is a tough sell in the public sector.

Given that this work had no expectation of large ongoing costs, we struggled to make the case for using these headless SaaS content tools.

The self-hosted options for headless content management are a lot more limited. There’s Strapi and a few other options, but these are still quite immature tools that we wouldn’t be comfortable using beyond prototypes, yet.

We did stumble upon a winner though: Wagtail

Masquerading as a conventional CMS, Wagtail has a very handsome API that was perfect for our needs. The Wagtail philosophy is that configuration is code. This means that developers don’t need to wade through complicated UIs to make changes they’d be more comfortable coding, and content editors get a cleaner and simpler experience.

It’s a philosophy that’s well-placed to avoid feature creep that ruins lots of enterprise software. And it’s the main reason we liked it.

Even better, there’s a reasonably mature community and some big public sector users, including the NHS. It’ll also power the new unitary Buckinghamshire Council website. We had fun making things with Wagtail on this project and we’ll definitely be using it in future.

Managing community datasets

The other half of this project was managing something totally different: a sprawling database of thousands of community groups, activities and services across the county.

We were moving this database, formerly a series of spreadsheets, online for the first time. It was an exciting opportunity to digitise a team’s processes, as well as open up the dataset to real-time queries with web APIs.

To store the data itself, we chose the non-relational database MongoDB over our normal go-to, PostgreSQL, because crushing spreadsheet data down to fit a fixed database schema in one go wasn’t practical. We needed to enforce a schema gradually as we go, probably similar to the emerging OpenReferral standard. MongoDB stores blobs of JSON as documents, and doesn’t require a common schema from one document to the next. Perfect! MongoDB also has space-age geospatial querying features, which drive a location-based search feature.

We didn’t have time to develop a totally custom, one-off data management interface, and didn’t really want to since we’re finding that stewarding this kind of data is a common problem across councils.

Instead, we tried Forest Admin, a generic admin panel framework which did indeed save us plenty of time.

The killer feature was the lack of lock-in. We can host our data however we like and never lose control over it — Forest Admin accesses it via an API. Forest Admin wasn’t perfect — the responsiveness and speed of the interface left a little to be desired, but it still let us deliver an impactful product quickly by freeing us up to focus on bigger problems.

We think the problem of data stewardship is common enough to warrant good commodity solutions, but we didn’t quite find the tools we hoped for.

What’s next?

We’re already seeing opportunities to refine this work in other locations, and there are some lessons we’d apply:

1. Wagtail could well be one of our go-to tools for building large, content-heavy sites.
2. Data management and stewardship is a common problem with solutions still emerging. Forest Admin is probably not the right tool for long-term use, so we have our eyes open for the right one. If we don’t find it, we’re not averse to building it!