Who owns the code when you hire a London software consultancy?

Who owns the code when you hire a London software consultancy? You should: repository, cloud accounts, domain, and data in your name from the first commit, not after a painful exit. If you only rent access to someone else's platform, you do not have a product; you have a dependency.

What you should own

Code means the Git organisation and every application repo, with history intact. CI and deploy pipelines should run from that same org. Cloud accounts (AWS, GCP, Azure, or your own metal) should bill to you. The domain and DNS stay yours. Production data and backups stay yours. Third-party licences (Stripe, email, maps) should be under your contracts wherever the vendor allows it.

A good London partner works inside those boundaries. They get IAM roles and repo access; they do not become the landlord. At Eight Mile that is the default for SaaS and software development: survey, fixed written price, warranty, and you own the lot from day one.

What "from day one" looks like

Before serious build, you create the cloud account and the Git org. Billing alerts hit your inbox. The first pipeline deploys to an environment you can open. Credentials live in your secret store, not a spreadsheet on the agency's laptop. When someone leaves the project, you revoke access in one place.

I've walked into rescues where nobody could say which AWS account was "production" and the only full backup sat on a contractor's machine. That is not a paperwork quirk. That is operational risk you paid for.

Buyers often treat ownership as a legal annex. Treat it as delivery design. The first sprint either lands in your org or it does not. Changing that later means migrations, downtime risk, and a negotiation you should never need.

Red flags in proposals

Watch for agency-owned GitLab or Bitbucket you will "get a copy of later." Shared hosting with no export path. Phrases like "we licence you the software" or "hosted on our multi-tenant platform" when you thought you were buying a bespoke product. Contracts that assign IP only after final invoice, or that keep "framework" code forever. Vague talk of "source available on request."

Ask plainly: whose AWS account, whose GitHub org, whose domain, who pays Stripe. If the answers dodge, assume lock-in until proven otherwise. A serious partner will put the ownership map in writing before kickoff, not wave at "we'll sort IP in the MSA."

Own-IP partner vs locked-in build

• Own-IP partner. Repos in your org from day one; cloud on your account and bill; exit means revoke access and keep running; you bought an asset you can hand to another team.
• Locked-in build. Their forge, exit is a project; their tenancy or opaque shared stack; migrate under pressure; you bought a service relationship.

Both can ship features. Only one leaves you able to hire someone else without rewriting history.

What to ask before you sign

Demand written confirmation that IP in custom work assigns to you, repos live in your org, cloud and domain stay in your name, and you receive admin access before go-live. Ask how backups are restored and who holds the break-glass credentials. None of that replaces a solicitor; it is the practical checklist founders skip while arguing about day rates.

Who owns the code when you hire a London software consultancy should never be a mystery after kickoff. Mystery is a choice the proposal already made. Prefer the partner who is bored by the question because their default already matches your checklist.

If you want a London partner that builds in your accounts and leaves you the keys, contact Eight Mile and say what you are planning to ship.