There is a piece of government infrastructure sitting underneath a remarkable number of UK digital products, and most of the people using it have never stopped to think about what happens if it goes away. GOV.UK Notify, the Cabinet Office’s free API for sending SMS, email and letters, has quietly become load-bearing for thousands of services since it launched in 2016. If you have ever received an NHS appointment reminder, a council tax alert, or a Companies House filing notification, there is a good chance Notify sent it. What is less obvious is how many private-sector startups and scaleups have built the same dependency into their own products.
I have spoken to product managers at three different UK SaaS companies in the past few months, and every one of them mentioned Notify in passing, almost as an afterthought. That casualness is precisely the problem. When something is free, reliable and well-documented, it tends to get adopted without the kind of vendor assessment you would run on a paid supplier. And when you skip that assessment, you skip the part where someone asks: what is our contingency if this goes down, or gets deprecated, or changes its terms?
What GOV.UK Notify actually does, and why teams reach for it
Notify is operated by the Government Digital Service (GDS) and is genuinely excellent. The official documentation is clear, the client libraries cover Python, Ruby, Java, .NET, Node.js and PHP, and the service has a 99.9% uptime SLA backed by GDS infrastructure. For a startup that needs to send transactional notifications without wiring up Twilio or Mailgun and absorbing the cost, it is an almost irresistible default.
The usage data tells its own story. As of early 2026, Notify has sent over 10 billion messages across more than 11,000 services. The majority are public sector, but a significant and growing tail are third parties building on top of public data or delivering services adjacent to government. Think: identity verification tools, legal tech platforms automating client communications, grant management software, social housing portals. The pattern is consistent. A team discovers Notify during a GDS hackathon or a procurement discovery phase, integrates it in an afternoon, and six months later it is the backbone of their entire notification layer.
The risk profile most product teams are not measuring
Single points of failure in notification infrastructure are not exotic engineering problems. They are boring ones that bite hard. The GOV.UK Notify dependency introduces a specific flavour of risk that does not always get captured in standard dependency audits.
First, there is the service continuity question. Notify is a government service, which means its existence is subject to spending reviews, machinery-of-government changes, and the political appetite for maintaining developer tooling. GDS has had its budget trimmed before. Notify itself has not been deprecated, but the institutional memory of what happened to some earlier GDS projects (Verify being the most instructive case) should prompt a realistic conversation about what a wind-down scenario would look like. GDS has given no indication Notify is at risk, but product teams should not need a wind-down announcement before they build an abstraction layer.
Second, there is the eligibility constraint. Notify is meant for services that are delivering or supporting a public service. The terms are relatively broad, but they are not unlimited. If your product pivots away from that framing, or if GDS tightens its eligibility criteria in a future policy cycle, your access could be reviewed. I have seen one company get a gentle query from GDS about their use case when they moved upmarket. It resolved fine, but it was a reminder that you do not own your position on the platform.
Third, and most practically, there is the rate limiting and sending limits architecture. Notify imposes daily sending limits that scale with your service tier and require a formal request to increase. For a company that has grown quickly, those limits can become a ceiling during high-traffic periods, such as bulk reminders, annual renewal campaigns, or emergency communications. Teams that have not stress-tested their limits against realistic peak scenarios tend to find out about them at the worst possible moment.
How UK startups are actually handling this
The smarter teams I have talked to treat Notify as the primary channel behind an abstraction layer, not as the direct integration target. The pattern looks like this: build a thin internal notifications service that accepts a message type and recipient, then routes it through Notify by default. The routing logic can be updated independently of the product. If Notify is unavailable, the abstraction layer fails over to a commercial provider. The additional cost of the commercial provider sits idle most of the time, but the resilience is worth it.
This is not a complex architecture. It is the same pattern you would apply to any critical third-party dependency, and it is the same logic that drives good engineering teams to avoid hard-coding any single supplier into their core flows. The discipline required is the same discipline that separates a robust product from a fragile one. I have written before about how UK legal tech platforms are applying this kind of thinking to their automation stacks; the legal tech firms automating junior solicitor workflows that are doing it well tend to be the ones that treat every third-party dependency as a temporary relationship, not a permanent fixture.
For teams building adjacent to government data, the broader compliance context matters too. The ICO has been increasingly attentive to how notification data is handled, and if you are sending health or benefit-adjacent communications, the data classification requirements are non-trivial. The work coming out of the ICO’s current audit programme is relevant here, particularly around documenting data flows through third-party APIs that you do not control.
What the public sector can teach private teams about dependency management
There is an irony in all of this. The public sector bodies that were Notify’s original audience tend to have more formal processes around supplier risk than the startups that adopted it later. NHS trusts and local councils generally run their technology through procurement frameworks that require documented exit strategies. A Series A startup does not have the same governance overhead, which is part of why the dependency sneaks in unchallenged.
The practical fix is not complicated. Add Notify to your dependency register the same way you would add any SaaS supplier. Document your sending volumes, your peak scenarios, and your fallback path. Make sure your contract or terms review includes a check on Notify’s eligibility criteria against your current business model. If you are using Notify to send communications on behalf of third parties, be explicit about whether that use case is within scope.
Some teams are also starting to think about this through the lens of operational resilience frameworks, particularly those touching financial services or health tech where the FCA or NHS Digital have views on notification infrastructure. The compliance-by-design approach that the more mature UK fintechs have adopted is worth borrowing here: build the resilience in from the start rather than retrofitting it when a regulator or a customer incident forces your hand.
There are good resources for exactly this kind of outreach. Communities like 0lly illustrate how much civic-facing digital work relies on free government tooling, and the dependency patterns are strikingly similar whether you are a grassroots project or a Series B company. The underlying question is always the same: what is your plan if the free thing stops being free, or stops being available?
GOV.UK Notify is good. GDS built something that genuinely works and has meaningfully lowered the cost of digital government in the UK. But good infrastructure and dependable infrastructure are not the same thing, and treating a government API like a permanent utility without a contingency plan is an engineering debt that tends to compound quietly until it does not.