1. Home
  2. Innovation Funding Service
An abstract pattern of concentric arcs radiating from the top-right corner, suggesting reach and scale, fading into deep blue.

The platform behind Innovate UK’s grant competitions

The Innovation Funding Service is how Innovate UK runs its grant competitions — from application, through independent assessment, to awarding and setting up the funded project. We were among the engineers who built it.

The live Innovation Funding Service on GOV.UK: the public ‘Innovation competitions’ listing showing open funding competitions such as Future Leaders Fellowships, with a keyword and innovation-area filter sidebar.

The live service on GOV.UK — the public listing of open innovation-funding competitions. See it on GOV.UK →

A national service, in the open

Innovation Funding Service is the GOV.UK digital service that businesses use to apply for innovation funding from Innovate UK, part of UK Research and Innovation. A competition runs through it end to end: applicants submit, independent assessors score, Innovate UK staff manage the competition and the money, and successful applicants are taken through project setup and finance checks. It handles a lot of public money, so it has to be correct, auditable and accessible.

It’s also open source, built in the open under the MIT licence — which means our contribution to it is a matter of public record, not a claim you have to take on trust.

What “we built it” actually means

Honesty first: nobody built the Innovation Funding Service alone. It was made by dozens of engineers across several supplier teams, over years; the public history shows seventy-six contributors. But one of us was among its most active: more than 2,200 commits — sixth of those seventy-six contributors — over roughly three and a half years (2016–2020), working across the whole system rather than one corner of it.

The contribution, on the record

Every figure here is checkable against the public repository: 2,200+ commits from one engineer, 6th of 76 contributors, across a Spring Boot codebase of sixty-odd modules plus the GOV.UK front end and a large acceptance-test suite. See the commits →

How it’s built

IFS is a Spring Boot microservices system of sixty-odd Gradle modules, running on Kubernetes. The front end is a set of journey-specific web applications built to the GOV.UK Design System: one for applicants, one for assessors, others for competition management and project setup. They all talk to a central data service over REST, which owns the domain model and persists it to a MySQL database with Flyway-managed schema migrations. Around them sit supporting services — registration and authentication, file storage, and stubs for the external systems IFS integrates with.

Applicants, assessors and Innovate UK staff use journey-specific GOV.UK web applications, which call a central data service over REST; the data service persists to a MySQL database, alongside registration, file-storage and integration services. Applicants Assessors Innovate UK staff Web front ends GOV.UK · per-journey apps Registration & authentication Data service REST API · domain model File storage Integrations MySQL + Flyway migrations
Spring Boot microservices on Kubernetes: GOV.UK journey apps call a central data service over REST, which owns the domain model and persists to MySQL — with registration, file storage and external integrations alongside.

That “web front ends” box is really several separate applications — one per journey — so each part of the service can evolve on its own while sharing the same data service and domain model underneath.

Five GOV.UK web applications — front door, application, assessment, competition management and project setup — each call the same central data service, which persists to MySQL. Front door discovery Application applicants Assessment assessors Competition management Project setup post-award Data service REST · domain model MySQL + Flyway migrations
A separate GOV.UK web application for each journey — discovery, applying, assessing, running a competition, project setup — all sharing the one data service and MySQL database.

What we worked on

The commits span the full width of the service — data model and migrations, REST services, controllers and view models, the GOV.UK front end, and the security rules that decide who can see and do what. They also span the full life of a competition:

The life of a funding competition: Innovate UK opens it, applicants apply, independent assessors score, a funding decision is made, and successful applicants go through project setup. Competition Innovate UK opens Application applicant submits Assessment assessors score Award decision & offer Project setup eligibility & finance
The life of a competition, from Innovate UK opening it to a funded project getting under way — the commits touch every stage of it.

In particular, that work concentrated on:

  • Assessment — the workflow that gets applications in front of independent assessors and tracks their status and scoring.
  • Project setup & finance — taking a successful applicant through funding levels, eligibility and viability checks before public money is committed.
  • User management & access control — managing internal and external users and the fine-grained permission rules that govern them.
  • Competition setup — the configuration that lets Innovate UK staff stand up and run each new funding competition.

It was rigorous work: feature branch per ticket, peer-reviewed pull requests, and a deep automated-test safety net — unit, integration, controller-documentation and full RobotFramework acceptance tests — because a service moving public money doesn’t get to guess.

From Innovate UK to all of UKRI

Innovate UK is part of UK Research and Innovation, which has since built a newer grant platform, The Funding Service, serving funders beyond Innovate UK. Two of us have worked on that as well, across 2021–2023. It is a different shape of system built to the same GOV.UK standards.

That work went deep as well as wide: performance engineering against production-like load until the service held its target, and streamlining how its databases are migrated so clean builds stopped costing developers their morning.

Why it matters

This is the kind of system we like: large, long-lived, consequential, and held to a high bar for correctness and accessibility because real people and real public money depend on it. Building at that standard — in the open, on a big team, to GOV.UK’s service expectations — is exactly the experience we bring to the work we do now.

Got a service that has to be right at scale? Let’s talk.