Your code, your repo, your cloud — from day one

The IP arrangement on most engineering engagements works like this: the vendor builds the system in their environment, in their repo, on their cloud account, with their tools. At the end of the engagement, there is a “transition” where the code, infrastructure, and operational knowledge are supposed to move to the client. In practice, the transition is partial, the documentation is thin, and the client is reliant on the vendor for the next year.

We don’t do that.

What “from day one” means

The first commit goes to your GitHub organisation. The infrastructure runs on your AWS / GCP / Azure account, billed to your card from day one. CI runs in your GitHub Actions, deploying to your cluster. Your engineering team has admin access to everything from week one. There is no “transition phase” because there was never anything to transition.

If you fired us in week six, you would already own everything. That is the test.

Why it matters

Three reasons, in order of how often clients raise them:

1. Lock-in defence. The longer code lives in a vendor environment, the more switching costs accumulate — not because the code is hard to move, but because the operational knowledge leaks slowly during transition. Day-one ownership means switching costs never accumulate.
2. Audit / compliance. Most regulated buyers (HIPAA, MAS, FCA, DPDP, FedRAMP-adjacent) need to be able to demonstrate full control of their stack. “Our vendor has the code” doesn’t pass audit. Day-one ownership is what auditors want to see.
3. Continuous review. Your engineering leadership reviews every PR as it lands. They aren’t approving a finished system at the end; they are watching it get built. That changes both the quality of the work and the depth of internal knowledge that survives the engagement.

The operational pattern

Here is the typical setup, day one:

• We get added as outside collaborators to your GitHub org. Push permissions to a feature branch, PR-only to main.
• Your engineering lead is named as a required reviewer on PRs touching production-impacting code.
• Infrastructure-as-code (Terraform / Pulumi / CDK) lives in your repo, applied via your GitHub Actions to your cloud accounts.
• Secrets live in your secret manager (AWS Secrets Manager, GCP Secret Manager, etc.). We get short-lived access; access is revoked at engagement end automatically.
• Observability (logs, metrics, traces) flows into your account. We get read-only dashboards.
• All third-party services (Anthropic, OpenAI, Stripe, Twilio, etc.) are billed to your accounts, on your API keys.

The operational graph is yours. We are visible inside it, but never above it.

What we keep

Methodology playbooks, prompt libraries, internal SOPs, code-generation templates — these stay with us. They are the leverage that lets us deliver fixed-price; they are not deliverables. We document this clearly in the SOW so there is no ambiguity at engagement end.

Open-source dependencies remain under their respective licences. Anything generated specifically for your engagement is yours.

The engagement-end checklist

When an engagement closes, here is what changes:

• We are removed from your GitHub org (you initiate this).
• Our short-lived cloud-access tokens expire automatically.
• Final SOPs and runbooks are committed to your repo.
• A 30-minute handover call with your engineering lead — usually unnecessary, since they were on every PR.

There is no invoice held back pending “transition complete.” There is no key in our pocket. The system was always yours.

Read more: /build/ · /about/ · /legal/terms/