The standard behind everything I build

Software should never fail a person in silence.

Six musts a system has to meet before I will call it fit for purpose. Free for anyone to take, apply, and hold me to.

Most software does not hurt people by crashing. It hurts them by carrying on, quietly, in a state it already knows is wrong: taking a payment for an application it has already worked out is invalid, losing the context a person has now explained four times, moving a case into a queue that has no owner. Nobody is told. The person finds out weeks later, through the consequence, and then has to reconstruct the organization’s own system well enough to explain to it what it did. That is a design choice, made by someone, and it can be made differently.

Read the six musts → or see how I apply it to client work →

Where this came from

< I met these systems as a person first />

I did not pick this focus off a list of profitable specialisms. I spent years inside public services, benefits processes, health records, and employment programs, as the person the system was supposedly for, and the same failure ran through all of them. Not rudeness, not incompetence, and rarely a crash. Silence.

The loop, as it actually runs

The system is split across departments that hold different pieces of the same person.
Context does not survive the boundary between them, so the person is asked to supply it again.
Something fails: a form, a transfer, a referral, a decision, a renewal.
The failure is never announced, because no step was ever made responsible for announcing it.
The person carries on assuming it worked, and finds out through the punishment: money gone, appointment missed, support stopped.
They become the investigator, calling each department in turn to piece together a system none of them can see whole.
They finally reach a person who believes them, who has no authority to change anything.
The individual case is patched. The cause is untouched. The next person meets the same loop.

Every link in that chain is a decision an engineer, an architect, or a procurement team either made or declined to make. That is the hopeful part: a system that fails this way was built to, and can be built otherwise.

I have written up the specific cases rather than gesturing at them: a passport application GOV.UK knew was invalid at question three and still walked to a non-refundable payment, an NHS system rollout that moved the forms onto a screen and changed nothing underneath, and the question those two forced: when is a system not fit for purpose? The answer to that last one became ADR-011, a recorded engineering decision I hold my own work to. The six musts below are that decision, in plain language, and further down I have written out which part of my own life taught me each one.

The standard

< Six musts, and one underneath them />

These are absolutes, not aspirations. A system missing any one of them is recorded as not fit for purpose no matter how healthy its dashboards look, how fast it processes, or how completely it complies with its own procedure. Read them in one direction only: every must is an obligation the institution owes the person. None of them is a requirement placed on the person, and that distinction is the whole argument.

1. Transparency, including the legal limits

Every system has a boundary: what it accepts, who it covers, what it is legally bound to do, the criteria it will judge someone against, and how a decision can be challenged. All of that is published early, in language a person can act on. A limit nobody is allowed to see is not a limit, it is a trap, and the duty to publish it sits with the institution, never with the person trying to navigate it. Publishing is only half of it, though: a limit with no enforcement behind it is decoration. The test is whether a person can hold the institution to it without needing years and a tribunal.

2. Failing is allowed. Failing quietly is not

The system can conclude that it cannot help, say so, give the reason, and point onward. Refusal is a proper ending, not the absence of one. An early no with a reason is better behavior than indefinite processing, exactly as a clear error beats a request threaded through ten services that dies without naming the cause.

3. Measure what changed for the person

Activity counters are allowed, never alone. Applications received, cases opened, appointments attended, tickets closed: that is motion. Whether the person’s situation actually changed is the outcome. Outcome measures are harder to collect, which is precisely why they are the ones left out.

4. Count the people it turned away

The system can answer what happened, when, why, how long it took, where it failed, and what happened next, including for the people it could not serve. How many were screened out, and what became of them? A system that can only report on its happy path cannot be evaluated, because everyone it failed is invisible to it.

5. The system carries the context, not the person

Records, history, and state belong to the system. When someone has to keep their own paper trail, their own dates, their own copies of what they already sent, to stop a case falling apart, the system has outsourced its memory to the person least able to bear the cost. That is a defect, not diligence on their part.

6. Never require the thing you exist to provide

A service built to remove a barrier must not require a person to clear that same barrier to use it. An employment program that only works for people who can already work a full week. A support line that needs the phone call somebody is not able to make. Alternatives and reduced friction are design obligations, not favors granted afterward.

And underneath all six: hold less, protect it properly, show it back

Robustness and security are not a separate department from this. A system holds the least it needs, defends it as though the people in it cannot afford a breach (most of them cannot), and lets a person see what is recorded about them and correct it. Data someone never consented to, cannot see, and cannot fix is another silent failure waiting to happen to them.

Where a must genuinely cannot be met, the gap is written down as a known limitation, visible to everyone deciding whether to rely on the system, instead of left implicit for a person to discover the hard way.

Provenance

< Every one of these has a year of my life behind it />

I am disabled and neurodivergent. My route through education and work has been shaped far more by the absence of accommodation than by any limit on what I can build, and I have spent a long time on the receiving end of systems that were meant to help. I did not derive these six musts from a textbook. Each one is a failure I lived through first and only later understood as architecture.

1. Transparency, including the legal limits.
Without published limits, people are blindsided as a matter of routine. You cannot navigate a structure whose rules, thresholds, and legal duties are kept out of sight, and you certainly cannot tell when an institution has stepped outside its own. Disability benefit assessment is the clearest case I know: a decision arrives, the reasoning behind it is not shown, the criteria were never published in a form you could check yourself against, and the only route to accountability is to challenge, wait, appeal, and wait again, sometimes for years, paying for the institution’s opacity with your own health and time. Responsibility that only arrives at a tribunal is not responsibility, it is liability finally cornered, and it corrects exactly one case while the structure that produced it carries on unchanged. Publishing the limits, the criteria, and the legal duties is what makes responsibility enforceable long before anyone reaches a courtroom.

And publishing is only half of it, because a limit nobody enforces is decoration. An employer can carry a disability-confident badge that it largely awards itself, with nothing checking whether the practice behind the badge matches the claim, while disabled applicants are still filtered out before a human reads the work. I have applied to those employers. A commitment with no audit, no consequence, and no usable route of redress is a statement about an institution’s self-image, not a limit on its conduct. The limits that count are the ones a person can actually hold them to.
2. Failing is allowed. Failing quietly is not.
Eighteen months of applications across nearly every route into tech, met mostly with silence or an automated filter that closed the door before a human saw the work. A clear no with a reason costs a system almost nothing and returns a person their planning. No answer at all is not neutrality, it is a cost transferred to whoever is waiting.
3. Measure what changed for the person.
The support I was given was counted in sessions attended and applications submitted. Both numbers went up for months while nothing in my situation moved. A system can report excellent health while every person inside it is stuck, and it will keep doing that until someone makes it measure the outcome instead of the motion.
4. Count the people it turned away.
When I stopped being able to continue, nothing recorded why, and nothing followed what happened next. Disabled applicants get screened out early and quietly, which means the population a service fails is exactly the population it cannot see. You cannot fix what you do not count.
5. The system carries the context, not the person.
I have explained the same history to a new adviser, a new department, and a new form more times than I can count, and kept my own records because theirs did not survive the handover. Records that hold none of what actually matters about a person, split across systems that cannot talk to each other, make the human being the integration layer. That is the most expensive possible place to put it.
6. Never require the thing you exist to provide.
I left university because the environment was not built for the way I learn and recover, and the same pattern followed into work: burnout, health flare-ups, inaccessible spaces. At one point severe burnout left me unable to work for nearly two years. Support that only works for someone already able to sustain a full week is asking for the capacity it was built to restore.

The layer that is always missing

Every one of these musts has already been written down by somebody. There are statutory duties, equality law, codes of practice, accessibility standards, charters, schemes, and whole programs built to help. Very little of it changes what actually happens to a person, because the same layer is missing everywhere: the one that enforces the rule at the moment it is broken, rather than years later, on appeal, for the one person who still had the health left to fight for it.

Help that cannot be enforced is not help. Where an institution or a company treats a person’s health and rights as optional, or as something to be negotiated down after a long enough fight, a scheme designed to support that person is a statement of intent they can decline at no cost. The enforcement then has to come from the person, paid for with their own time, health, and money, which is exactly the resource the help existed to protect. The stronger the need, the less capacity there is to enforce, so the failure lands hardest on the people the system was built for.

In software that layer has a name. It is validation: the check that sits at the boundary, runs before the damage, refuses the invalid state, and says out loud what it refused and why. A right with no enforcement layer and a rule with no validation layer fail in exactly the same way, for exactly the same reason: somebody decided the check was optional, and the cost of that decision was moved onto whoever had least power to refuse it.

This is why I build the enforcement layer rather than write about the principle. A guardrail that rejects a bad state at the boundary is the same idea as a duty somebody can actually be held to, expressed in the one medium where I can make it real.

The barrier has almost never been capability. It has been role structure, accommodation, and routes that were never designed with people like me in mind. That is also why I treat clear systems as an accessibility feature rather than a nicety: predictable behavior, loud failures, and context the system holds for you are the difference between a person being able to take part and a person being quietly filtered out. I build the thing I needed and could not find.

The longer version of this is my note on perseverance →

What this looks like when you hire me

< The same standard, billed by the job />

None of the above is charity work. It is the specification I work to, and it is why my engagements are shaped the way they are.

I look for the quiet failures first.
A reliability review is a hunt for the places your system can be wrong without anyone being told: configuration that is accepted and never checked, two systems drifting apart, a nightly job that sometimes does not run and never says so. Those are the findings that cost you customers without ever reaching a bug tracker.
Invalid states get stopped at the door, loudly.
Guardrails reject a bad configuration before a run starts, with an error a human can act on. That is ADR-001, and the message itself is a deliverable rather than an afterthought, which is ADR-005.
Irreversible actions are gated on proof, not on progress.
Taking money, sending the letter, deleting the record: those wait on evidence that the person is actually eligible, not on the fact that they managed to reach the final screen. That is ADR-003, written directly out of the passport application above.
Every judgment I make is written down and published.
My decisions live in a public decision register with the alternatives I rejected and why. You can audit how I think before you spend anything, and you can hold me to it afterward.
Fixed prices, agreed before the work starts.
A standard about not surprising people would be a strange thing to sell by the hour against a vague brief. You get the number first, in writing, and the scope it covers. Full breakdown on the services page.

Take it

< You do not need to hire me to use this />

I would rather this standard spread than stay mine. If you build, buy, commission, or run software that people depend on, these are seven questions you can ask about it this week, without a consultant in the room.

Seven questions for something you already own

Where are our limits, criteria, and legal duties written down, and would a person find them before investing their time?
Which of our published commitments could somebody actually enforce against us, and what happens to us when we breach one?
Can this system say no, give a reason, and point somewhere else? What happens today when it cannot help?
Name one measure we hold of whether a user’s situation actually changed. Not a volume, an outcome.
How many people did we turn away last quarter, and can we say what happened to them?
Which parts of this only work because users keep their own records to compensate?
Does using this service require the very thing the service exists to provide?

If one of those lands badly, you have found real work worth doing, whether or not I am the one who does it. If you apply this to something you run and it breaks, tell me where: the standard is meant to survive contact with real systems, and I will write down what I learn.

The furthest I have taken this myself is the Social Resource Floor, an open blueprint for reaching the resources a person needs to survive on the basis of being human rather than on financial status. It is unpaid, long-term, open to collaborators, and it is the same argument as this page carried to its end: the systems people’s lives run on should be built to carry responsibility, not to shed it.

< Hold me to it />

If something you run is failing people quietly, tell me what it is doing. If you think this standard is wrong, tell me that instead: I would rather be corrected in public than comfortable.

Get in touch → or read the thinking behind it →