Our approach
We absorb how your organisation really works, find the structure underneath the mess, and carry it all the way to a service that runs. Sometimes the service is new; more often it already exists and needs to work better — the method covers both.
We use the Double Diamond — the design-thinking frame you already know — as a lens, not a fixed process, adapting it to the problem in front of us.
The Double Diamond, carried through to delivery
Discover
Talk, transcribe, parse
Define
Stories, YAML, blueprints
Develop
Django + HTMX / n8n prototype
Deliver
Validate & hand over
Discover
Understand the real need
We start by hoovering up what already exists. We talk to the people doing the work, transcribe interviews and focus groups, and parse every document already written about the problem. We go wide before we narrow — surfacing the real needs, the constraints people operate under, and the lines they can’t cross.
Where we’re improving an existing service, we establish what it really does — and which behaviours to keep — before designing the replacement, so we’re not quietly rebuilding yesterday’s problems.
Define
Make the intent explicit (and fundable)
This is where the work earns its keep. We find the things that aren’t written down anywhere — the workaround that keeps the real process moving, the decision that actually gets made in the corridor, the point where the official version and the lived version part ways.
Then we render it so clearly it becomes obvious: user stories, low-level processes in our own human- and machine-readable YAML, service blueprints, and presentations that show exactly what’s going to happen. These do double duty — they’re the spec the build runs from, and they’re what you take to your colleagues to win the funding and the priority. More than once, a blueprint we made is the thing that got the business case over the line.
We agree the design with you before we build from it — so what gets built is what you signed up to, and it doesn’t quietly drift as it goes.
Develop
Build a living prototype
Not slideware — a working, evolving thing you can use, test and argue with. We build lean in Django and HTMX, or n8n, or both, assembling it fast with agentic AI. The engineering discipline is there from the first line; the production apparatus switches on as the service matures — never all at once, never bolted on late.
Progress is verified without reading code: plain-English user stories, test names that describe the intent, and documentation updated in the same change as the thing it describes.
What you walk away with — a working service, an operating model in readable YAML, and living documentation — is built to stay maintainable by people and AI for years. See the outputs →
Deliver
Prove it, then hand it over
We validate with the people who’ll actually use it, in conditions close to the real thing. Then we hand over a working service, usable up to a defined scale, with an honest roadmap of the product, technical and service work it takes to grow further. These are typical outputs, not guarantees — every engagement is shaped to its problem.
Run & improve
Handover isn’t the end
The documentation is a living deliverable — user stories, runbooks, blueprints and process maps kept current with every change, in a form both your people and your AI tools can execute. The service gets a regular health review: evidence-led proposals you accept or decline, so improvement is scheduled, not hoped for. And periodically the whole thing is audited by a different AI model than the one that built it — cold, independent, evidence required for every finding.
When we’re replacing an existing service, the old system keeps running while the new one takes over one piece at a time — each piece proven to match the old before it goes live, with a tested route back at every step, and no big-bang moment.
Standards and non-functionals, from the start
The things that decide whether a public service can be trusted are designed in from the first day, not bolted on before launch:
- Security — built to the NCSC Cloud Security Principles, with each change threat-modelled as it’s specified, so a risk shapes a design decision rather than surfacing in a later audit.
- Accessibility — built to WCAG 2.2.
- Testing — automated tests that describe the intended behaviour in plain English, run on every change, so a regression is caught before it ships.
- Data rights and audit — data-subject export and deletion, audit trails on sensitive records, and malware scanning of uploads, as defaults.
- Localisation — a first-class concern wherever a service serves more than one language community, not a retrofit.
All of it in the grain of the Government Digital Service Standard and service lifecycle, and the Digital Scotland Service Standard — and we’ve designed services with NCSC architectural input.
The tools we choose keep your data in places we control: open and self-hostable by default — Excalidraw for discovery, Django and HTMX on standard Postgres, n8n — with cloud (GCP or AWS) where it fits. For AI, foundation models (ChatGPT, Claude, Gemini) through our secure cloud environment, and open-weight models (DeepSeek, Gemma, Mistral, Qwen) on our own controlled hardware for the most sensitive work. Nothing sensitive goes to an uncontrolled third party.
Why this is different
Thinking and building in one small senior team, a method that keeps AI-built work honest, and services we run ourselves. That combination is rare — and it’s the whole point.
Book a call