HDUK: Engineering for Independence

Role: Volunteer Senior Engineer
Scope: Complete website rebuild, UI design, and CMS integration
Tech Stack: React, TypeScript, Cloudflare Pages, PagesCMS

Table of Contents

• Introduction
• Understanding Who We Are Building For
• The Website Was Only the Starting Point
• Being the Technical Advocate
• Designing Ourselves Out of the Process
• Engineering for Independence

Introduction

When we started rebuilding the Hirschsprung's Disease UK (HDUK) website, our goal was to deliver something accessible, easy to navigate, and at an enterprise standard without the long term costs or dependencies that usually come with it.

HDUK is a charity, not a software company, they do not have an engineering team, and every pound spent keeping technology running is a pound that cannot be spent supporting their community.

This gave us an interesting set of requirements: how do we make a website manageable and maintainable with minimum engineering effort? We needed to give the trustees both the confidence and ability to maintain the content on the site themselves.

Understanding Who We Are Building For

When building software, understanding the audience is the key to success.

We weren't just building another website, we were building something that would likely be used by someone sitting in a hospital waiting room at 3am, while being told their child has a condition they likely do not understand. In that moment, people are highly stressed, sleep deprived, and almost certainly using their phone.

This exact scenario heavily influenced our design decisions. We needed something that was easy to navigate during highly emotional moments, getting someone from entering the website to the most useful information with as little friction as possible. We assumed a mobile first layout and focused on clear page organisation patterns to limit cognitive overload.

One of the first sections a user is presented with is We've just been diagnosed which links them directly to Information Hub. This was an intentional design decision, driven by the trustees' first hand experience of wanting access to high quality information as quickly during these high stress situations.

This principle is carried through into the way the content itself was presented. For example, the Information Hub page contains a lot of information, so we intentionally designed the page to reduce the effort and fatigue of finding answers in the moment, we grouped related information into collapsible sections, keeping it hidden until actively needed.

The Website Was Only the Starting Point

From an engineering perspective building a website is essentially a solved problem, the complexity here wasn't the designing or making of the website. It was building something to the standard you would expect from a professional organisation without the enterprise backing that normally comes with it. That meant thinking beyond what worked today and considering whether the decisions we made would still make sense years from now.

To ensure long term maintainability, we deliberately kept the tech stack boring. We could have chosen any framework, any hosting provider, or introduced endless complexity. Instead, we relied on standard React TypeScript, automated pipelines, and Cloudflare hosting. This wasn't meant to be exciting, it was meant to be approachable. Relying on widely understood technologies ensures HDUK will always have a large pool of developers who can easily pick the project up.

Cost is a factor in every project, but how that constraint is handled differs wildly between enterprise software and a charity. In an enterprise environment, spending a few extra pounds a month on a service is often negligible, whereas for a charity, every pound spent on technology is a pound taken directly away from the organisation's actual goals. We designed around free services wherever possible because of this, not to cut corners, but to carefully weigh the trade offs and find the best path at the lowest sustainable cost.

Being the Technical Advocate

As engineers, we are experienced in building this stuff, and that means we should be advocating for things that make actually make an enterprise quality site, even when they weren't explicitly asked for. Accessibility, clear navigation, responsive behaviour, and maintainability all matter, but they aren't necessarily things someone outside of software should be expected to know to ask for / know about.

It was our responsibility to ensure these non functional requirements were baked into the foundation from day one. Applying common principles of website design, such as WCAG 2.2 AA standards, meant building in full screen reader support, clear focus indicators, and accessible touch targets right from the start. Building the layout mobile first guaranteed compatibility with a variety of screen sizes and input methods, including touch screens and keyboards. Establishing these professional standards as the default meant HDUK wouldn't have to worry about them later.

Designing Ourselves Out of the Process

One of the biggest risks with a project like this is accidentally making yourself a dependency, because if every content change requires an engineer, the charity never really owns the website.

We wanted HDUK to have complete control over their content without ever needing to look at a line of code, so we integrated PagesCMS alongside our Cloudflare hosting. This gave the trustees an intuitive visual dashboard to write and manage content, and since it simply updates files in our repository behind the scenes, there is low risk of a non technical user accidentally breaking the site.

They can now edit every page directly or seamlessly publish new stories and documents without worrying about the underlying technical configuration. We also built in the smaller controls that become critical over time, allowing content to be unpublished without being deleted and giving them the ability to easily choose which stories are prioritised on the homepage.

That didn't mean removing engineers from the problem entirely, since structural changes, new functionality, or changes to how the site itself works will still require engineering support. The goal was simply to make sure the charity didn't need an engineer for the routine work of keeping its content alive.

Engineering for Independence

Ultimately, engineering for independence meant making technical decisions that gave HDUK genuine ownership of their website, rather than tying that ownership to the developers or technology behind it.

The people working on a project today won't always be the same people supporting it years from now. True independence means recognising that reality and ensuring the charity is never permanently locked into relying on the engineers who originally built the system.

Good software shouldn't depend on the people who built it.