Web and platform engineering

Public websites and campaign sites. Publishing and editorial platforms with real workflow behind them. Membership systems covering joining, renewal, tiers, directories and gated content. Portals and intranets for people who log in and get something done. Event and conference sites, including programmes, submissions and delegate handling. Archives and libraries where the content is structured data and has to stay searchable for decades. Documentation sites. Multi-site networks where one design serves several markets, chapters or brands. Front ends that read a CMS over an API instead of rendering it directly.

If what you need is not on that list, ask us. Most requirements turn out to be one of these under a different name, and the ones that are not are usually the more interesting brief.

On a new build the content model gets settled early, because everything downstream inherits it: navigation, search, feeds, exports, and whatever gets asked for in year three. We keep layout out of content, so a redesign later stays a redesign instead of turning into a re-entry.

We work on established CMS platforms where people need to edit their own site without calling anyone, and on custom stacks where the requirement has outgrown what a CMS should reasonably be asked to do. The choice comes out of the requirement, and we will tell you which one we think it is and why.

Moving off a system that has become a liability is a large share of our work. Most of the effort goes into proof: that every address still resolves or redirects somewhere sensible, that the content arrived intact, that search visibility built over a decade survived the switch, and that anything retired was retired deliberately.

We plan for source systems that make this difficult. Hosts that block automated requests. Exports missing tables they should contain. Media libraries whose filenames stopped matching their files years ago. Content that was never modelled in the first place, only typed. Budget for that and a migration is long and uneventful. Skip it and the failure happens in public, on launch day.

Both are engineering constraints agreed at the start and tested against, not a score chased in the final week. In practice that means page-weight and Core Web Vitals budgets written into the brief, keyboard and screen-reader testing on real templates, and contrast checked against measured values instead of eyeballed.

Where you have a legal obligation under EN 301 549 or WCAG 2.2 AA, we will tell you what the build meets and where it falls short. A claim of full conformance that nobody has tested is worth less than an honest list of gaps.

We implement design faithfully, including the parts a static comp leaves open: focus and error states, empty states, loading, over-long strings, and every screen width between the two that were drawn. Where a design does not answer a question we answer it with the same logic, instead of starting a second visual system halfway down the page.

We also design, for projects that arrive without an agency attached.

Most engagements do not stop at launch. Updates, security, monitoring, extensions, the annual round of changes every organisation needs, and being reachable when something breaks at an inconvenient hour. It is not sold separately because it is part of nearly everything we do.