How we build, and how we know it works.
Most of this is invisible to you when it works. It is worth publishing precisely because it is what you are buying.
- 8dimensions, answered before any code is written
- 3independent sign-offs, each checking the one before
- 5gates, each needing its own explicit approval
Before anything is built
Every change starts with a written impact analysis, presented and agreed before a line of code is written. It is a fixed list of eight dimensions, answered every time.
- 01 Naming and terminology
- 02 Data flow and mechanics
- 03 Shared code
- 04 Sitewide claims and counts
- 05 Duplication across pages
- 06 Language
- 07 Regression impact
- 08 Design
It is fixed on purpose. A conditional version, where you only check what seems relevant, gets quietly narrowed by mis-categorising the change at the start. That is how things get missed, and a name that needs to change, or a design that has to match what is already there, is exactly the kind of thing a narrowed check skips.
Three independent sign-offs
Work does not ship because the person who built it says it is finished.
-
01
The developer
Builds it, and tests their own work.
-
02
An independent QA pass
Verifies the change, runs the entire regression pack at every screen size, checks side effects on anything sharing code with what changed, and walks real end-to-end journeys. It ends in an explicit signed-off or not-signed-off verdict.
-
03
A validator audits that QA report
Not the code again: the report. Did it cover what the specification required, and are its claims true when independently re-measured?
A QA report once said “sampled from 16” when there were eighteen, and skipped a check on an assumption that turned out false in two cases out of seven.
The validator caught both. Each layer checks the one before it rather than trusting it.
Regression testing
Every case in our regression pack exists because something actually broke once. None are hypothetical. The full pack runs on every release, at every breakpoint, not a sample of it. Skipping a case requires a stated, measured reason, not a judgement that it probably does not apply.
Defects are recorded with their root cause, not just their symptom, including cases where our own testing missed something and why.
Security testing
Changes are reviewed for security before release, not hardened afterwards. Anything touching authentication, data flow or permissions takes the full three-way path rather than the light one. Security headers and content policies are part of the build output.
We do not currently hold a third-party penetration test certificate. If your procurement requires one, say so at the start and we will tell you honestly whether we can meet it.
Getting it to you
Five gates, each needing its own explicit approval, never inferred from the one before.
- 01
Structural checks pass locally.
- 02
Work is tagged on a branch once QA has signed off.
- 03
You approve deploying a preview.
- 04
You review the live preview yourself. We never self-certify this step.
- 05
You separately approve going live. Reviewing a preview is not approval to deploy.
How quickly? A tightly scoped tool can reach a preview you can use within days. What takes the time is rarely the building: it is agreeing exactly what should happen at the edges, which is where software usually goes wrong.
Compliance and regulation
What we can evidence, and what we will not claim.
Our products are built to help you meet your obligations: every action carries its evidence, nothing changes without a recorded human approval, and the trail of who approved what is part of the design rather than a report bolted on later.
What that means concretely for your regulator depends on your sector, and we will not pretend otherwise on a web page. Tell us what you are held to and we will tell you specifically what we can evidence and what we cannot.
Ask us what we would do with yours.
Tell us the job and you will get a straight answer on what we would build, what it would take, and what we would check before it reached you.