Background

What happens when you build software for people, not for the market

Over the past weeks the first compliance requests from organisations came in. Lists of requirements covering information security, data protection, software ergonomics and accessibility. Mapping them against the existing architecture produced an unexpected result: most of it was already in place. Not because any standard demanded it. But because the target group needed it.

The observation looks unremarkable at first glance. It becomes interesting only once you see what an enterprise compliance review actually asks for. The requirements that land on the table there did not emerge as a legal end in themselves. They grew out of concrete harm that software has caused in the past.

What an enterprise review actually asks for

A flawed application can expose personnel data, compromise customer accounts, disrupt supply chains or put entire business units into regulatory question. From precisely those risks, five families of requirements have emerged over decades, and any procurement process at a mid-size or large organisation will check them today:

• ISO/IEC 27001 governs information security as a management system. Who has access, how data is encrypted, what is logged, how the organisation responds to an incident.
• OWASP Top 10 is the industry baseline for application security. Which classes of vulnerabilities exist and how the application is hardened against them.
• GDPR defines the rights of the individual. Access, rectification, erasure, portability, data minimisation. It also requires a data protection impact assessment as soon as special categories of personal data are processed, which include health and neurodivergence information.
• EN ISO 9241 defines software ergonomics. Seven dialogue principles, from suitability for the task to self-descriptiveness to error tolerance. A standard that asks: can a person actually work with this software without wearing themselves down on it.
• WCAG 2.1 Level AA is the international standard for accessibility. Keyboard operability, contrast, screen reader announcement, reflow, scalability. Mandatory for many sectors in the EU since 2025.

Together these five families produce a requirement scope that large software vendors staff entire audit teams for. Without that evidence, no enterprise procurement happens.

The unexpected match

Mapping the existing codebase and database systematically against those five families produced this result: met, except for two external steps that will be activated with the first enterprise contract. A formal certification by an accredited auditor and an external penetration test. Neither requires any change to the existing architecture.

• ISO/IEC 27001 Annex A: 12 of 13 control families met. A.6 Organisation of information security partially met on the organisational side (single-point-of-contact structure).
• OWASP Top 10: all ten categories met, documented in Audit 20.
• GDPR: 18 articles mapped and met, including a Data Protection Impact Assessment with eight risk scenarios for special categories of personal data under Art. 9.
• EN ISO 9241: all seven dialogue principles per Part 110 met, complemented by the relevant Parts 112, 125, 143, 171 and 210.
• WCAG 2.1 Level AA: all 50 Level A and AA success criteria documented, with no open critical or high findings.

Concretely, without going into individual implementations: row-level access control on every table. Encryption at rest and in transit. Pseudonymisation of IP addresses before logging. Audit log with tiered retention. Separation of identity data and content data. A complete record of processing activities. Data export in a structured, machine-readable format. Seven-day grace period before final deletion. Protection against the ten most common web application vulnerabilities. Buffer-then-send instead of streaming, so a safety check can see the entire response before it arrives. Keyboard operability for every interactive element. Contrast values exceeding the accessibility minima. Reduced sensory load as a default.

The full breakdown with per-area status and references to the underlying source documents is available in the Compliance Report v1.0.

Why all of this was already in place

If you build an application for autistic people, you cannot build it "fast and a little unsafe". A flawed AI response can push someone into a crisis. A piece of diagnosis information passed through to the wrong place can cost a job or shape a custody case. An interface that is too sensorially intense excludes part of the audience from the first screen.

From this threat landscape architectural decisions emerged that, in retrospect, line up with enterprise requirements. An anti-ABA filter (protection against responses that try to normalise or condition autistic people) is, technically, a form of output safety in the OWASP sense. Crisis detection redundantly in frontend and backend is defense in depth in the ISO 27001 sense. IP pseudonymisation is data minimisation under GDPR Article 5. Soft delete with a grace period is a forward-looking implementation of the right to restriction under Article 18.

None of these decisions were made to satisfy a standard. They were made because a vulnerable target group needed them. The fact that they happen to be standards-compliant is the unintended consequence.

How this connects to the peer review

The scientific journal Autism in Adulthood (Mary Ann Liebert, Impact Factor 9.5, Q1 in Developmental Psychology) is currently reviewing a submission that frames the concept behind Autistic Mirror. A scientific review does not look only at idea and ambition. It looks at the actual implementation. Software without a solid safety and ethics architecture is hard to defend in review. Methodological soundness on the scientific level and architectural soundness on the technical level are rooted in the same point.

Compliance is therefore not a separate layer placed on top after the fact. It is the precondition for the scientific review to even be meaningful. What a vulnerable group needs in terms of safety and dignity overlaps with what a serious scientific review demands in terms of methodological soundness. Both rest on the same point: a product must not cause additional harm to the people it is meant to help.

An observation about small structures

Compliance at this depth is something enterprises build over years. Security teams, legal departments, UX research, external audits, quality assurance. The fact that a very small structure can land near a similar point in a first product version has a specific reason.

Autism research describes a processing pattern that can be called simultaneous self and system observation: self-observation and system-observation run in parallel rather than sequentially. Combined with a biography that knows the consequences of badly built systems from the inside, this produces a requirement list no specification document ever delivers. Where a classical product team asks "what does the market demand", this processing mode asks "what happens to the human who uses this if something goes wrong here".

Markets often demand exactly what people need. They just phrase it in another language: as compliance, risk, reputation, audit. Building from the other direction, from what a person concretely needs, sometimes lands at the same point the standard sits at. Not because anyone read the standard. But because the standard rests on the same ground: that a system must not damage people.

A bright spot

Building a product from substance lets compliance evidence be consolidated within days, because the substance is already there. Building a product from compliance often does not allow human need to be retrofitted, because the substance is missing. It is a question of order. And it decides whether a product ends up being both: viable for the people it was made for, and viable for the organisations buying it.

Autistic Mirror is an AI chat that explains what is happening in the autistic nervous system. For autistic adults and their environment. Mechanism instead of advice. Explanation instead of correction. The app is not a medical device and does not replace medical or therapeutic treatment. It is a neurological translation layer, built with respect for the people it serves and, as it turns out, in a state that already meets most enterprise requirements.