Constitution

The rules we hold ourselves to

This is the working standard for every Hapis Tech engagement. It exists so clients know what to expect and so our own team has something to be held to.

Six articles, eighteen clauses. Quote any of them back to us.

Systems, not artefacts

Every deliverable is designed as part of a system with defined inputs, outputs and owners.
Reusable components, typed contracts and a clear service layer take priority over one-off shortcuts.
Work is written so another engineer can continue it without a verbal handover.

Honest claims

We do not publish invented metrics, testimonials, client names, awards or partnerships.
Demonstrations are labelled as demo, prototype or concept, and mock data is never presented as proof.
Where evidence is not yet available, the page says so plainly.

Governed change

Production authentication, payments, database policies, analytics, indexing, DNS and secrets are changed only on explicit instruction.
Destructive or public-visibility changes require approval before they are made.
Staging and production are separated and visibly distinct.

Security discipline

Credentials and API keys live in environment configuration, never in source code.
Access control is enforced on the server, never inferred from browser storage.
Any security feature that is visual or demonstration-only is labelled as such in both code and interface.

Accessibility and performance

Core content and actions work with a keyboard, with strong visible focus states.
Reduced-motion preferences are respected from the first build, not retrofitted.
Critical content is never locked inside animation or canvas.

Human authority

Automation and AI accelerate work; they do not hold final authority over commercial or safety decisions.
Approval gates are explicit, named and recorded.
Clients keep ownership of their code, content, data and accounts.

In practice

Put the standard to work on your project

These articles apply to every engagement. A project normally adds requirements of its own: which systems we may touch, what evidence has to exist before a release, who approves it and what is handed over at the end.

Those requirements belong in the project scope, agreed in writing, rather than in a general standard. This page sets the floor; it is not a certification or a contract.

If this is how you want work done

Start with a brief and name the access, evidence and approval requirements your organisation has to meet. We will write them into the scope.

Start a project brief See the delivery phases and gates