Security is part of how we build, not a checkbox at the end.
We work with teams in healthcare, fintech, enterprise, and government, where confidentiality and reliability are the price of entry. So we plan for them from the first call. Here is how we handle your access, your data, and your intellectual property, in enough detail to take to your security team.
Last updated: July 2026
The practices, in plain terms.
The defaults on every engagement, whether or not the contract asks for them.
NDA first
We are happy to sign your NDA before the first detailed conversation, so you can be candid about the problem from the start.
Your cloud, your code
Accounts, infrastructure, and repositories are created under your name from day one. Where you want it, the GitHub repositories live inside your organisation and we join as invited members.
Least-privilege access
Each person gets only the access their work needs, scoped and time-bound. When someone rolls off, their access is removed the same day, and everything goes when the engagement ends.
Separate environments
Development, staging, and production are separate from the first deploy. Changes reach production through review and a deploy pipeline, never by hand.
No production data on laptops
We develop against masked or synthetic data. Real customer data stays inside your environments, and any debugging that genuinely needs it happens there too.
Secrets stay out of code
Credentials never live in the codebase. They sit in a secrets manager, scoped per environment, and are rotated when people leave or the engagement ends.
Backups and recovery
Production data gets automated backups, and we treat a restore that has never been tested as no backup at all. Recovery steps are written down before they are needed.
Monitored in production
Error tracking, logging, and alerting ship with the product, so we usually know something broke before a user has to tell you.
Dependencies kept current
Updates and vulnerability patches are part of normal weekly delivery, not an annual event that someone has to remember to schedule.
No question about who owns the work.
What we build for you belongs to you.
- You own everything we build for you: the code, the design files, and the data
- Work happens in your repositories and cloud accounts, under your organisation where you want it
- No reuse of your proprietary work for anyone else
- Clear handover and documentation so your team can take over any time
- Access is revoked promptly when a person rolls off or the engagement ends
- Subcontracting only with your knowledge, under the same confidentiality terms
Incidents, handled like adults.
Software breaks. What separates teams is what happens in the hour after. This is our default, and if your organisation has its own incident process, we plug into that instead.
Stabilise
Alerts reach us directly. We stop the damage first, rolling back or failing over, and dig into the root cause once users are safe.
Tell you plainly
You hear from us before you have to ask: what broke, who it affected, what we did, and what happens next. No silence and no spin.
Fix the class, not the instance
A short written post-incident review: what failed, why, and the change that keeps that whole class of failure from coming back.
AI assistants, with a clear boundary.
We are an AI-native studio, and our engineers use AI coding assistants every day. Used well they are a genuine advantage. Used carelessly they are a leak, so the boundary is explicit rather than assumed.
Assistants may see the code we are writing for you, on paid business plans that do not train on customer data. They never see production data, customer records, credentials, or secrets. Those stay in your environments and out of every prompt.
If your policy is stricter, for example no third-party AI tools on your codebase at all, we agree that in writing at the start and work that way.
An honest word on compliance
We do not hold ISO 27001 or SOC 2 certifications today, and we will not pretend otherwise. Our practices are aligned with the controls those frameworks expect, and we are happy to walk your security team through exactly how we work, questionnaire and all. If your project carries specific obligations, for example around health or financial data, tell us early and we will plan the engagement around them.
Questions your security team will ask.
What security-minded buyers ask us, answered straight.
Are you ISO 27001 or SOC 2 certified?+
No, and we will not imply otherwise. Our practices are aligned with the controls those frameworks expect, and we are glad to complete your security questionnaire or walk your team through how we work in detail.
Who can see our code and data?+
Only the people working on your engagement, and you can have that list at any time. Code access is scoped per person. Production data stays in your environments and is never copied to ours or to anyone's laptop.
Where does our data live?+
In your cloud accounts, in the region you choose. We build inside your infrastructure rather than pulling your data into ours, so nothing about where your data lives changes because we showed up.
Do AI assistants see our codebase?+
By default yes, for the code we are writing, on paid plans that do not train on your data. They never see production data or secrets. If you want no AI tooling on your codebase at all, say so and we will work that way, agreed in writing.
What happens when something breaks in production?+
Alerting tells us early, we stabilise first and diagnose second, and you hear from us before you have to ask. Every incident ends with a short written review and a change that prevents the repeat.
What happens to access when we part ways?+
It ends. Accounts are removed, keys and secrets we touched are rotated, and the documentation for all of it is already in your hands, because it was written during the build rather than at the exit.
Have requirements we should plan around?
Tell us about the obligations your project carries. We will build the engagement to respect them from day one.