Somewhere in the work of getting a child the free school meals they are owed, a council becomes a buyer of software. So does a hospital. So does a central department a thousand times its size. None of them set out to be in the technology business; they set out to do right by the people they serve, and the buying came as part of the freight. What has quietly become true and that almost nobody has priced: the kit all of them need has become as ordinary as electricity, while the ability to get it on fair terms has not. The components have commoditised. The access to them has not. That gap is the problem, and it is a good problem, the kind worth a few years of a working life. It got mine.
The National Digital Exchange was built to close it. A real, ministerially backed attempt to change how the public sector buys and shares technology, built in the open from the first commit, with a working part you could actually pick up and use. It is being switched off today. That is also my last day at the Government Digital Service. I am writing this down now, on the day rather than after it, for one reason: so the idea, and the people who put real belief behind it, are not switched off along with the platform. The code outlives it. The problem certainly outlives it. This is the thread between them, left where the next person can find it.
So let me start with the problem, not the programme, because the problem is the durable part.
Government buying is rarely one thing. It tends to be a long chain of forms, frameworks, due-diligence questionnaires and waiting, stitched across departments that were never designed to act as one buyer. A council team trying to help vulnerable children get the free school meals they are entitled to is, somewhere in that work, a buyer of software. So is a hospital. So is a central department with a thousand times the buying power, on terms the council will never see.
There is a useful phrase for the version of this that citizens feel, the "administrative burden": the cost to people of dealing with the state, in forms, in waiting, in proof-gathering, a lens Richard P. , on the founding team of GDS, has applied to public services. Public-sector buying has its own administrative burden. It tends to fall hardest on the bodies with the least time to spare, and reducing it is what NDX was for.
There were three places I started from. None needs a public source; they are how I saw it from where I stood, and, I think, where the next person will have to start too.
The first start: demand without a way to buy
People tend to need to experience a thing before they will commit to it. So I built NDX:Try, the one part of the platform that ever went live: a free, no-commitment cloud sandbox, an isolated working environment a public-sector buyer could stand up in minutes, use to evaluate a product hands-on, and have wiped clean afterwards. A local authority could try something for real, with no obligation to buy. The compute behind it was paid for by a cloud vendor, treated as a pre-sales environment.
It worked, in the narrow sense: it created demand. Users started building. Suppliers started readying products to be tried. Letting people hold a thing in their hands could turn a vague interest into a concrete intention, and often did.
But demand is not the same as a solved problem. A few weeks ago I wrote that for anything in public procurement there was no fast lane yet, only a road we were still pouring, and that it was nearly here. I believed that when I wrote it. The load-bearing word was the one in the bracket: a sandbox makes a thing legible, lets you see it and try it, but legibility does not make anyone able to buy it. NDX:Try proved the appetite and handed everyone back to the same chain of frameworks and forms they came from. That is not a failure of the sandbox. It is the shape of the whole problem: you can let a thousand councils try a thing and still leave every one of them unable to acquire it without re-running the slow machinery from scratch. The procurement problem is exactly as unsolved this evening as it was the morning NDX:Try went live.
A sandbox is not a destination
When I built NDX:Try, I made a quiet assumption that turned out to be wrong: that access was the gift. Give a council a clean cloud account, no commitment, the bill paid for, and the rest would follow. It did not. An empty cloud account may be one of the more underwhelming things you can hand someone. It is an empty room. They came for a kettle and you have handed them a deed of access. What people connect with is a thing they recognise, close enough to their own work that they can see themselves using it by Friday.
So the more useful thing NDX:Try did was not the sandbox. It was what we put in it: ready-to-run scenarios built on real, open-source public-sector software that already existed and was already good. That part I can take little credit for, and I would rather name the people who can.
There is LocalGov Drupal, the open-source publishing platform built collaboratively by UK councils and now trusted by more than fifty of them, so a council need not pay a vendor to rebuild what its neighbour already runs. There is LocalGov IMS, the open-source income management system councils use for payments like council tax, business rates, parking and rents, with GOV.UK Pay integration. There is Minute, the transcription and minutes tool from the government's own incubator for AI, i.AI. There is PlanX for building planning services and BOPS for processing the applications, both from the Open Digital Planning community. And there is Paperless-ngx, the open-source document-management project, patiently filing the buff-folder mountain every public office still keeps. None of this was waiting to be invented. It was waiting to be tryable, which is a much smaller and more answerable problem.
It also let me ship demos that were genuinely impressive rather than merely plausible. The one I am proudest of is an AI contact centre (public walkthrough here, source in the open like the rest). It stands up a real, callable UK phone number with an AI front door that can answer and route a caller in whatever languages you need; the demo ships with six, English, Italian, French, German, Spanish and Polish, which is at least five more than I manage on a good day. You can edit the voice menu live, save it, dial back in, and hear the change you just made. You could call it. It was a demonstration, never a service put in front of the public; not the diagram of a contact centre, but a phone that rings, configured and reshaped in well under an hour, against the six to nine months it tends to take to buy almost anything (the timeline I come to under "batteries included"). Minutes, not months. I wrote up two of these scenarios as they went out: when a council CMS gets a brain, and teaching a computer British Sign Language.
But the point of a demo that works is not the demo. It is whose hands it lands in: a stretched council team, given something genuinely impressive they can touch rather than be shown. When these went out, the reaction I cared about was never "clever demo." It was "wait, I could use that." The technology has often been ready for a while; the access to it has not.
Rapidly deployable templates only help if you already have a cloud account and the freedom, the skills and the budget to experiment in it. Most people do not. Most organisations do not. The ability even to try a thing turns out to be a privilege, distributed about as evenly as privileges usually are, and it may be quietly ruinous for every council to keep acquiring it alone, one expensive setup at a time. This is not the batteries-included point, which is about the bought product arriving configured; this is the layer beneath it. NDX would have done the undifferentiated groundwork once, for everyone, the boring setup shared rather than the choices narrowed, so the recognisable destination, and not the empty room, was what a council reached first.
The CloudFormation templates I built, the scripts that stand each scenario up, are public like everything else I made, so anyone can still redeploy them. The open-source tools they point to certainly outlive NDX, and were never mine to begin with.
The second start: the divide that does not show up in the meeting
The second start mattered most to me.
If you run a small council team trying to do right by children at risk, you buy the same kinds of cloud and software as a central department, but rarely on the same terms. You cannot generally get the price, nor the technical support. The better deal the large department gets is not a favour; it is the arithmetic of scale, and the same arithmetic that earns the big buyer its terms is what denies them to the small one. The disadvantage of the council is the advantage of the department, seen from the other end.
The divide runs both ways. On one side, the council that cannot reach central government's price. On the other, suppliers with genuinely strong offerings for local government who could not afford to reach those councils, because the cost of finding and winning each small customer made the model unviable. More than three hundred councils, each procuring separately, is not a market a good small supplier can easily afford to serve. So the council that needs the thing and the supplier that built it tend never to meet, not for lack of will, but because the road between them was never built.
That is not a new shape. The household means test in the 1930s, the assessment of household income for anyone claiming the dole, pushed the entire cost of proving eligibility onto the household, the people least able to absorb it, and called the result administration. A council buying software is a long way from a family at the dole office, but the design fault may be the same: the burden lands where it is least affordable, and being unaware you have created a burden does not make it any lighter for the people carrying it. Large buyers are often unaware of the cost their scale imposes on smaller ones, the way a fish is unaware of water. I have made this argument before, more than once. I am making it again today, because the problem it names has outlived the thing built to answer it, and will outlive me too.
NDX was an attempt to redesign that, sketched in the open as four parts beyond the sandbox, each still a prototype. The NDX:Catalogue was a browsable directory where any public body could discover and compare cloud, AI and government products in one place, the way you can already see a food-hygiene rating on Just Eat before you order. The NDX:Challenge space would let departments publish their real problems in plain sight, a public problem-book, so a supplier could see a genuine need before building for it. The NDX:Campaign space would pool demand the way a crowdfunder does, letting bodies pledge to use a thing so a supplier could see proven appetite before building it. And a guided flow I called Assist would let you describe a problem in plain English, the free school meals a child is entitled to, say, and walk you from that sentence to a plain list of the services you would need. The public record names NDX:Assist without describing it; what I am describing is the guided demo there to see in the open repository. But the real reason NDX:Assist existed was that a NDX:Catalogue which succeeds becomes large, and a large catalogue is hard to browse; you only need a guide when there is enough to get lost in, so I built the guide early, while there was almost nothing to get lost in yet, as a bet that one day there would be.
None of the richer parts, the reviews, the ratings, the AI supplier-matching, the nationally negotiated deals, were live. Most were stated openly as where the platform could go, not where it was. I never claimed otherwise. The point is not what NDX had finished. It is that the divide it was built to close is still wide open.
The third start: who moved first
I assumed that if any cloud vendor put real money behind letting the public sector try things for free, it would be a smaller player with first-mover advantage to gain and less to lose. It was not. Amazon Web Services moved first. They funded the compute that made NDX:Try free for a council to use, and they deserve the public credit, with other vendors and services coming in behind them. To be clear, that paid for free trial compute and nothing else: no preferential place in the Catalogue and no say over the platform, which was built to compare vendors against each other, not to favour one.
I record it because it may tell the next person something useful: the appetite to fix this exists in the market, not only in government. What is missing is not will. It is the road that turns a council's need, a supplier's offer and a vendor's goodwill into something a public body can actually acquire without months of separate effort.
It was not only the home market that noticed. Delegations from other governments asked to see how NDX worked, and the questions they came with were often the same ones a stretched UK council brings: how do you let people try a thing, how do you make the money move, how do you stop everyone rebuilding the same foundation alone. I take that less as a compliment to NDX than as confirmation the problem is not a British peculiarity. The same divide, commoditised components and uncommoditised access, tends to show up wherever the public sector buys, which may mean a model that closes it travels further than the body that first tried it.
Batteries included
Most business cases for buying technology price the wrong thing. They price the purchase. The purchase is often the cheap part.
Start with time. Buying through a framework tends to be slow. Even with G-Cloud, the framework that is supposed to be the fast way for the public sector to buy cloud and digital services, and the wind firmly behind you, the road from a need to a signed purchase runs, in my experience, six to nine months. Cross a financial year and you may add another three to six, because public-sector money is famously spend-it-or-lose-it. That is why your potholes tend to get filled in February and March: the council burning the last of this year's budget on a well-founded suspicion that if it does not spend the lot, someone will quietly decide it needed less all along. Out come the crews with the warm tar, in the cold, paving this year's road to protect next year's.
But the timeline is only the half of the cost you can see. When you finally have the thing, it is rarely ready to use. It has to be secured, then bent into the shape of how your organisation actually works, which is never the shape on the diagram. I took to calling this "batteries not included": the box looks complete on the shelf, and the effort lives in the small print, after the money has changed hands and the timeline everyone was watching has quietly ended.
NDX was always meant to be the other kind. Batteries included. A service that arrived ready-configured, like a furnished flat rather than an empty one. You own it outright, you can rip out every stick of it and put in whatever you prefer, but you do not start from a bare room. You start from the reasonable acceptance criteria of a bed, an oven, a sofa, a television. The point was never to narrow anyone's choices. It was to spare a team the second job before it had begun the first.
The reason this matters has a name. The industry calls it a "landing zone": the secured, configured foundation an organisation has to lay before it can safely run anything in the cloud at all. Organisations routinely spend tens, sometimes hundreds of thousands of pounds building one. And the trap tends to close the same way every time. You build a landing zone because you must; it is expensive and shaped around one vendor's way of doing things; having paid for it once, your appetite to pay for it again with the next vendor is understandably low; and the thing built to give you choice has quietly taken the choice away. My own view of landing zones is not a generous one. They are an expensive tax on getting started that we have all quietly agreed to treat as weather, as if no one decided it and no one could change it.
So the framework timeline is only the visible half of the cost. The other half lives in the months nobody put in the plan, and it is usually the larger one. Batteries included was never a luxury. It may be the difference between owning a thing and being able to use it.
It was a marketplace, not a shop
The part of NDX people pictured was the shop: a place a public body could go and buy a thing. A shop has one till, and the money runs one way. That was never the whole of it. The NDX:Catalogue would let public-sector bodies sell as well as buy, one public body to another, internal recharge between departments, never data sold to the open market. And the moment you can cross-charge, that is, bill one public body for a service another provides without a bespoke deal each time, you can also do the reverse and issue a credit note. That financial plumbing, the dull business of money moving cleanly between departments, was the quiet point of the whole thing. I know how a credit note lands at a dinner party; I have watched the eyes drift over my shoulder to a happier place, one where nobody is saying the words "credit note". Stay with me, though, because this dull bit is the engine.
It was meant to underpin initiatives like the National Data Library, the government's stated ambition to make public data usable across departments. A library only works if someone can afford to keep the lights on. NDX was an attempt at the financial basis for that: a way to make sharing data and capabilities across government sustainable, rather than a favour one team does another until the goodwill runs out.
"Sharing in the public sector is hard"
"Sharing in the public sector is hard" is a sentence we keep paying a great deal of money to be told, slowly, by people who are usually right about it. It is true, as far as it goes. Technical fixes help; political fixes help; mandates help. But none of them moves the thing that actually sticks, which is that sharing only works when the money can move with it.
Consider what it takes today. If one department, say DEFRA, wants data held by another, say DWP, the borrowing department needs to know the arrangement is sustainable, that the data stays consistent, and that it meets the service levels it is promised. The threshold to strike and implement that agreement is often so high that the cross-organisation business case rarely justifies itself below the millions. And you can reach the end of all that effort only to find the data quality was not good enough, or the need had changed while you were still negotiating.
NDX could change that arithmetic. Services and data could be shared with federated user and workload identity baked in, the plumbing that lets one system trust a person or a process from another without a fresh negotiation each time. So the producing team, the one that has to put a real person on supporting a new consumer without degrading its own service, could simply be paid for it. The consumer would get a dependency it could rely on; the producer a line of income instead of a line of unfunded obligation. No grand treaty. No heroics. Just paid. Like the rest of the platform beyond the sandbox, this was the design and the direction, not yet the delivery. But it was the point.
Sharing in the public sector is not really a technology problem, and it is not really a willpower problem. It may be a plumbing problem, and the plumbing is money moving cleanly. The rules on how public bodies may recharge each other, and the law on sharing data safely, matter too, and no platform abolishes them; but money is the part everyone tends to tiptoe around, and the part nothing else moves without. Spend years trying to fix it with mandates and strategies and you can spend a fortune without ever moving a penny to where it needs to go. Nobody writes a song about plumbing (apart from Weird Al), but you notice it the day it stops. The willingness to share was there the whole time. The mechanism to pay for it was not, and willingness without a mechanism is just goodwill waiting to expire. You do not get organisations to share by asking them nicely. You get them to share by paying the bill.
What the Catalogue really did
The part of the Catalogue people pictured was the listing: a row of products, a price, a star rating. The listing was the easy part. The hard part was the trust that would have had to sit underneath it, and almost all of that trust came down to one feature nobody finds glamorous: the review. Reviews were never live, like the ratings beside them; this is the design and the direction, not the delivery. But of everything I drew, the review was the small thing that turned out to be the largest, and I think it is worth saying why.
A review has to be safe at both ends of the same transaction at once, and the two ends want opposite things. The supplier needs enough safety to be reviewed at all: a bad review must not be commercially fatal, and it must never feel like an ambush. The consumer needs the opposite kind of safety: enough trust in the review to act on it with public money. Make it too safe for the supplier and you have built a brochure nobody believes. Make it too sharp and your best suppliers quietly decline to be listed at all, which leaves the careful buyer with nothing to read. The work was never the star rating. It was building a place honest enough to be useful and kind enough that people would still stand in it.
That is also why a review cannot fairly be the judgement of one buyer in one room. Anyone who has sat on the buying side knows that a self-attested questionnaire rewards the supplier who answers it well, not the supplier who delivers well, and the two are not always the same. Even when you suspect a claim has been burnished, you cannot challenge it fairly, because to be fair to this supplier you would have to know every other as well as you know this one. No buyer can; procurement is a side-of-desk job, never the thing anyone is measured on. So the fair thing and the doable thing come apart in your hands, and pretending otherwise is how unfairness gets to call itself diligence. That is not a failure of any individual's care. It is the reason fair signal has to be pooled, accumulated across many buyers over time, rather than assembled by one person in one afternoon. One body knows the real story behind this supplier's work; another knows the truth about that one. Spread across enough of them, structured and shared, those fragments add up to the even-handed picture no single panel could ever build. Reviews, in other words, are sharing applied to judgement.
There was a harder question underneath that one, and I never solved it, because the layer was never built. Most reputation systems reward the absence of complaints, which quietly rewards whoever never gave anyone the chance to complain. A clean record might just mean nobody has stress-tested them yet. The supplier I would actually want a public body to depend on may not be the one that happened to get it right on day one; it may be the one that got something wrong, listened, and put it right quickly without being chased. A digital product is not a tin of beans, the same thing on the shelf it was at launch. It changes every week, and so do the people behind it, so the question that matters is not "was this perfect when the first buyer touched it" but "when this turns out to be wrong, and it will, does anyone on the other end move." A fault well fixed is evidence a clean record cannot give you. The naive version is dangerous: reward fixes too crudely and you teach suppliers to break things theatrically so they can be seen to mend them. So the real target is the trajectory, a living product and the people tending it, not a snapshot on its best day. I just did not get to measure it.
And under all of it sat the thing I would build first if I started again. Due diligence today is done in full when a public body takes on a new supplier, and lightly, if at all, when the same contract comes up for renewal. But these are not bridges that sit still once you have signed for them. They are digital products, and they keep changing underneath you: a new sub-processor here, a security posture that was true in March and is not by September. So the diligence you did at the start goes quietly stale while you rely on it, and the renewal that should catch it is the moment everyone is too busy to look. Now multiply that by the tens of thousands of public bodies who buy the same handful of things, every council, every school, every GP practice, each running the same checks on the same supplier, alone, in the dark, and binning the answer the moment they have it. The NDX:Catalogue was meant to make that work shared rather than repeated. Diligence one body has already done, published once where the next can pick it up; anyone free to refresh it, with the refreshed answer flowing back to everyone rather than into a drawer; each finding tied to the buyer's risk register, and to what changes if they come to use the thing more, less, or differently. Done well, due diligence stops being a toll you pay at the door and becomes a living record the whole sector keeps together, fresher because more people are watching it, not staler because each of them looks alone. This is the evidence layer that would have made the two-sided reviews trustworthy at scale. Nobody should re-investigate, in the dark, what another public body has already checked.
Where this came from
I want to be straight about where this came from, because pretending an idea sprang from nowhere is both untrue and a little unfair to the people it actually came from. NDX was a synthesis. G-Cloud got there first on the principle that the public sector should be able to buy cloud and digital services through one faster, fairer front door, and it has the years of hard-won lessons to show for it. The hyperscale marketplaces, the ones AWS, Microsoft and Google built on top of their own platforms, showed what a catalogue and a clean transaction layer can do at scale, and how much friction may simply disappear when discovery and buying live in one place. NDX took both of those, pointed them at the particular shape of UK public-sector procurement, and added the parts neither had a reason to build: cross-charging between public bodies, demand pooling, the batteries-included promise.
Good ideas are almost always synthesis. The work is rarely the flash of originality, which is rare and usually borrowed anyway. The work is choosing the right things to borrow, understanding the problem well enough to know what to leave out, and then actually carrying it. That part I will claim.
There is a reading of all this where NDX looks like empire: one central platform growing, year on year, until it has swallowed every catalogue, every transaction, every council's choice. That is the opposite of how the thing was drawn. NDX was built to be glue, not a kingdom. A thin, modular connecting layer for a sector whose components had commoditised and whose access had not, owning none of the things it joined and made specifically to be ripped out and replaced the moment something better came along. Unearned lock-in was the disease, not the goal; a platform you cannot leave is just a landing zone with better marketing. The best version of a connector ends not by reigning but by quietly becoming unnecessary, and anything that has to keep swallowing things to justify itself has forgotten what it was for. That is a claim about the architecture, not about the conviction. I believed it was the right answer, and I still do; I just wanted it built so that the day it stopped being the right answer, nobody would be trapped inside it.
What the public record says, and what it does not
I should be precise about what is mine to assert and what is not, because this is meant to outlast me, and the credibility of the whole thing rests on keeping the public record and my own account cleanly apart.
The trail is public, and I built it deliberately in the open. The Register reported the underlying paper in April 2024, a copy of which had unintentionally reached them, a paper I had written a few months earlier describing a UK Public Sector Cloud Marketplace and arguing that the existing approach concentrated risk and left the public sector with weakening power to negotiate with cloud vendors. That marketplace is what became NDX. The idea in it was not new, and I never pretended it was; a marketplace for public-sector technology is an obvious thought once you have seen G-Cloud and the hyperscaler marketplaces do their versions of it. What I will take the credit for is writing it down, arguing for it, and aligning users and industry to it.
In June 2025, ahead of London Tech Week, the Department for Science, Innovation and Technology (DSIT) announced NDX as a first-of-its-kind digital marketplace to overhaul how the public sector buys technology, fronted by the Minister for AI and Digital Government. That announcement carried the £1.2 billion figure, set against the roughly £26 billion a year the public sector spends on technology, and the government's own roadmap for modern digital government repeated it in January 2026. It is the government's own published number, not mine, and I hedged it myself, in public, at the time. As I told a room of London boroughs: "I'm not asking you to believe the £1.2 billion. It's an estimate; it'll be wrong in at least one direction." Both halves of that are still true. Peter Kyle returned to the theme at the Google Cloud Summit in July 2025, saying the National Digital Exchange would help more UK tech companies "get their slice of the £21 billion pie". And in April 2026 some months after its general availability the official GDS technology blog announced NDX:Try for local councils, openly inviting both sides in: councils to test real services, and suppliers to put their own forward.
I'm not asking you to believe the £1.2 billion. It's an estimate; it'll be wrong in at least one direction.
The NDX site carried a banner calling it a prototype, the cleared blog post I didn't write called it a pilot, and I have told you it was in alpha/beta. All three are true, and none of them makes it disposable. A pilot, like an alpha, is the ordinary early phase of a committed public service: discovery, then alpha or pilot, then beta, then live. Calling that phase experimental is honest delivery language; it means you are testing the riskiest assumptions in the open before you scale them. That is what we were doing, and that is what it was.
The committed-programme record sits in the same public place. In May 2026 I delivered a talk to London boroughs, I described NDX as a committed programme. The government's own published roadmap, updated at the end of May, carried a dated commitment to complete NDX. That was a programme mid-stride.
The closure itself is not in the public record (today, at least). It is my own first-hand account, and I will keep it that way rather than lean on any document to imply what it does not say: the decision to switch NDX off was made, and the reasons were not shared with me. I am a contractor I was paid everything I was owed and I am therefore not owed a reason, and that is the deal. I will not speculate about one I was never going to have.
On the record
I led NDX and I carried it: I learned the procurement regulation (old and new!) and the innards of the frameworks; I learned what a council actually needs, and what lands with a Deputy-Director, Director, Director-General, Minister, Secretary of State, UK SME or multi-national tech conglomerate in the room; I drew the model and argued for it day to day. The synthesis was the work. But the shape of it was borrowed from better and earlier work, built on, and made specific, which may be the only way anything like this ever gets made.
NDX was nearly three years of my life. They were spent on a set of problems I had already watched for the thirteen before it, from the other side of the buying desk and the other end of the framework, in enough different organisations to know they were not local quirks but the standing shape of the thing. That is the part I would ask the next person to take seriously: the diagnosis here is not a theory formed inside one programme, it is what sixteen years working on the same problem taught me, three of them spent trying to solve it.
There is one thing I owe to every minister, foreign delegation, council, supplier and colleague who took NDX:Try seriously, and it belongs in writing. I told them what I believed: a committed programme being built in the open. That belief was held in good faith, and so was their trust.
I should say what this meant, because that is the truer thing to leave on the record. I am a contractor, which on paper means the work ends when the day does. This one did not, and I am glad it did not. It was built in a great many nights and weekends, and I gave them gladly, because the problem was worth it and the people were worth it: sharp colleagues, work that mattered, the rare feeling that the effort was going somewhere worth reaching. My family gave me the room to do it , and I am grateful to them for that more than for anything else here, Hannah Nesbitt-Smith 🙏💖. I would not hand the time back even if I could. It asked a lot, and it gave back more. That is the part I most want remembered.
The record, handed forward
So this is not an elegy and not a complaint. It is a marker, left on purpose where the next person will be standing.
The whole thing was built in the open, code and thinking both, so nothing of substance is gone. The repositories are public, the talks are public, the rationale has been public since 2024. What is easy to lose is not the work but the thread: why it was tried, what it solved and what it did not, and where it stopped. Git (software version control) remembers the code commits but not the reasons, and a problem only findable by people who already know it existed is not really findable. So here are the things I would hand on, held loosely:
- The procurement problem is the problem. Demand was never the hard part; NDX:Try proved that in weeks. The hard part is the road from a need to a thing you can actually acquire, ready to use, and that road was never finished.
- The access divide runs both ways. A council cannot reach central government's terms, and a good small supplier cannot afford to reach the council. Any next attempt may have to close both gaps at once, or it closes neither.
- The real prize is not buying, it is sharing. The same plumbing that lets one body buy from another could let them share a service or a dataset and fund it cleanly and sustainably. Get that right and things like the National Data Library have a foundation to stand on.
- The constraint is the machinery, not the will. The market is willing; the machinery is what is missing.
- Build it in the open from the first code commit, so the next person inherits the work instead of starting again from a bare room.
That last pair is the creed I have written more than once and still believe: nobody in public service should have to start from a blank page alone, and nobody should re-buy, in the dark, what the public has already paid for. The instrument built against that is being switched off tonight. The reason for it is not.
There are a few small things lined up for me personally over the next few weeks, and I find it oddly steadying that the problem is not going anywhere: it means the work is not going anywhere either, only its current address. NDX was one large, stubborn problem of this shape, and it turns out I am happiest working on those: the big, hard, unglamorous ones where the components exist and the access does not, and where getting it right is worth the years it asks for. If you are carrying something like that, NDX-shaped or not, lets talk! The best way to reach me is on LinkedIn or email me.
Before I close, the thanks, because credit and lineage matter more than the rest of this, and that cuts in two directions at once. NDX was built on work that came before it, and carried by more people than me. It owes a debt to G-Cloud, which made the case years ago that public-sector buying could be faster and fairer, and to the cloud marketplaces the hyperscalers built, which showed what a catalogue and a transaction layer can do at scale. I borrowed freely from both and I am glad to say so. And I did not carry the thing alone. To David Knott , Barry Hooper FWCC, FCIPS, MCIM. , Joanne Newman , Madeline Hoskin , Phil Rumens who put real work and real belief into it and gave more than the job ever asked: thank you, genuinely. To the colleagues across government and industry who backed it and put their weight behind it, Dimitris Perdikou , Chris Hesketh , Ella Cole , Jodie Keens , Nick A. , John Cunningham , Liz Adams , Samuel Walls , Emilie Cummins , George Burton , Ryan Thompson MBCS , David Heath , Daniel B. , James R. , Neil McIvor , Jonny Williams , Andrew Newland , Iain Stark , Steve Chan , Dr. Nayyab Naqvi, PhD MBCS , Joe Reay , Martin Bishop , Paddy Gardner , Sam Hazeldine , Rhys Powell , Jack Perschke , Tim Koch , Dan Mehaffey , Jonathan Bennett , Bettirose Ngugi , Will Callaghan , Ben Bennett , Matty Hayward , Peter Gale , Ollie Chalk , Sarah Crandall , Sarah Handyside , Charles Lawrence , Sharon Madigan , Tommaso Spinelli , Kristina Pitts-Tucker , Simon Wardley , Richard P. , Mike Potter , Antonia P. , Rob Graves (and some people without last names, you know who you are..) : thank you for the company. To the boroughs and councils who signed up, tried things, and told us the truth about what helped and what did not: thank you for trusting it. And publicly, to Amazon Web Services (AWS) , the first to back making this free for the public sector to try: you moved first when I did not expect anyone to, and you deserve to be named for it.
The platform switches off tonight. The problem it was built for is still sitting there, patient. I have left the light on.
This piece was written from publicly available material and my own first-hand experience of building and running NDX, nothing drawn from internal or confidential sources made it in, and to keep the rest to what is already on the public record. It is written in a personal capacity.
(Views in this article are my own.)