Security posture.

The founder owns the infrastructure

The single most important security decision we make is architectural, not technical: every piece of infrastructure we set up during a sprint is set up in an account the founder owns. Their GitHub organisation. Their Vercel team. Their Stripe, Resend, Postgres host, and domain registrar. We are added as collaborators for the duration of the engagement. We are removed at handover or on request.

This is a security decision because it means the blast radius of any compromise of oursystems is bounded. Our team cannot hold a founder's codebase hostage, exfiltrate customer data after the engagement ends, or be a single point of failure for their infrastructure access.

Access during a sprint

While a sprint is running:

• Every team member who touches founder systems uses an individual account — no shared logins.
• Two-factor authentication is required on every service we use — GitHub, email, cloud consoles, password managers. We check this on the first day of every engagement.
• Access is granted at the minimum role needed to do the work. “Owner” access is avoided where a “Developer” or “Collaborator” role will do.
• Credentials the founder needs to share with us are transferred through a shared, audited vault — not over email or chat.

How we handle secrets

Secrets never live in source. They are set in the deployment platform's secret manager (Azure Key Vault, Vercel environment variables, and similar), with different values per environment. They are never printed to logs, committed to the repo, or sent in email.

We scan every commit for accidental secret exposure. If a secret is committed in error, we rotate it immediately, rewrite history where possible, and notify the founder.

At handover, any shared credential that was used during the sprint is rotated out. The founder sets new values. We do not retain copies.

The code itself

The code we produce follows defensive engineering defaults:

• HTTPS everywhere. No plaintext transport. HSTS enabled at the platform layer.
• Auth done properly. Password hashing with modern algorithms (bcrypt or Argon2id), rate limiting on sign-up and password-reset endpoints, email verification where the product requires it, session invalidation on password change.
• Input validation. Server-side validation on every request boundary, typed end-to-end with a schema library.
• SQL injection protection. Parameterised queries or an ORM that parameterises for us. Raw concatenation of user input into SQL is a review blocker.
• XSS protection. Output encoded by default in the framework we use. Content Security Policy configured on new projects.
• CSRF protection. Built-in tokens on mutating forms, same-site cookie attributes set.
• Dependency hygiene. We pin dependency versions, review upgrades, and subscribe to security advisories for the major packages.

Data we process during a sprint

A sprint may involve handling sample or production data the founder provides so we can test against realistic inputs. When that happens:

• Data is stored in founder-owned systems — typically a staging database in the founder's account — never on our local machines beyond a build session.
• Where possible, we work with synthetic or anonymised data instead of real customer data.
• If production data must be used, we document the fact, use it for the minimum time necessary, and delete it when the need is over.

Our own systems

The systems we operate internally (email, project management, source control, shared vaults) are configured as follows:

• Two-factor authentication enforced on every service that supports it.
• A password manager used for any credential not covered by SSO.
• Laptops run up-to-date operating systems with disk encryption and screen-lock enforced.
• Regular audits of access — who can get in where, and whether they still need to.

What we don't claim

We are a small studio. We are not SOC 2 certified, not ISO 27001 certified, not HIPAA- or PCI-audited. If your product falls into a regulated category that requires any of these, we'll say so on the discovery call, and recommend partners better suited to the engagement.

We do design and build to defensive defaults that most unregulated founders find more than adequate. Where your engagement needs something more formal — a DPA, a subprocessor list, a bespoke security schedule — we're happy to negotiate those terms alongside the engagement contract.

Reporting a vulnerability

If you believe you've found a security issue on this website or in a product we've built — but only those we've built, not unrelated third-party products — please email security@aidevcrew.comwith a description and steps to reproduce. We'll acknowledge within two business days and keep you updated while we investigate.

We appreciate responsible disclosure and will work with researchers in good faith. We do not currently operate a paid bug bounty.

Incident response

If we become aware of a security incident affecting a founder's systems or data we are responsible for, we will:

1. Contain the incident, rotating credentials and revoking access as appropriate;
2. Notify the founder directly within 24 hours of discovery;
3. Investigate and document what happened, with what data, and through what vector;
4. Notify affected individuals and the Office of the Australian Information Commissioner where required under Part IIIC of the Privacy Act 1988;
5. Make whatever permanent changes to our process are needed so the same incident cannot recur.

Contact

Security matters: security@aidevcrew.com
Privacy matters: privacy@aidevcrew.com
Everything else: hello@aidevcrew.com