Standards

A standard that is not enforced is an aspiration. Most organisations have standards. Fewer have standards that are consistently applied, measurably met, and actively maintained.

The gap between documented standards and applied standards is where technical debt accumulates. Every deviation that is tolerated is a precedent. Precedents compound.

Standards — not enforced is an aspiration; enforced is an advantage. The gap between documented standards and applied standards is where technical debt accumulates: every deviation that is tolerated is a precedent, and precedents compound. What standards cover, across five areas: Coding Standards (how code is written, structured and reviewed — standards that make code maintainable, testable and understandable); API Standards (how APIs are designed, documented, versioned and governed — consistency that keeps the API surface predictable and governable); Accessibility Standards (WCAG compliance, semantic markup, keyboard navigability — accessibility as both a technical standard and a legal requirement); Architecture Standards (the patterns and constraints that define how systems are structured, preventing architectural drift and uncontrolled complexity); and Security Standards (the baseline security requirements applied to every system — not aspirational, but enforced). The approach: every engagement at Sixteen Pillars applies the same tested framework for security, standards and accessibility — not adapted per project, but applied consistently. This is not rigidity; it is the result of consistent experience, because the cost of applying standards correctly at the start is lower than the cost of remediating their absence later. This is delivered through three engagement models: Build & Oversee (build to standard, oversee to keep standards applied and effective), Consultancy (assess, define, implement — make standards operational), and Fractional CTO (provide technical leadership to embed standards in the right way).

What standards cover

Coding standards. How code is written, structured, and reviewed. Not style preferences — standards that determine whether code is maintainable, testable, and understandable by someone who did not write it.

API standards. How APIs are designed, documented, versioned, and governed. Consistency that makes the API surface predictable. Standards that prevent the API proliferation that makes integration landscapes ungovernable.

Accessibility standards. Technical accessibility requirements — WCAG compliance, semantic markup, keyboard navigability. Accessibility is a technical standard and, increasingly, a legal requirement.

Architecture standards. The patterns and constraints that define how systems are structured. What is permitted and what is not. Standards that prevent the architectural drift that produces systems nobody fully understands.

Security standards. The baseline security requirements applied to every system. Not aspirational. Enforced.

The approach

Every engagement at Sixteen Pillars applies the same tested framework for security, standards, and accessibility. Not adapted per project. Applied consistently.

This is not rigidity. It is the result of consistent experience: the cost of applying standards correctly at the start is lower than the cost of remediating their absence later.

Start a Conversation