Skip to content
HAPISTECH

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.

01

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.
02

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.
03

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.
04

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.
05

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.
06

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.

Next

If this is how you want work done, start with a brief.

Start a project brief