How we’re building an adaptable and sustainable web platform
Evaluating technology choices, reducing repetition and waste — and building something better
Hello! I’m Kieran, a Digital Platform Manager at British Red Cross. My focus is our new Web Platform — and our ambitions for our team and the service we offer to the organisation.
We want to create a high-quality web platform and run it as a service so that other teams can reach their audiences without having to worry about building, maintaining and supporting a website.
To do that, we need to re-evaluate our technology choices across our ‘digital estate’ (i.e. websites and apps), reduce repetition and waste, and build something better. We’re not alone in this transformation, but knowing where we’re coming from might help you to understand what we’re aiming for.
The past
Our team manages a large digital estate for our size, with myriad different technologies and platforms. Some Sitecore, some Umbraco, a handful of WordPress, and a few hand-coded static sites that come and go for campaigns and causes as needed. Built by different people with different technologies at different times, their differences are many!
On top of this varied estate, we engage agencies for development and support. Product Owners and Platform Managers work with these agencies to deliver changes. We usually aim for a regular cadence, but it can range from weeks to months, depending on availability, complexity, and cost.
The idea
With a growing feeling that having to support such a varied digital estate was holding us back, Ged (our Senior Developer) and I began talking and wondering if there was a better way for us. We quickly converged on the idea of a single platform that our team could use to run many websites, supplying standard components and features out-of-the-box for our audience and reducing duplication of effort for us.
This would be like what Ged had already started with our WordPress platform, but with a more conscious choice of tools and principles that would help to future-proof us. We wanted:
- To achieve consistency in many things: how we manage sites, how sites look and behave, and what other teams can expect from us.
- To build and do less non-essential stuff. This is the infamous ‘build vs. buy’ question, and we wanted to shift our stance towards ‘buy’ for things that aren’t pivotal to our mission.
- To bake ‘changeability’ into all things, so we could make incremental changes without breaking things. The biggest part of this would be decoupling the website front-end from the CMS (Content Management System) back-end.
- To take the last point further, we wanted truly Continuous Deployment. For older platforms, we relied on agencies to deploy large batches of work, rolled up over a period of weeks to months. It’s relatively expensive and can get complicated. Aiming for a drastic departure from the status quo, we knew from the beginning that we wanted to use automation and new ways of working to enable incremental, isolated changes to be tested, approved, and deployed as soon as they were ready. Always.
Regarding #2, something I wanted to avoid if possible was the responsibility for updating and supporting the CMS software and infrastructure. That stuff has been my bread and butter for years, but I’m not sad to leave it behind. If you’re building a decoupled system then cloud headless CMSs — CMS-as-a-service, anyone? — have come a long way.
Altogether, I call the whole stack the Web Platform because it’s simple and descriptive. The technology isn’t useful to our users, nor is it an obscure codename. We want to offer an end-to-end curated and well-supported experience to teams across our organisation, where they worry about their content, service, audience, and purpose, and we worry about building and running websites.
Where we are now
We built a website! The new VAD (Volunteer Aid Detachment) site launched in November 2022, just in time for Armistice Day.
The old VAD site had suffered for a long time without a dedicated owner and was so out of date that it needed to be shut down for security and cookie compliance reasons. I liked the site and wanted to redo it for a while, and luckily it was a good fit for us. It didn’t have much content but could search a huge database of volunteer records — giving us an opportunity to try our hands at building an API integration.
After months of research and internal discussion, we got the green light to rebuild VAD with our new Web Platform as a proof of concept.
The Web Platform
There are four main parts to the Web Platform:
Component Library
- React with TypeScript.
- Tailwind for CSS styling.
- Hosted on Chromatic.
Front-end app
- Next.js with TypeScript.
- Uses our Component Library! (Also, Tailwind again for any extra CSS styling.)
- Hosted on Netlify.
CMS
- We’re using Kontent.ai! We define the content models, but Kontent.ai is a SaaS (Software as a Service) product and they’re responsible for running and supporting it.
And for the volunteer records database
- One huge Azure Cloud Table.
- Azure Cognitive Search.
(There is another key ingredient — the Design System — which would be at position 0, but it’s not technically a connected part of the Web Platform stack. It deserves a post of its own, so I’m happy to leave that to Brendan, our UX/UI Designer!)
Wanting to save our developers time (which is valuable!) I’ve put a fair amount of effort into automating routine tasks in the Component Library’s and front-end app’s GitHub repositories. We use Dependabot, GitHub Actions, Conventional Commits, and Semantic Release to keep the mundane stuff ticking along nicely with minimal intervention needed.
With the above practices and abundant automation enabling (encouraging, even!) small, incremental changes, and Netlify’s automated deployments releasing those incremental changes for us, we’re able to make changes to the Web Platform every day, with confidence.
Julio, our Front-End Developer, says:
“Contributing a front-end change to the Web Platform can feel exhilarating, as the impact of the change is immediately visible and can have a significant impact on user experience.”
Some more highlights:
- Not only was the VAD site quietly launched in time for Armistice Day, the big milestone we needed to be ready for, but we continued to deploy improvements on the day itself.
- When we had a penetration test run on the VAD site, we were able to fix two or three of the issues found on the same day.
- When we had an accessibility audit run on the VAD site — with some interesting findings, more than we were expecting, but that’s a story for another post — we were able to create an isolated, frozen-in-time instance for the auditors in about 15 minutes. (They couldn’t audit the live site because we make several changes a day, and they needed a fixed point to work from.)
- On more than one occasion, we’ve discussed a new change in the morning and seen it released in the afternoon.
The future
So, what’s next? We still have plenty of crucial and interesting challenges ahead. I split our roadmap into two themes: growth and stability.
The most important milestone for ‘growth’ right now is figuring out how we can run a second site with this platform. We think there are two likely paths, with trade-offs, and we’re waiting for some key and promised features from Kontent.ai that will help.
We also need to add new features to the Web Platform if we’re going to compete internally. The ability to add forms to sites (ideally created and managed elsewhere, in a dedicated tool), or videos, or maps, or audio clips, or anything else that will help our staff create useful, compelling content.
Yet, we also need to be proactive about good practice, performance, consistency, and everything else that contributes to the health and cohesiveness of the platform. We plan to build something sustainable.
This new Web Platform will continue to grow, and we will continue to aim for the best that we can do for every challenge and opportunity. We plan to hire more developers very soon, so please keep an eye out for job vacancies for our team. Feel free to reach out if you want to talk about what we’re doing!
Mastodon: @kieranmcguire@hachyderm.io (preferred)
Twitter: @kmcguire_dev (Not checked regularly)
