How we work
Forty years of engineering discipline. Modern tools, used responsibly.
This page covers the rules we build by, exactly where AI fits in and where a person stays in charge, and the evidence from a live site that it works.
Kington Parishes, as of 26 Sep 2026.
What "quality" means here
Four things, together, not one of them alone.
Anyone can promise quality. This is what we mean by it, and where each one is proved rather than just claimed.
The right values
Creative, Cooperative, Honest, Determined, Respectful — they decide what we'll build and who for, before a line of code exists. Who we are →
The right thing, specified properly
A written spec, agreed before any code is generated, saying what should change and how we'll know it worked. The best system badly specified is still the wrong system.
Sound architecture
Security as the primary non-functional requirement, least privilege everywhere, and the simplest thing that meets the real need — never the cleverest.
Disciplined practice, tested
Our Engineering Principles below, and the full suite — accessibility, security and content — on every single change, not just at launch.
The starting point
Our Engineering Principles
Eight software engineering principles, condensed from forty years of professional practice and written down long before AI tools existed. They're just as true now, and they're public.
- There are no shortcutsSoftware creates technical debt the way trees create oxygen. It's unavoidable, but good practice keeps it small.
- All code is first-class codeCode that fails to explain itself to other people is poor, and potentially dangerous. Test code included.
- Code for other people, not just for the solutionSay what the code is going to do, up front.
- Avoid stream-of-consciousness programmingCode written without intent leaves boundary conditions unhandled and failure modes unconsidered.
- Security is your responsibilityThe primary non-functional requirement. Built into the pipeline, not bolted on afterwards.
- Always test firstGood tests are nearly impossible to reverse-engineer later. Write them first, so they're always there.
- Test functionality, not implementationTest the contract with the caller, so the code underneath is free to change.
- Test business rules, aim for 100% coverageFull coverage and a green build buy the confidence to refactor, or rewrite, and trust it still works.
What changes with AI
The rules don't get less true. They move.
An AI writing the code doesn't make good engineering expire. It changes where each principle bites, and understanding that is the difference between AI making a site faster to build and AI making it riskier.
Tests become the control
"I understand it because I wrote it" no longer applies. Tests written first, against the real business rules, become the thing the AI is held to. The code underneath can be regenerated without re-earning trust from scratch.
Intent moves into the spec
A vague prompt produces stream-of-consciousness code, with nobody's memory to interrogate afterwards. So the thinking happens before the AI is prompted, in a written spec, and after, in review.
Confident isn't correct
AI output reads as clean and assured even when it's wrong. Sloppy code used to look sloppy. Now fluent code invites a skim, exactly when it needs a careful read. We don't skim.
You own it, whoever typed it
"The AI wrote it" is no more an excuse than "the framework did it" ever was. Every line that ships stands behind our name.
Verify what it asserts
Models invent plausible package names and config flags with total confidence. Every dependency is checked to exist, and to be the genuine article, before it's trusted.
Standing instructions
Every project has a written rule-book the AI must follow on every change: run the tests, audit dependencies, calculate contrast, log the release. The rules travel with the code.
Further viewing: "Software Fundamentals Matter More Than Ever" by Matt Pocock (video talk, external site)
In practice
Every change, the same way.
We use GitHub for every project and Claude Code to do most of the typing. The workflow around them is what makes that safe.
The life of one change
- Spec
- What should change and how we'll know it worked, written by a person
- Test
- A test that fails until the change is right
- Code
- Claude Code writes it, following the project's standing instructions
- Check
- The full suite, an accessibility scan of every page and a dependency audit
- Review
- A person reads the diff before it merges
- Record
- A commit, a tagged build number and an entry in the public changelog
The evidence.
Kington Parishes · as of 26 Sep 2026
466
automatic checks before every change
151
updates published since 31 August
36
pages, all built the same way
0
accessibility problems found on any page
0
known serious security problems
What that buys a live site.
Checked automatically on every change, not promised once at launch and left to drift.
Same-day changes
A wording change, a new page or a whole feature goes out the day it's asked for, with no monthly change quota.
Real browser tests
374 Playwright tests drive a real browser through search, forms, keyboard navigation and the mobile menu, plus 92 fast logic tests.
Tagged, every time
Each release is tagged against the exact commit that shipped it, for a real audit trail rather than a claim.
Dependency audit on every push
A push is blocked outright if a high or critical vulnerability turns up.
Addresses bots can't scrape
Email addresses are encoded so the simple harvesters behind most spam lists can't read them.
Hardened file serving
Tested against path-traversal attempts, including encoded and Windows-style tricks, rather than trusted to behave.
Zero accessibility violations
Every page passes a full axe-core scan, the engine behind most enterprise accessibility audits, on every change.
Contrast that's calculated
Every text and background pairing clears WCAG AA by real relative-luminance calculation, not by eye.
Built to be found
Structured data per content type, link previews that look right when shared, and a sitemap regenerated on every build.
Instant site search
A search box that finds the right section of the right page as you type, with no external service.
Enter it once
People, events and prices each live in one place, and appear everywhere they belong.
Self-tidying content
Old notices come down and newsletters move to the archive on their own, when their date passes.
After launch
Watched every day, not just on launch day.
Most sites are secure the day they go live and slowly less so after that. Every site we build and host is checked every morning, and problems become tracked, tested fixes instead of surprises.
A daily vulnerability watch
Every morning, every piece of software behind your site is checked against the public lists of known security flaws (GitHub's, and Google's OSV), including known malicious packages.
Every warning tracked
Each new warning is logged, with what it affects and how serious it is. Anything serious also triggers an email the same morning.
Fixes proposed automatically
When a patched version is published, a fix is prepared automatically as a proposed change. Before a person approves it, it has to pass the site's full test suite.
Very little to attack
Our sites send your visitors plain, fast pages with very little code and no trackers. Most of the software we use to build and test them never reaches the live site at all.
Locked-down automation
The tools that do this checking are locked to exact versions we've reviewed, and can only touch what they need to.
Self-healing SiteAdmin
Where there's live code, as in SiteAdmin, errors are caught, diagnosed and turned into tested fixes automatically. See how SiteAdmin reports and repairs faults
A straight answer about "zero-day" attacks.
A true zero-day is a flaw nobody has published a warning about yet, so nobody can scan for it, and anyone who claims to is overselling. What we can do is give an attacker very little to work with in the first place, and act the day a warning is published rather than weeks later.
A real change
What "always test first" looked like.
Kington Parishes' noticeboard retires an old notice and reveals its replacement once a date passes. That logic had never been tested, so we added a test, after the fact.
Spec it precisely
Which cards hide and appear, and when, including what "nothing has expired yet" should look like.
Write the test
A mocked clock set to three different dates, checking the right cards on each.
Prove it's real
Break the logic on purpose, confirm the test fails loudly, then revert.
Confirm, then ship
Green again, committed, tagged and logged in the public changelog.
This site's own build log.
The same discipline applies here. These are the latest entries, pulled from the changelog on every build.
2026.10.21.002Update the checks for the home page to expect the new door order and headline
2026.10.21.001Reorder the home page hero and door cards as Enterprise, Business, Not-for-profit, then Selling,…
2026.10.19.001Add a GitHub Action that re-runs this repo's own test gate and audit against a Claude Code pull…
2026.10.13.002Add MediaWright Motors, a fictional car and motorbike dealer, as a demonstration of what we can…
2026.10.13.001Fix the project cards' row of three figures pushing the page sideways on the narrowest phones…
Want to see it applied to your project?
Tell us what you're building, and we'll show you what the process would look like.