I Built a Modern UK Government Service Using COBOL

Introduction

A few days ago, I published a rather lengthy blog post titled Building Services to GDS Standards Without a Frontend Framework, exploring whether modern frontend frameworks are really necessary when building UK government services. To demonstrate they aren't, I built the same service using eight different backends.

Shortly after publishing, I had a conversation with Matthew Somerville, of traintimes.org.uk fame, who suggested adding Perl as a ninth backend. It's something I plan to explore, so thanks for the suggestion, Dracos!

That conversation got me thinking. If I could build a modern government service using eight different backends, how much further could I push the experiment? What about a programming language that predates the World Wide Web, and certainly wouldn't be anybody's first choice for building a modern government service?

After a little research, I settled on COBOL. A language so old that calling it "mature" feels like something of an understatement!

Yes, COBOL. A programming language first developed in 1959. That’s 67 years ago, long before HTML, CSS, JavaScript, or even the World Wide Web existed. In fact, COBOL predates the first moon landing by an entire decade, and it’s almost as old as my parents! It’s certainly been around a lot longer than I have.

So, let’s build a fake UK government service using a backend language that’s been around for nearly seven decades. A language developed when computers literally filled entire rooms, programming involved punch cards, and the idea of accessing a government service through a web browser would have sounded like something from a science fiction novel.

Now, before anybody gets too worried, I’m not suggesting that UK government departments should start developing new services using COBOL. This is purely an experiment to demonstrate how little the browser cares about the technology generating its HTML. Although, given COBOL’s history within government, perhaps it’s actually a more appropriate choice than it first appears!

The Experiment

As with my previous post, I wanted to keep the experiment as consistent as possible. Rather than simply writing a COBOL application that outputs a few lines of HTML, I wanted to see whether I could implement GOV.UK Frontend components and build the same fictional fishing rod licence journey, using a programming language designed more than three decades before the first website appeared.

The requirements are essentially identical to those used for the original eight implementations:

1. Implement GOV.UK Frontend components using COBOL, with automated fixture tests that compare the generated HTML against the official GOV.UK Frontend output.
2. Build the same fictional fishing rod licence service, using server-rendered HTML and the GOV.UK Design System.
3. Ensure the core user journey works without requiring client-side JavaScript, following the principles of progressive enhancement.
4. Keep the generated HTML consistent with the other eight backend implementations, while using COBOL rather than a modern application framework.

One important rule remains unchanged: the generated component HTML must match the expected GOV.UK Frontend output. Simply making the pages look the same in a browser isn’t enough. The underlying HTML needs to follow the same structure, attributes, and conventions as the official components.

The fishing rod licence service returns

For consistency, I’ve reused the same fictional fishing rod licence journey from my original experiment. This includes the GOV.UK Design System components, familiar form patterns, validation, error handling, and the basic functionality required to complete the service.

The important point here is that users shouldn’t notice any meaningful difference between the COBOL implementation and one written in TypeScript, Java, Python, .NET, or any other backend language. The pages should look the same, forms should behave as expected, and users should be able to complete the journey without needing to know anything about the technology responsible for generating the HTML.

This is something, I believe, is essential when building government services. The majority of people accessing these services aren’t interested in whether developers have chosen the latest JavaScript framework, a traditional server-rendered application, or something considerably older.

Nobody visits GOV.UK thinking, “I really hope this page was rendered using a modern programming language, and works when JavaScript fails.” They just want an accessible service that works, lets them complete their task, so they can get on with their day. Preferably without an error message forcing them to start all over again!

And, just to reiterate the disclaimer from my original post, the fishing rod licence service is completely fictional. In the UK, you don’t need a licence simply to own a fishing rod. A licence is only required to actually fish with one. My example deliberately gets this wrong to make it obvious that it isn’t a real government service.

The last thing I want is somebody stumbling across one of these experiments and thinking they’ve discovered a new government policy. We’ve got quite enough of those already!

As you will see from the screenshot above, the resulting service looks incredibly similar to the services I created using the other 8 backend languages post, not surprising really! We are just rendering GOV.UK Frontend components after all! The browser doesn’t care that the backend language is older than 83% of the current UK population! Thank you to the Office for National Statistics for that striking statistic!

Using COBOL with GOV.UK Frontend

So, how exactly do you use a programming language from 1959 to build a modern government service?

Well, the underlying principle is surprisingly straightforward. An HTTP response contains a status code, headers, and a body. When that response represents a webpage, the body generally contains HTML. It doesn’t matter whether that HTML was generated by Express.js, Spring Boot, Django, or a COBOL application. Once the response reaches the browser, it’s processed in exactly the same way.

Of course, generating HTML is only part of building a web application, and this is where COBOL becomes rather more interesting.

Modern backend frameworks provide functionality that developers have come to expect, including routing, request handling, form processing, validation, sessions, error handling, and security features. COBOL was designed long before any of these became normal web development requirements. Although, to be fair to COBOL, the web hadn’t actually been invented yet. ’Tis but a minor technical detail! So implementing the surrounding application functionality can involve considerably more work.

Unlike TypeScript and Node.js, COBOL doesn’t have native support for the Nunjucks macros provided by GOV.UK Frontend. There also isn’t an official COBOL implementation of the Design System components, which means the rendering logic needs to be implemented separately.

I found writing the sentence above quite surreal and entertaining given how obvious it is that there’d be no support for Nunjucks and an "official COBOL implementation”. Maybe one should be added to the Design System Roadmap? 🤣

As with the other eight implementations, the approach is to follow the official GOV.UK Frontend component templates and generate the expected HTML using the chosen backend language. GOV.UK Frontend itself provides the CSS, fonts, assets, and JavaScript required for progressive enhancement, while the backend is responsible for generating the HTML that the browser receives, and serving these static assets.

The important distinction is that the backend doesn’t need to understand how GOV.UK Frontend works internally. It simply needs to produce the correct HTML, following the same structure and attributes as the official components. As long as the correct assets are also available, the browser can render and enhance the page in the same way it would for any other backend implementation.

This is where I think the experiment becomes particularly useful. COBOL doesn’t provide any special capabilities that make GOV.UK Frontend work, and there’s certainly no magic involved. It’s simply generating HTML, and serving static assets. Something that practically every general-purpose programming language is capable of doing!

The HTML is still the contract

The main point I wanted readers to take away from my original blog post was that the HTML generated by GOV.UK Frontend should be treated as a contract, regardless of which backend technology is used.

The same principle applies here.

GOV.UK Frontend includes ⁠HTML test fixtures that describe the expected output for its components. These fixtures provide a consistent way to verify that an implementation written in another programming language generates the same HTML as the official Nunjucks templates.

For example, the HTML for a GOV.UK button looks like this:

<a href="#" role="button" draggable="false" class="govuk-button govuk-button--start" data-module="govuk-button">
  Start now
  <svg class="govuk-button__start-icon" xmlns="http://www.w3.org/2000/svg" width="17.5" height="19" viewBox="0 0 33 40" aria-hidden="true" focusable="false">
    <path fill="currentColor" d="M0 0h13l20 20-20 20H0l20-20z" />
  </svg>
</a>

There’s nothing particularly complicated about this HTML, but it contains the structure, classes, and attributes expected by GOV.UK Frontend. The same output could be generated using TypeScript, Java, PHP, Python, Rust, or, as I’ve now demonstrated, COBOL.

If you are curious, this is the COBOL code for the same start button:

START-ENGLISH.
    STRING
        "<a href=""/licence-length"" role=""button"" draggable=""false"" "
        "class=""govuk-button govuk-button--start"" data-module=""govuk-button"">"
        "Start now"
        "<svg class=""govuk-button__start-icon"" xmlns=""http://www.w3.org/2000/svg"" "
        "width=""17.5"" height=""19"" viewBox=""0 0 33 40"" aria-hidden=""true"" "
        "focusable=""false""><path fill=""currentColor"" "
        "d=""M0 0h13l20 20-20 20H0l20-20z""/></svg></a>"
        DELIMITED BY SIZE INTO RES-BODY WITH POINTER BODY-PTR
    END-STRING.

For the fixture tests, the process remains the same as in my original experiment. Each test loads a GOV.UK Frontend fixture, renders the corresponding component using the backend implementation, and compares the resulting HTML against the expected output. If the HTML matches, the test passes. If it doesn’t, the test fails, allowing the developer to identify exactly where their implementation differs.

This approach is particularly important for languages that don’t have an established GOV.UK Frontend component library. Rather than manually recreating components and hoping they continue to work correctly, the fixture tests provide automated evidence that the generated HTML matches the official output.

Assuming the fixture tests are passing, the result is rather satisfying. A programming language first developed in 1959 can generate the same GOV.UK Frontend component HTML as a modern TypeScript application, with both implementations verified against the exact same fixtures.

There’s also an essential maintenance benefit here. GOV.UK Frontend continues to evolve with every new release, this includes new components, accessibility improvements, bug fixes, and changes to existing functionality. When a new version is released, the fixture tests can help identify where the COBOL implementation needs to be updated, rather than relying on some poor developer manually comparing HTML across every component, and fixture version (725 fixtures in all!)

Of course, passing the fixtures doesn’t automatically make an entire service accessible. GOV.UK Frontend provides an excellent accessibility foundation, but accessibility also depends on how components are combined, the content design, the entire user journey, and that the resulting service is tested with real users.

The responsibility for ensuring that a service's end-to-end user journey is accessible remains with the service team.

What about progressive enhancement?

As readers of my blog will probably know by now, I’m a massive fan of progressive enhancement (PE), particularly when it comes to building government services. And, rather predictably, the COBOL implementation follows the same principles as my other eight examples in my previous post.

For those unfamiliar with progressive enhancement, the idea is to start with a functional experience that works using HTML, then introduce JavaScript where it genuinely improves the user experience. If JavaScript fails, is disabled, or simply doesn’t load, the underlying service should still allow users to complete the task they came to do.

For a relatively straightforward government service, such as applying for a fishing rod licence, the majority of the journey can be handled using traditional server-rendered HTML and forms. Browsers already provide an enormous amount of functionality by default, including navigation, form submissions, keyboard interaction, and native accessibility semantics.

When building a new service or website, it's worth remembering that you don't need a JavaScript framework to recreate functionality the browser already provides for free! I've seen many frontend bootcamps jump straight into React, largely because of its popularity, without properly teaching the fundamentals of HTML, CSS, and JavaScript. My advice to anyone starting out in frontend development is simple: learn the web platform first, then move on to frameworks when there's a genuine need for them. More often than not, there isn't.

That’s not to say JavaScript or frontend frameworks are inherently bad. There are plenty of genuine user needs that justify additional frontend complexity, particularly when building highly interactive interfaces. I’ve previously written about ⁠progressively enhancing interactive maps for UK government services, where JavaScript can significantly improve the experience while still providing an appropriate fallback.

But for a fairly typical form-based government service, the requirements are often considerably simpler. And if COBOL can generate the HTML required to build that service, perhaps it’s worth questioning whether some of the additional frontend complexity we’re introducing is actually necessary.

Again, I’m not suggesting COBOL is the answer. Quite the opposite! What I’m trying to demonstrate is that the browser doesn’t require a particular backend language or client-side framework to provide a modern, accessible experience.

What is COBOL?

Now that we’ve covered the experiment itself, it’s probably worth exploring COBOL in a little more detail, particularly for readers who have never encountered the language. I included myself in this camp before I came up with this ridiculous idea for an experiment / blog post!

⁠COBOL, which stands for Common Business-Oriented Language, was first developed in 1959. That makes it 67 years old in 2026, which is quite remarkable when you consider how much software development has changed during that time.

For some perspective, COBOL was developed four years before the first episode of Doctor Who aired, ten years before humans landed on the Moon, and more than three decades before the World Wide Web became publicly available.

It was designed primarily for business, financial, and administrative systems, particularly those involving large amounts of structured data and transaction processing. Unlike many modern programming languages, COBOL uses an English-like syntax intended to make programs relatively easy to read and understand.

For example, here’s a simple COBOL program that outputs “Hello, world!”:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO-WORLD.

       PROCEDURE DIVISION.
           DISPLAY "Hello, world!".
           STOP RUN.

Yes, that’s a real programming language, and yes, people are still being paid to maintain applications written in it!

COBOL became particularly popular with banks, insurance companies, government departments, and other large organisations that needed reliable systems for processing financial transactions and administrative information.

Many of these systems have continued operating for decades, often because replacing them would be expensive, complicated, and potentially risky. As seen in the research and analysis paper I linked to earlier in the post related to HMRC’s use of COBOL. In some cases, organisations have modernised the infrastructure surrounding their COBOL applications rather than replacing the applications themselves.

And when you think about it, that isn’t necessarily a bad decision. Rewriting an application that has been processing critical transactions for decades introduces its own risks, particularly when the original developers have long since moved on, in some cases to a better place, and the documentation might be somewhat lacking.

However, there’s an important distinction between maintaining an existing COBOL system and deciding to use COBOL for an entirely new application. Just because a language has been around for decades doesn’t automatically make it the most appropriate choice for modern development.

How mature is COBOL?

I’m not entirely sure this question needs answering, given that COBOL is now 67 years old!

It’s one of the oldest programming languages still used in production, with a history stretching back to the earliest days of commercial computing. Its longevity is quite extraordinary, especially when you consider how many programming languages, frameworks, and development tools have appeared and disappeared during the same period.

But despite its age, COBOL hasn’t completely disappeared. Far from it, in fact. It’s still used within banking, insurance, financial services, and government, particularly in organisations that continue to operate large enterprise and mainframe systems.

What’s also interesting is that COBOL itself continues to be maintained and developed. Projects such as ⁠GnuCOBOL provide open-source compiler support for modern operating systems, while the ⁠GNU Compiler Collection (GCC) introduced a COBOL frontend in GCC 15 during 2025.

So, despite being developed in the 1950s, COBOL is still receiving attention from developers and compiler maintainers today. That’s quite an achievement for a language that predates the World Wide Web by several decades.

However, there’s an important distinction I’d like to make here: language maturity and ecosystem maturity are not the same thing.

COBOL is unquestionably mature as a programming language, with decades of proven production use. But when it comes to modern web development, its ecosystem is considerably smaller than those of TypeScript, Java, Python, PHP, or the other languages included in my original experiment.

Modern backend frameworks generally provide established solutions for routing, templating, sessions, authentication, security, testing, and deployment. COBOL doesn’t have the same breadth of readily available web development tools, which means building and maintaining a modern service would require considerably more effort.

There’s also the question of finding developers with the appropriate skills. While COBOL remains essential within established enterprise systems, recruiting developers who are familiar with both COBOL and modern web development practices is likely to be more challenging (if not impossible) than recruiting developers with experience in mainstream backend languages.

I’m not sure whether I really need to say this but while COBOL is exceptionally mature, that doesn’t automatically make it a sensible choice for building a new government service.

How popular is COBOL today?

Popularity was one of the metrics I examined in my original article, so it seems only fair to apply the same scrutiny to COBOL. And this is where things become particularly interesting.

According to the ⁠2026 Stack Overflow Developer Survey, just 1.1% of respondents reported using COBOL for extensive development work during the previous year. That’s 150 developers out of the 14,099 respondents who answered the programming languages question.

For comparison, the same survey reported the following usage across the eight languages included in my original experiment, alongside COBOL:

That’s quite a contrast, particularly when you consider that COBOL has been around considerably longer than any of the other languages in the table.

Even Ruby, which has relatively low usage compared with languages such as Python and TypeScript, was reported by more than five times as many developers as COBOL.

However, there’s an important distinction to make here, and it’s one I’ve tried to emphasise throughout my original article: popularity doesn't equal suitability.

The Stack Overflow survey provides useful insight into which technologies developers report using, but it doesn’t necessarily tell us how much software is running on those technologies in production. This is particularly relevant to COBOL, where many of the systems still in operation were developed decades ago and continue to be maintained within large organisations.

These environments may not be particularly well represented in a survey of contemporary developers, so it would be misleading to interpret the 1.1% figure as evidence that COBOL is responsible for only a tiny proportion of production workloads.

In fact, COBOL’s continued relevance is closely tied to the enormous number of established systems that organisations still depend on. Unlike modern programming languages, its continued use isn’t driven by developers selecting it for new projects, but by the long-term maintenance and operation of existing applications.

This makes COBOL an interesting example of the difference between developer popularity and software longevity. A language can fall out of favour while the systems built using it continue operating for decades. I’m sure many developers have experienced this when joining a new company, arriving bright-eyed and bushy-tailed, only to discover the legacy systems nobody dares touch. And more often than not, there’s a reason they’re still there, usually involving internal politics, competing priorities, and the uncomfortable reality that replacing something that works isn’t always worth the risk. I’d imagine many COBOL systems today fall squarely into this category!

And that’s something I think we should consider more carefully when making technology decisions, particularly within government.

Once a government service goes live and both staff or citizens rely on it, replacing or decommissioning it can become incredibly difficult. Some services remain operational for years, even decades, and the technologies chosen today could still be somebody else’s responsibility long after the original development team has moved on.

COBOL is perhaps one of the best examples of this. It’s either an extraordinary testament to the longevity of well-established software or a slightly concerning reminder of how difficult replacing critical systems can become.

In my opinion, it’s probably a bit of both!

Advantages and disadvantages of COBOL for GOV.UK services

As with the original eight backend implementations, I think it’s worth examining the advantages and disadvantages of using COBOL for a modern government service. Although, having built the example, I suspect the disadvantages might be a little more substantial than the advantages!

Advantages

• Extremely mature language: COBOL has been used in production systems for decades, particularly in banking, financial services, insurance, and government.
• Proven longevity: Existing COBOL applications demonstrate that software can remain operational for extraordinarily long periods, although maintaining those applications can introduce significant challenges.
• Modern compiler support: Projects such as GnuCOBOL and GCC’s COBOL frontend demonstrate that the language can still be compiled and executed on contemporary systems.
• Server-rendered HTML: COBOL can generate the HTML required by GOV.UK Frontend without requiring any client-side frontend framework.
• Predictable HTML output: Automated fixture tests can verify that COBOL-generated components match the expected output from GOV.UK Frontend.

Disadvantages

• No official GOV.UK Frontend integration: Components need to be implemented separately, following the official Nunjucks templates and HTML fixtures.
• Limited modern web ecosystem: COBOL doesn’t have the same range of web frameworks, templating libraries, and development tools available in languages such as TypeScript, Java, and Python.
• Additional application complexity: Common web development functionality, including routing, validation, sessions, and security features, may require additional supporting infrastructure or custom implementation.
• Component maintenance: Keeping native COBOL components aligned with future GOV.UK Frontend releases requires ongoing development and automated testing.
• Smaller developer community: Finding developers with COBOL experience, particularly those familiar with modern web development, is likely to be impossible.
• Frontend developer experience: Working directly with HTML generation in COBOL is unfamiliar for any member of a modern government service team, where developers and UX designers normally work with modern template engines.
• Additional build tooling: GOV.UK Frontend’s Sass, JavaScript, and other assets still need to be managed alongside the COBOL compilation and deployment process, a dual stack of old and new spanning almost 70 years!
• Long-term maintainability: Introducing COBOL into a new government service would simply break any recruitment process, operational support, knowledge sharing, and future maintenance.

Looking at that list, I think it’s safe to say that COBOL won’t be replacing TypeScript, Java, or Python in most government development teams anytime soon. Or ever, for that matter. And nor should it! Although I must admit, I’d be fascinated to know the average age of the COBOL developer community. I suspect a fair few have been maintaining the same systems since before some of their colleagues were born!

However, the purpose of this experiment isn’t to demonstrate that COBOL is a better backend choice than the other eight languages. It’s to again demonstrate that the browser doesn’t impose those choices on us. We make them ourselves, and those decisions should be based on the needs of the service, the organisation responsible for it, and, most importantly, the staff or citizens who use it.

Does this mean COBOL is suitable for modern government services?

Let’s be clear, No, it isn't.

Although I appreciate that probably deserves a slightly more detailed explanation!

There’s a significant difference between demonstrating that a technology can do something and recommending that organisations should use it. COBOL has an extraordinary history, and there are perfectly legitimate reasons why organisations continue to maintain applications written in it. Replacing critical systems simply because the programming language is considered old would be a rather questionable approach to modernisation. What matters is whether those systems remain secure, maintainable, cost-effective, and capable of meeting the needs of their users.

That doesn't mean we should simply leave ageing systems alone, either. As I mentioned in my previous post, Government Digital Service (GDS) is actively coordinating work to identify, manage, and modernise legacy technology across government. This includes the Roadmap for Modern Digital Government, plans for upgrading outdated systems in critical public services, and work to better understand government's existing technology estate. Interestingly, GDS also published an updated definition of legacy IT in August 2026, which focuses on the risks and burdens associated with maintaining a system rather than simply its age or the technology it uses. And that's really the point: modernisation should be driven by genuine risks, costs, and user needs, not simply because something was written in a language that predates the moon landing!

However, building an entirely new government service presents a different set of considerations. Beyond generating HTML, service teams need to think about security, deployment, observability, automated testing, dependency management, operational support, and the ability to recruit developers with the appropriate skills.

These are all important factors when choosing a backend technology, particularly in government, where services may need to operate for many years and continue to be maintained long after the original developers have moved on.

In my original article, I explored why picking the right backend is a long-term commitment. What seems modern today can quickly become legacy, and in government, legacy has a habit of sticking around for a very long time!

This is why I think the distinction between popularity, maturity, and suitability is so vital. COBOL is exceptionally mature, has a long history of production use, and remains relevant within established enterprise systems. However, none of those things automatically make it the right choice for a new government service. At the other end of the spectrum, choosing a language simply because it’s modern, popular, or familiar doesn’t necessarily make it suitable either.

We should be asking more practical questions about the skills already available within the organisation, the infrastructure, and security processes already established, the actual requirements of the service, and the developers who will eventually inherit the application.

And above all, we should be choosing technology that meets the needs of the service and its users, rather than introducing complexity simply because we can.

COBOL GOV.UK Frontend example

As with the original eight backend implementations, I’ve made the COBOL example available for anyone interested in exploring how it works. The repository contains the fictional fishing rod licence service, the GOV.UK Frontend component implementations, and the automated fixture tests used to verify the generated HTML.

You can find all the associated resources below:

• GitHub repository: COBOL-Frontend
• Live example service: Fishing rod licence service
• GOV.UK Frontend component examples: All GOV.UK Frontend 6.6.0 components
• Important: As mentioned in the original post: These demos are hosted on Render's free tier, so the first request after a period of inactivity may take around 50 seconds while the service starts up, this cold-start time has nothing to do with the COBOL backend.

As with the other implementations, this is an experimental example intended to demonstrate what’s technically possible, rather than something I would recommend deploying into production. You’re more than welcome to fork it, experiment with it, and adapt it for your needs, but please don’t blindly deploy it into a live government service! If you do find yourself seriously considering using this example in production, please get in touch. I’m more than happy to offer some free technology therapy, as I suspect there are rather more pressing issues we ought to discuss first!

In my original post, I described the eight repositories as little sourdough starters for government services. With a little love and ongoing maintenance, they could potentially develop into something considerably more useful. I’m not entirely sure that analogy works quite as well for COBOL. This particular starter is 67 years old, and I’m pretty sure nobody should be eating it!

What have I actually demonstrated?

When I started the original experiment, the aim was to demonstrate that GOV.UK Frontend doesn’t require a particular backend language or modern frontend framework, in order to use it. Eight different implementations seemed like a reasonable way to prove that, particularly when each could generate the same HTML and be tested against the official GOV.UK Frontend fixtures.

COBOL takes that argument a little further, perhaps to a slightly ridiculous conclusion!

By using a programming language first developed in 1959, I’ve demonstrated that the ability to generate modern HTML isn’t inherently tied to the age, popularity, or perceived sophistication of the backend technology.

The browser doesn’t care whether the HTML was generated using a language released last year or one developed before humans landed on the Moon. It simply receives the HTML, CSS, and JavaScript, and processes them according to established web standards. And that’s one of the remarkable things about the modern web. We’ve spent decades developing and refining open standards that allow browsers to reliably interpret content, regardless of the technology used to generate it.

While the web has evolved enormously since its early days, COBOL has quietly carried on doing what it’s always done: reliably processing data, largely unconcerned with whatever the rest of the technology industry happens to be excited about this week. And since I made a J. R. R. Tolkien reference in my previous post, it seems only fitting to make another here. Tolkien’s The Lord of the Rings was first published between 1954 and 1955, just four years before COBOL was created in 1959.

In The Fellowship of the Ring, Bilbo describes life in the Shire as a place where change comes slowly, “if it comes at all.” In many ways, COBOL is rather like the Shire. While the rest of Middle-earth has been busy fighting wars, forging rings, and generally making a terrible fuss, life in the Shire has carried on much as it always has. Meanwhile, languages, frameworks, and entire computing platforms have come and gone, but somewhere, in a government department or financial institution, COBOL is still quietly processing transactions as it has done for decades. Much like the Hobbits, it probably wonders what all the fuss is about.

Of course, this doesn’t mean that every backend language is equally suitable for building a government service. Some languages and frameworks provide considerably better tooling, security features, developer experience, and long-term maintainability than others. Those differences matter, especially when you’re building services that millions of people may eventually depend on.

But I think it’s important to separate the technology responsible for generating the HTML from the frontend experience that users actually receive.

One of the most valuable aspects of the GOV.UK Design System is that it provides a single common foundation for building accessible and consistent government services, regardless of the technology used "behind the scenes".

It also allows departments and service teams to choose backend technologies that best suit their organisation while benefiting from a shared frontend foundation. Crucially, improvements to the Design System can then benefit users across a wide range of government services, regardless of the technology used to build them.

And that’s considerably more important than whether the backend happens to be written in TypeScript, Java, Rust, or, somewhat improbably, COBOL.

Summary

When I published my original article about building UK government services using eight different backends, I wanted to demonstrate that choosing a backend technology and choosing how to build the frontend don’t necessarily need to be the same decision.

GOV.UK Frontend provides the HTML patterns, CSS, assets, and JavaScript needed to build consistent, accessible government services. As long as the backend can generate the correct HTML, it doesn’t need to use Node.js, Nunjucks, or any frontend framework.

The COBOL experiment takes that principle a little further by using a programming language that’s now 67 years old, and one that nobody would reasonably recommend as the starting point for any new government web service.

But despite its age, COBOL can still generate the HTML required by GOV.UK Frontend. It can serve the same familiar Design System components, support traditional server-rendered journeys, and have its output verified against the same HTML fixtures used by considerably more modern backend implementations.

That doesn’t mean COBOL is a good choice for new government services. In fact, the experiment demonstrates some fairly compelling reasons why it isn’t! What it does show is that modern frontend experiences aren’t dependent on modern backend languages, and that the browser itself places remarkably few restrictions on the technology responsible for generating its HTML.

As developers, we have an enormous selection of programming languages, frameworks, libraries, and tools available to us. Some are genuinely useful, some solve very specific problems, and others introduce complexity that might not be necessary for the service we’re building.

Rather than choosing technology because it’s popular, familiar, or considered “modern", we should be asking whether it actually solves a problem for the service, the organisation, and, most importantly, its users.

And if there’s one thing I hope readers take away from this slightly ridiculous addition to my original experiment, it’s this:

If a programming language from 1959 can generate the HTML required for a modern government service, perhaps the more interesting question isn’t what technology we can use, but how much technology we actually need.

Anyway, I think this ninth backend implementations is quite enough for one experiment. Although I have started wondering whether you could build a UK government service using Microsoft Excel. Given how much of government already runs on spreadsheets, it seems like it could be a perfectly natural progression!

As always, thanks so much for reading. I hope you enjoyed this rather unusual experiment as much as I enjoyed creating it. Feedback, comments, suggestions, and corrections are always more than welcome, so please do ⁠let me know! If you spot anything I’ve got wrong, I’ll happily correct it and credit you in the post changelog below.

Post changelog:

• 20/10/26: Initial post published.