Trust & security

Building your software means holding your keys.

To do the work we usually need access to your hosting, your domain, your analytics and sometimes your payment provider. That deserves more than a line in a contract.

Ask us something specific

Least: Access we ask for
Yours: Who owns the accounts
On handover: When our access ends
None: Certifications claimed

Access

The smallest key that opens the door.

Most security failures in agency work are not break-ins. They are access that was granted broadly, never scoped down, and never revoked.

We ask for the narrowest role

Not an admin account

Where a platform has roles, we take the lowest one that can do the job — editor rather than owner, deploy rather than billing. If a task genuinely needs full access, we ask for it for that task and say so.

Accounts stay in your name

We are invited, not the owner

Your domain, hosting and analytics are registered to you, billed to you, and we are added as a collaborator. This is the single most important line on this page — a studio that owns your accounts owns your business's continuity.

Access ends at handover

You do not have to ask

When a project closes we remove ourselves from the accounts and tell you we have. If you want us to stay on for maintenance, that is an explicit decision rather than an oversight.

No shared logins

Individually attributable

Every person who works on your project has their own named access. A shared password means nobody can tell afterwards who did what, and offboarding one person means changing it for everyone.

Handling

Where credentials actually live.

A password manager, never a message

No email, no chat

Credentials come to us through a password manager or a one-time secret link. If you send us a password in an email or a chat thread, we will ask you to rotate it — those messages are searchable, backed up and forwarded for years.

Secrets never enter the repository

Environment only

API keys and tokens live in environment variables on the host, not in code. A secret committed once is in the history permanently, and history gets cloned.

Client data stays in your systems

We don't take copies

We work against your database, not a copy of it on someone's laptop. Where a local copy is genuinely necessary for a migration, it is scrubbed of personal data first and deleted when the work is done.

Two-factor on everything

On our side too

Every account we hold access to is behind two-factor authentication, including our own email and password manager. Most compromise of a small studio arrives through the studio, not the client.

Being straight with you

What we are not claiming.

Plenty of companies imply certifications they don't hold. We'd rather list ours honestly — which currently means listing none.

No SOC 2 or ISO 27001

Not audited

We have not completed a third-party security audit. The practices above are real and followed, but they are our description of our own process, not an auditor's. If you need certification for procurement, tell us and we will be straight about the timeline rather than implying we have one.

We're a small team

Know the trade-off

There is no 24/7 security operations centre here. What there is: a small number of people, a small number of systems, and no incentive to hold data we do not need.

You should still keep your own backups

Whoever builds it

We set up backups and we test that they restore. You should still be able to recover without us — ask us to show you where they are and how to use them, and we will.

Report something

We'll respond

Found a vulnerability in something we built? Send it through the contact page and we will acknowledge within one business day. We will not threaten anyone acting in good faith.

Ask before you hand anything over.

If there's something here you need clarified for your own compliance, ask — a real person answers.