Client-owned repositories mean the git remote sits in your GitHub, GitLab or Bitbucket org. Client-owned cloud means AWS, GCP or Azure accounts you control. Domains and store listings follow the same rule. Partners get access; they do not become the landlord.
Blog · 2026-10-24
Why client-owned repositories matter in software partnerships
Who holds the git remote, cloud account and deploy keys decides whether you can exit a vendor cleanly. How to insist on ownership without slowing delivery.
Ownership is an exit plan, not a paperwork preference
Buyers often treat “who owns the repo” as a legal clause to skim. It is an operations decision. If the only remote, the only cloud login and the only deploy path live under a partner’s organisation, ending the engagement means negotiating for your own product.
Three Index writes this into how we engage from day one. It is not an upsell — it is the default so you can keep the software when priorities change.
What “you own everything” actually includes
Repository access alone is not enough. A partner can leave you a repo while keeping production in an account you cannot open, or secrets in a vault you never joined.
A complete ownership checklist covers: source remotes, CI configuration, staging and production environments, domain registrars, app store accounts, monitoring and error trackers, and the password manager or secret store that holds production keys. If any of those stay only with the vendor, you have a soft lock-in even when the contract says you “own the IP.”
Write the checklist into kickoff. Related reading: avoiding vendor lock-in without building everything — ownership of accounts is the practical half of that advice.
Why agencies still push host-in-our-account models
Hosting everything under the delivery firm is faster in week one: one bill, one login, fewer procurement tickets. It also concentrates risk. When the relationship ends, migration becomes a project instead of a permission change.
Some partners also prefer opacity — you never see how brittle the pipeline is until you try to take it over. Client-owned accounts make staging something you can click every two weeks, which is harder to fake with status slides.
If a proposal requires their cloud “for security,” ask who can revoke access and who pays the invoice when the contract ends. Security and ownership are not opposites.
How ownership shows up in daily delivery
Named engineers open pull requests in your org. CI runs on runners you approve. Staging URLs resolve in your DNS. Incident channels include people who will still work there after the partner rotates off.
That pattern matches written scope and biweekly increments: progress is software you can open, not a private demo environment that disappears with the contract. See how we operate for the same four habits — scope, named people, staging, ownership.
Dedicated capacity fits the same model. A dedicated development team works in your repo on your backlog; the remote does not move when headcount changes.
Vibe-coded MVPs need ownership before the next feature wave
Products spun up with Cursor, Claude or similar tools often start in a personal account or a prototype host. That is fine for a weekend. It is dangerous once customers or payments appear.
What to put in the brief and the SOW
Name the org that will hold git and cloud. Require infrastructure as code and CI that runs without a partner laptop. List credentials that must be rotated into your vault before go-live. Say that work stops if delivery drifts into accounts you cannot access.
01
Fixed-price slices still fit. Ownership is not the opposite of a clear milestone — it is how you keep the milestone after the invoice is paid. If the partner needs temporary elevated access, time-box it and revoke it.
02
For cloud hygiene in accounts you keep, see DevOps and cloud. For product work in the same repos, start from services.
Red flags when a partner resists
Refusal to use your git org. Production only in their AWS organisation. Deploy keys that only their staff hold. “We will hand over at the end” without a date or a dry-run migration. No staging URL you can open yourself.
Any of those means exit cost is being deferred into your future. Push back early. A partner who ships well in accounts you own is demonstrating confidence; a partner who cannot is selling dependency.
Three Index declines engagements that require us to be the only holder of your production path. That filter protects both sides.
Ask for ownership in the first conversation
When you send a brief, say where the repo and cloud should live. Ask who will hold deploy rights on day thirty. If you already have a prototype in a personal account, say so — moving it is part of scope, not an afterthought.
You should get a written reply that treats ownership as a delivery constraint, not a legal footnote. That is how software stays yours after the partnership ends.
FAQ
Short answers related to this article.
Who should own the repository in a software partnership?
You should. The git remote, cloud account, domains and credentials belong with the client so you can keep shipping if the partnership ends. Partners work in your accounts; they do not hold the only copy.
Is client-owned hosting slower than letting the agency host everything?
Usually not. Staging and production in accounts you own is normal CI/CD. The delay comes from unclear access in week one, not from ownership itself. Write access into the kickoff checklist.
How does Three Index handle repository and cloud ownership?
Repository, cloud, domains and credentials stay yours. We work in your accounts wherever possible, ship to staging you can open, and leave operator notes with the code — see how we work and send a short brief if you want that written into scope.
Why Three Index
AI-first software development company in Ahmedabad — not an investment fund or three-fund product. Founded 2020. Fifty-plus IT professionals. Five hundred-plus projects shipped.
We are a software engineering company: large enough to staff serious products and small enough that the people who wrote a module can still explain it. See how we operate, our AI development work, browse case studies, read what Three Index is (and is not), or join the team.
Tell us what you are trying to build.
Send a short description of the project. You will get a reply from someone technical — with questions worth answering, not a brochure.