When buyers ask who owns the code app development agency teams write, our answer is short: you do, from the first commit. You also own the repositories, cloud accounts, app store listings and signing keys, because they sit in your name before we start.

Below is exactly how we set that up, what you receive at each step, and how much of your time it takes. If a vendor cannot match each step, you have a lock-in risk.

Who owns the code app development agency teams write: the contract terms

Ownership starts in the contract, and the usual shortcut is weaker than people think. Under US law, "work made for hire" covers employees. For outside contractors it applies only to a short list of work categories, as the US Copyright Office explains in Circular 9. Custom software often falls outside that list.

So our contracts include an explicit assignment of IP, not just a work-for-hire label. The clause transfers copyright in everything we write for you. It also covers designs, schemas and infrastructure code.

The three clauses we put in writing

  • Assignment: all project deliverables transfer to you. Assignment takes effect as each invoice is paid. That is our one condition, and we state it plainly.
  • Pre-existing tools: some code we reuse across projects, such as a logging wrapper or a deploy script. You get a perpetual, royalty-free licence to use and modify it. We list these items by name in an appendix, so nothing is vague.
  • Open-source components: these stay under their own licences, such as MIT, Apache 2.0 or BSD. We name each one and flag any copyleft licence, like GPL, before it enters the codebase.

Contract review typically takes your lawyer one to three hours. We send the IP section first so it does not hold up the rest.

If you want to see these terms in context, see how a project with us runs from contract to handoff.

Step by step: what you receive and when

Day 0: accounts in your name

Before we write code, you create the accounts that matter. Then you invite us as members, not owners. This takes most clients 60 to 90 minutes, and we send a checklist with links.

  • A GitHub or GitLab organisation you own, with us added as collaborators
  • Your cloud account (AWS, Google Cloud or Azure), with billing on your card
  • An Apple Developer Program membership in your company's name, with you as Account Holder
  • A Google Play Console account, also in your company's name
  • Domain registrar and DNS access, plus any third-party services such as Stripe or SendGrid

The Apple step trips people up most. Enrolling as an organisation needs a D-U-N-S number, and that can take several days. We start it in week one so it never blocks a release.

Weeks 1 to N: code lands in your repo daily

Every commit goes to your repository, not ours. There is no private mirror and no end-of-project upload. If you stopped paying us on a Friday, you would still have everything up to Thursday night.

You also receive a short weekly summary. It lists merged work, open decisions and any new dependency. Reading it takes about 10 minutes.

During the build: decisions get written down

When we make a choice that a future developer would question, we write an Architecture Decision Record. It is a half-page file in the repo with the decision, the options we rejected and the reason. Examples include "Postgres over DynamoDB" or "why we cache tokens for 15 minutes".

A typical mid-sized build produces 10 to 25 of these. They cost us minutes each. They save the next team days of guessing.

Final 1 to 2 weeks: the handoff

Handoff is a scheduled phase with its own line in the plan, not a goodbye email. It usually runs one to two weeks, and it needs 4 to 8 hours of your team's time.

  1. Access audit. We list every account, key and secret together, then confirm you hold admin rights. We remove our own access when you say so.
  2. Walkthrough sessions. We hold two or three recorded calls of about an hour each. They cover architecture, deploys and the parts of the code most likely to break.
  3. Dry-run deploy. Your developer, or your new vendor, ships a small change to production while we watch. If they get stuck, the docs are wrong and we fix them.
  4. Sign-off. You confirm you can build, test and release without us.

What lock-in actually looks like

Lock-in rarely comes from bad intent. It comes from defaults set on day one that nobody revisits. Here is the comparison we walk buyers through.

Agency-held setup

  • Repo lives in the agency's organisation
  • App store listings sit under the agency's developer account
  • Cloud billing runs through the agency, often with a markup
  • Signing keys and secrets sit on one developer's laptop
  • Moving away takes weeks, plus an app transfer process for each store

Client-held setup

  • Repo, cloud and stores sit in your name from day zero
  • The agency has scoped access that you can revoke in minutes
  • Secrets live in a managed store, such as AWS Secrets Manager or 1Password
  • Moving away takes a handoff, not a migration

Apple and Google both support transferring apps between accounts. Still, transfers have conditions and can take time. It is far simpler never to need one.

The documentation package we deliver

A repo link is not documentation. Here is what you get, and roughly how long a new developer needs to read each part.

  • README: how to clone, install and run locally in under 30 minutes
  • Architecture overview: one diagram and two pages on how the pieces connect
  • Runbooks: step-by-step guides for deploy, rollback, rotating secrets and restoring a backup
  • Decision records: the ADRs described above
  • API reference: generated from an OpenAPI spec, so it stays in sync with the code
  • Dependency list: every third-party package with its version and licence

For the dependency list we produce a Software Bill of Materials in a standard format. CISA's SBOM guidance explains why that matters for security reviews. It also helps when a buyer's due-diligence team asks what is inside the product.

What it costs you in time

Ownership is not free on your side, but the cost is small and front-loaded. These are typical figures for a three to six month build.

  • Contract and IP review: 1 to 3 hours of legal time
  • Account setup on day zero: 1 to 2 hours, plus waiting time for Apple enrolment
  • Weekly summaries: about 10 minutes each
  • Handoff phase: 4 to 8 hours across walkthroughs and the dry run

In total, that is usually under 20 hours across the whole project. Compare that with the weeks it takes to unpick an agency-held setup later.

Where we push back

Sometimes a client asks us to hold the accounts "just to keep things simple". We say no, politely. Convenience in month one becomes leverage someone else holds in month eighteen.

We also push back on skipping the dry-run deploy. It is the only test that shows the docs actually work. If nobody on your side can ship a change, the handoff is not finished.

FAQ

Does an app development agency own the code by default?

Often, yes, unless the contract says otherwise. In the US, a contractor usually keeps copyright unless there is a written assignment. Check for an explicit IP assignment clause, not just the words "work for hire".

What should a software handoff include?

At minimum: admin access to every account, a README that gets a developer running locally, deploy and rollback runbooks, and a list of dependencies with licences. A good handoff also includes recorded walkthroughs and a dry-run deploy by your own team.

Can I move my app to a new developer without losing App Store reviews?

If the app is already in your own developer account, yes. You simply add the new team as users. If it sits in the agency's account, you need an app transfer, which keeps reviews but has eligibility rules you should check first.