Security

Security is part of how we build - not a slide at the end. Practices scale with the product; the principles do not.

Secrets

API keys and credentials live in environment variables or a secrets store - never in git.
Repos get .env.example with empty placeholders and setup notes (as on this site for Web3Forms).
Client-exposed keys (e.g. public form endpoints) are scoped and domain-restricted where the provider allows.
Server-only secrets stay server-only; they are not embedded in static bundles.

RLS and tenant isolation

On Supabase-backed apps, Row Level Security is the default boundary between tenants.
Policies are designed with the data model - not bolted on after the demo works.
Service-role keys are treated as break-glass: never shipped to the browser.
Multi-tenant designs assume hostile tenants until proven otherwise.

Data residency (UK / EU)

Prefer UK/EU regions for databases and object storage when client or regulatory needs require it.
Third-party processors (email, SMS, payments, AI APIs) are chosen and documented with residency and DPA awareness.
This marketing site itself stores no customer application data - contact messages go to the configured form/email destination.

What we do not claim

We do not advertise certifications we have not earned, or invent audit theatre. If a client needs a formal security questionnaire or pen-test path, we treat that as a scoped engagement - honestly.