Do I Own My App if I Hire Developers to Build It?

We worked on a sports club app that was meant to handle finances, games, schedules and players across several different sports. The client had serious funding behind it. We advised launching with one sport, on one platform, as an MVP, then releasing more over time. They pushed back on all of it and wanted everything ready before anything went live. Feature after feature went in, the budget ran out, and nothing ever reached the store. By the time the relationship ended, the question of app ownership with developers had a slightly sad answer. They owned a large pile of code and design files for a product no member of the public had ever opened.

A contract can hand you every line of code and still leave you unable to ship.

That's the gap most founders miss. Ownership gets talked about as if it's one thing, settled by one clause, when really it spreads across code, designs, research, store accounts, hardware specs, third-party licences and the decisions that explain why the product works the way it does. You can hold the copyright and still be stuck, because somebody else holds the Apple account or the repository or the only person who understands the hardware interface.

So this piece walks through what you actually own, what you only think you own, and what to settle in writing before the first sprint starts.

What You Are Actually Buying When You Hire Developers

When people picture app ownership when hiring developers, they picture a folder of code arriving at the end. The code is the smallest part of it. You're buying a product that exists in several places at once, and each place has its own owner, its own account and its own contract.

We worked on a fitness and wellness product with two co-founders who were new to the whole process. That project never produced a line of shipped code. The budget went into design and research, round after round of it, and then it was gone. What the founders owned at the end was a set of design files, a research base and a lot of documented thinking. Real assets, and worth having, though not what they came for.

The five things you are paying for

Source code sits alongside design files, research and its reasoning, the accounts the product lives in, and the specifications that explain how everything talks to everything else. Treat those as five separate questions rather than one. A contract that transfers code and says nothing about the Apple developer account has answered one fifth of the problem.

The useful test is simple. If your agency disappeared tomorrow, could another team pick this up and release an update within a month? If the answer is no, you don't own the product yet, whatever the paperwork says.

The Default Legal Position on Code You Paid For

This part surprises people, so it's worth being plain about it. We're a design and product consultancy rather than a law firm, and anything below should be checked with a solicitor against your own contract. The general position in the UK, though, is clear enough.

Under UK copyright law, the person who writes the code owns the copyright in it. If a developer is your employee and writes it as part of their job, the copyright sits with your company by default. If the developer is a contractor, a freelancer or an agency, the copyright stays with them unless there's a written assignment transferring it to you.

Paying an invoice doesn't move copyright. It pays for the work. Courts often read an implied licence into the arrangement, so you can usually use what you paid for, but an implied licence is a thin thing to build a company on. It doesn't reliably let you modify the code, hand it to a new agency, or sell the business with the software attached.

Assignment has to be in writing

The transfer needs to be written down and signed. Verbal agreement, a friendly email, a line in a proposal deck, none of those do the job properly. Get the assignment into the contract before the work starts, because negotiating it afterwards puts all the leverage on the other side of the table.

Contract Clauses That Decide Ownership

A handful of clauses carry almost all the weight here. Most development agreements have some of them. Very few have all of them, and the missing one is usually the one that bites two years later when you're raising money and somebody's lawyer reads the file.

App ownership with developers in the contract

The payment trigger matters more than it looks. Most agencies tie the transfer to settled invoices, which is fair. Just read how it's worded, because a clause that says ownership passes on final payment leaves you owning nothing during the build itself.

Ownership that arrives only on final payment means you own nothing mid-project.

Moral rights are the other one people skip. In the UK, the author keeps a right to be identified and to object to derogatory treatment of their work even after copyright moves. A waiver clause handles it in one sentence, and it saves awkward conversations if you later rebrand or heavily rework what was built.

Ownership of Accounts, Not Just Code

On a social football product we worked on, the client registered the App Store Connect account in their own name and held the Account Holder role. They gave me admin access to most of the account, and we set up three testing groups, one for our team, one for the client, and one external QA beta group for the client's own testers. That structure let us control which build reached which group during deployment.

As launch got close, the client started going into the account directly and sending already-uploaded builds to whichever group they fancied. It caused problems. Because everything lived on their account, they had full access and we had very little ability to stop it. That's the correct way round for ownership, and it shows what ownership actually means in practice. Whoever holds the account holds the power.

Register the Apple Developer and Google Play accounts in your company name, with a company email address and a company payment card, before development starts. Add your agency as a user. Never the other way round.

The accounts worth holding yourself include the Apple Developer and App Store Connect account, the Google Play Console account, the code repository organisation, the analytics and crash reporting tools, the cloud hosting and database accounts, and the domain registrar and DNS.

• Apple Developer and App Store Connect
• Google Play Console
• Code repository organisation
• Cloud hosting, database and push notification services
• Analytics, crash reporting and error monitoring
• Domain registrar and DNS

Who Controls the App Store Listing and Why It Matters

Store review is where account ownership stops being an administrative detail. On the peer-to-peer currency exchange product we built, where travellers swapped leftover foreign currency with each other at interbank rates and skipped the commission, Apple took against the product. Each time the client resolved an objection and resubmitted, a new objection appeared. The client spent real money on legal counsel and compliance work, and the rejection criteria kept moving.

It was clear something else was going on and that Apple simply didn't want it on the store. There's no meaningful route to challenge that. A well-funded incumbent can keep a compliant competitor out of the market more or less indefinitely, and the developer has no referee to appeal to.

The ownership lesson sits underneath all of that. Whoever holds the developer account is the party in the conversation with Apple. They receive the rejection notices, they write the replies, they decide whether to argue or to change the product. If that's your agency rather than you, somebody outside your company is negotiating your route to market on your behalf, and you're reading about it second hand.

The listing itself carries the same weight. Screenshots, description, keywords, the support URL, the privacy answers and the age rating all shape how the product is found and judged. Those are marketing decisions sitting inside a technical account, and they should be yours.

Pre-Existing Code, Libraries and Third-Party Licences

No app is written entirely from scratch. Your product will sit on open source libraries, platform SDKs, payment providers, map services and whatever internal tooling your agency has built up over the years. An IP assignment transfers the new work. It cannot transfer things the agency never owned.

So the contract needs to separate the two. New work assigns to you. Pre-existing agency components come to you under a licence, and that licence should be perpetual, irrevocable and transferable, so it survives a change of agency and a sale of the business. Third-party and open source components stay under their own terms, and you need a list of what they are.

Open source licences vary more than people expect. Permissive ones let you do almost anything. Copyleft ones can oblige you to publish your own source code under the same terms if you distribute the software. That obligation attaches to the product you own, not to the agency that chose the library.

Prototype code and provenance

We saw a trading card platform client get much further with investors once he stopped relying on pitch decks and built a vibe-coded version he could demo. Having something concrete to show changed the conversations. When a prototype like that becomes the base of the funded build, it's worth a proper look at where the generated code came from and what it pulled in, before it's carrying real users and real money.

Hardware, APIs and Integration Contracts

On a baby monitor product we worked on, the client was building the physical hardware, the cameras and sensors, as well as the companion app. The plan had been to use off-the-shelf Bluetooth protocols. The real integration turned out to be far more involved than anyone expected.

We ended up formally defining the contract between the software and the hardware, specifying exactly how the app communicated with the device, covering turning things on and off, pulling sensor data and getting camera feeds, all in a format the app could actually use. That document is an asset in its own right. Anyone replacing either side of the product later needs it, and without it they're reverse-engineering a conversation between two devices.

The specification between app and hardware is an asset, and somebody needs to own it.

We also built a prototype that rendered a web server from the device itself, so we could connect to it, see the internals of what was happening, check that settings were being applied correctly, and drive the device from the app at the same time. Test rigs like that get written off as throwaway tooling. They're often the only way to debug the product in future.

Settle three questions in writing on any connected product. Who owns the firmware, who owns the interface specification, and who owns the test tooling built to prove it works.

Design Work, Research and Everything Before the Code

Design and research carry the same copyright rules as code, and they're left out of assignment clauses far more often. Wireframes, prototypes, component libraries, interview notes, personas, the reasoning behind each decision. All of it is created work with an author.

On a dating app we worked on, the client put heavy emphasis on onboarding, verification and validation. Discovery didn't extend to the messaging side, so messaging got built generically, and it allowed exactly the fake automated behaviour the onboarding had been designed to keep out. The two halves of the product contradicted each other.

That's the argument for owning research rather than just deliverables. The research explains why the verification worked the way it did, what the onboarding was defending against, and therefore what the rest of the product has to respect. Hand a new team the screens without the reasoning and they'll rebuild the same contradiction in a different place.

Ask for research outputs in editable, non-proprietary formats at each milestone rather than at the end. A PDF of a design system is a record. The source file is a working asset.

The fitness and wellness founders ended up with design and research as their entire deliverable after the budget ran dry. Painful as that was, those files had real value, and they only had value because they belonged to the client in a usable form.

Sign-Off, Approvals and the Paper Trail of Decisions

Ownership of a product includes ownership of the decisions that shaped it, and that only exists if somebody writes them down as they happen.

The fitness and wellness project showed what the absence looks like. We'd get sign-off on a design, start building, and then the founders walked the approval back, saying they hadn't understood that was what we were going to build. The two co-founders never reached a consensus between themselves, and approval seemed to be given out of politeness rather than as a genuine decision. We kept warning them that the budget was going on design iterations that made no material difference to the product. That advice fell on deaf ears, and the work finished at the design and research stage.

A written approval record fixes some of this. Not as a weapon, as a shared memory. It should say what was approved, who approved it, on what date and what it unlocks. One named decision-maker on the client side helps enormously, particularly where founders share a company equally.

The social football product had a related issue in the other direction. Builds went out to test groups without the structure being respected, so the record of which group received which build got muddled. When something behaves oddly in testing, that trail is how you work out what actually happened.

Compliance Obligations That Come With Ownership

Owning the app means owning its obligations. The regulator, the platform and the user all look at the company named in the listing, whoever wrote the code.

The currency exchange product made that concrete. We built the core transfer mechanism well, and what we hadn't factored in was anti-money laundering. Apple saw a product that allowed unlimited transfers between parties and treated it as a possible money laundering route. We went back and retrofitted several layers. More stringent know your customer checks, tighter transfer security, and hard limits on how many transfers any two parties could make between them.

Retrofitting compliance is slower and more expensive than designing for it, because the rules change the product rather than sitting on top of it. Limits on transfers altered the whole proposition.

The obligations that follow the owner

Data protection responsibility sits with the owner as data controller, which covers the privacy policy, lawful basis, retention and subject access requests. Accessibility duties attach to the owner. Platform policy compliance, age ratings and in-app purchase rules do too. So does whatever sector regulation applies to the category you're in, whether that's health claims in supplements or payments in hospitality.

Ask your developers what compliance work is in scope and what is out of it. An agency that lists what it isn't covering is telling you where your own homework starts.

What Happens When the Relationship Ends

Every engagement ends, in good order or otherwise. The sports club app ended in the second category. We'd warned the client early that the budget would get wildly out of control and that they risked running out of money before launching anything. The warnings were noted and the features kept coming. At the end of it the entire budget was gone, nothing was on the store, and the client and the agency parted ways.

Listening to the process and releasing incrementally is often the difference between launching and not launching.

What makes that ending survivable is the handover, and the handover is far easier when ownership was settled at the start. A sensible exit runs in order.

1. Transfer the Account Holder role on both store accounts to your company.
2. Move repository ownership to your organisation, with full history.
3. Hand over signing certificates, provisioning profiles and keystores.
4. Reassign hosting, database, domain and third-party service accounts.
5. Deliver design sources, research outputs and any interface specifications.
6. Write a short document covering architecture, dependencies and known issues.

Put that sequence in the contract as an offboarding obligation with a deadline attached. Signing keys deserve particular attention, because losing an iOS signing identity makes updating an existing listing painful in a way that surprises people.

Questions to Ask Before You Sign

These are worth working through in order with any agency, ours included. The answers tell you a lot about how a team operates, well beyond the legal detail.

1. Does the contract assign copyright in all new code, designs and research to us, in writing?
2. What pre-existing components of yours will be in the product, and on what licence terms?
3. Which open source libraries are you planning to use, and are any of them copyleft?
4. Whose name goes on the Apple and Google developer accounts?
5. Do subcontractors and freelancers assign their work to you, and does that flow through to us?
6. What exactly gets handed over at the end, in what formats, and within how many days?

Ask the handover question first rather than last. How a team describes the end of the relationship tells you how they'll behave during it.

One more question matters as much as the rest, and it's about fit rather than ownership. We worked on a football-focused social media app where the client wanted a streamlined MVP-style first release but had a budget that didn't match the premium experience they expected. They wanted the low budget without the limitations that come with it. Several conversations went into aligning expectations with the money available. We did reach a finished product, with compromises on features, because budget went to areas we'd have ranked lower.

Conclusion

App ownership with developers is less about a single clause than about a series of small decisions made early, when nobody is under pressure and everything feels straightforward. Who registers the store account. Whether design sources come back editable. Whether the hardware interface gets written down. Whether approvals are recorded as they happen. None of those feel urgent in week one, and all of them decide how much freedom you have in year two.

The projects we've described here lost value in different ways. A sports club app burned a full budget and published nothing. A fitness and wellness product never left the design stage because approvals kept moving. A currency exchange product got the mechanism right and had compliance bolted on afterwards at real cost. In each case the paperwork was a smaller factor than the working relationship, and good paperwork made the difficult moments much less damaging.

Get the ownership questions settled before the build starts, then spend your attention on the product itself. That's the right order, and it's the order we work in.

If you're about to commission a build and want a second opinion on what you'll end up owning, let's talk about your app build.

Frequently Asked Questions