I built a GOV.UK prototyping tool that never goes online
Local models are finally good enough to do real, standards-compliant work on the device in front of you. So that's where this one runs.
Government designers are increasingly using AI to prototype. It speeds up a slow part of the job, and the design community has been openly experimenting with it — Joe Lanman's work on the GOV.UK Prototype Kit is one well-known example. That's a good thing.
But there's a rule sitting on top of it. The cross-government guidance to civil servants on generative AI is explicit: don't put sensitive or personal information into public generative-AI tools, because government has no oversight of what happens to the data once it's entered.
Prototyping runs straight into that rule. A mock-up is only convincing when the content is believable — and the most believable content is real content. So the moment "realistic" shades into "real", a public AI tool becomes a place service data can quietly leave your control.
I built Prompt to Page to dissolve that tension rather than make people tiptoe around it. It turns a plain-English prompt into valid, accessible GOV.UK Design System HTML — a page, or a whole journey — and it does the entire job on your machine. After first-run setup, nothing you type and nothing it generates ever leaves your laptop. There is no API key, no account, and no server to send your draft policy to.
Standing on Joe Lanman's experiment
I'm not the first person to point a local model at the GOV.UK Design System. Last year Joe Lanman — who co-founded the GOV.UK Prototype Kit — built Component Pad, an experiment that configures individual GOV.UK components from a prompt. He ran it against open models you can run yourself, like Mistral Small, and he was clear about why: smaller models, prompts and outputs use less energy, and the project isn't "stuck with a large, closed commercial model."
That last point stuck with me. Most AI tooling makes you a tenant of someone else's data centre. For government work, that's not a detail — it's often a blocker.
Joe's tool answers a focused question: give me the configuration for this one component. I wanted to find out what happened if you took the same bet — local, open, on-device — and pushed it all the way to the thing designers actually need: complete, accessible pages and multi-page journeys, generated, checked and exported without ever going online.
What it does
You describe what you want the way you'd brief a colleague:
Create a GOV.UK service start page for checking apprenticeship eligibility, with a heading, short intro, and a Start now button.
The app retrieves the relevant Design System component documentation, sends it to a local model along with your request, and streams back HTML. It renders that HTML live with real GOV.UK Frontend components, layout, spacing and colours — so you're looking at the actual page, not a description of one. Then it runs an accessibility check and a validation pass against real GOV.UK class usage, and lets you export a ZIP, copy the HTML, or copy it as Nunjucks for a developer.
All of it runs through a bundled inference engine — llama.cpp on most machines, Apple's MLX on Apple Silicon. The model lives in a file on your disk. The internet is not in the loop.
Why offline is the point, not a limitation
It would have been easier to call a cloud API. I didn't, for three reasons that matter specifically to public-sector work.
Data residency is the whole game. A prototyping tool is only useful if you can paste in realistic content. The moment "realistic" means "real", a cloud tool becomes a place where service data, draft policy and citizen-shaped examples leak out of your control. On-device removes the question entirely. There is nothing to leak because nothing is sent. That also means the tool works inside locked-down environments and on a train with no signal.
It's more sustainable, and that's not a side note. Joe made this point and he's right. A cloud model answers every prompt with a round trip to a data centre that costs energy and, increasingly, water for cooling. A small model doing a small, focused task on hardware you already own is a far lighter way to work. Prototyping is iterative — you'll generate a page twenty times. Twenty data-centre round trips versus twenty runs of a 4-billion-parameter model on your own laptop is a real difference.
No per-seat cost means no gatekeeping. When inference is free at the point of use, you don't have to ration access or justify a licence per designer. The tool can just be there.
What it doesn't do, and the safety net for that
Local models are smaller than the frontier cloud ones, and I'm not going to pretend otherwise. They make mistakes. Asked for a component that doesn't exist, any model will confidently invent one — Joe flagged this, and it's still true.
So the model is not trusted on its own. Every generation is checked against the 473 real govuk-* classes and the Design System's structural rules, with one-click fixes for the common errors. Every page is scanned with axe-core against the WCAG 2.2 AA bar, run against the rendered page so colour-contrast and target-size checks actually mean something. The model proposes; the deterministic checks dispose. Those automated checks are a floor, not a ceiling — they catch the mechanical failures so a human can spend their judgement on the things only a human can assess.
That's the honest shape of it: a capable-enough local model, wrapped in standards-aware guardrails, doing a narrow job well.
It's live
Prompt to Page is in free closed beta, for macOS (Apple Silicon) and Windows. If you design GOV.UK services and you've ever hesitated before pasting content into a chat box, I'd like you to try it and tell me where it falls down.