--- title: What IP Rights Do Freelance Developers Keep From Your App? description: Under UK law, freelance developer intellectual property stays with the developer by default. Find out what you own and how to secure full assignment. image: https://weareaffective.com/hubfs/learning-centre-images/what-ip-rights-do-freelance-developers-keep-from-your-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-ip-rights-do-freelance-developers-keep-from-your-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What IP Rights Do Freelance Developers Keep From Your App? Table of Contents Pay a freelance developer to build your app and you own the app. That's the assumption almost every founder starts with, and under UK law it's wrong. Freelance developer intellectual property belongs to the freelancer by default, because copyright sits with the person who made the thing unless a signed agreement moves it. You've paid for the work. You haven't automatically bought the rights to it. > A contract that says nothing about ownership has already decided, and it hasn't decided in your favour. The gap stays invisible while everyone's getting along. It shows up later, when you want to move to a new developer, when an investor's lawyer asks for a list of what you own, or when someone offers to buy the business. Then a contract gets read properly and what looked like ownership turns out to be a licence. So this piece walks through what a freelancer keeps, what you can fairly ask them to hand over, and the parts of a product nobody thinks about until they're missing. Code is the obvious piece. Designs, brand names, recordings, store accounts, repositories and third party licences each carry their own rules, and we've watched every one of those cause a real problem on a real project. ## Who Owns the Code by Default Copyright in software starts with the author. Someone writes a function, and from that moment they hold the copyright in it. No registration, no paperwork, no fee. That's the starting position in the UK and in most places you're likely to hire from. #### Why freelance developer intellectual property sits with the freelancer A freelancer isn't your employee. They're running their own business and selling you a service, so the rule that hands an employer the copyright in work made during employment doesn't reach them. What you usually get instead is an implied licence to use what they built for the purpose you commissioned it for. That licence is often enough to run the app. It's rarely enough to sell the company, sublicense the code, or hand the whole thing to a different team and ask them to rewrite half of it. Ownership fights are expensive in a way that makes the paperwork look cheap. Mark Zuckerberg settled with the Winklevoss brothers over ownership of Facebook for $65 million, according to [SVB](https://www.svb.com/startup-insights/startup-strategy/protecting-intellectual-property-startups/). Most disputes are far smaller and still cost more than a lawyer reading a contract before anyone writes a line of code. ## Employees, Contractors and Agencies Compared The arrangement you choose changes the default, and the default is what applies when nobody writes anything down. It's worth seeing the three side by side. | Arrangement | Who owns the code by default | What you need in writing | | --- | --- | --- | | Employee | You, if the work was done as part of their job | A clear job scope, plus terms covering side projects | | Freelance contractor | The freelancer | A signed assignment of all IP, with moral rights waived | | Agency | The agency | Assignment on final payment, plus named third party licences | | Sub-contracted developer | The sub-contractor, not the agency | A matching assignment up the chain to you | That last row catches people out. An agency can only assign what it holds, so if its own freelancers never signed anything, the chain breaks before it reaches you. We worked on a [football-focused social media app](https://weareaffective.com/learning-centre/what-features-must-your-social-media-app-include-to-succeed) where the client wanted a streamlined first release but had a budget that didn't match the premium experience they expected. A lower budget means less flexibility and a sharper focus on getting something launchable, and that trade-off has to be said out loud. Contract terms work the same way. The cheapest engagement is the one where nobody pays for an hour of legal review, and that hour is the one you'll wish you'd bought. ## The design layer your *developers* need We deliver complete UX/UI design and technical specifications your development team can build from immediately. No guesswork, no back and forth, no mid-project surprises. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Assets Beyond Code: Designs, Brand and Content Code is only part of what makes a product. Figma files, icon sets, illustration, motion, copy, photography, audio and the name on the store listing all carry separate copyright, and they're often made by different people. A designer who worked on your onboarding screens holds rights in those screens whether or not your developer signed anything. Recordings and other media bring licensing on top of ownership. We worked on a music app where the client came from the music world and knew exactly what the recordings had cost them to produce. They wanted to recoup that cost within weeks, which isn't how consumer app economics work, and the cost-of-production anchor stopped them considering a lower price or a longer volume play. The rights question sat underneath all of it, because what you can charge for content depends on what you're actually allowed to do with it. > Separate rights live in the name, the illustration and the audio, and they're usually held by different people. Make a list of every asset in the product and write a name next to each one. The gaps on that list are the work you thought you'd bought. ## Trademark Clearance Before You Build the Brand A client came to us with a brand name they loved, a play on words for what the product did. We ran initial searches, found no conflicting brands, and started designing and building. Then we discovered a registered trademark for it, an obscure one, but registered all the same. We advised them to change the name, and they went with something slightly different that kept the play on words without exposing them to legal recourse. Changing a name mid-project is disruptive and it's still the cheap option. A letter from someone else's solicitor after launch costs you the name, the store listing, the domain, the app icon and whatever reputation the name had built. Clear the name before any pixel of brand work starts, and have a proper search done in every class and territory you plan to trade in, not just a quick look at the register. Registration is worth doing once the name is clear. A trademark registration runs for an initial 10-year term and can be renewed indefinitely after that, according to [Rapacke Law](https://arapackelaw.com/trademarks/trademarks-for-mobile-apps/), so the protection outlasts most of the code you're currently writing. ## Third-Party Libraries, Open Source and Licence Conditions No app is written from scratch. Your developer pulls in packages for networking, image handling, charts, analytics and payments, and each one arrives with a licence. Most are permissive and want nothing more than an attribution line. Some are copyleft, which can oblige you to publish your own source code if you distribute software built on them. A freelancer can't assign you rights in any of it, because those rights were never theirs. Developers do pay attention to this. 63% of developers surveyed by [Veracode](https://beta.darkreading.com/application-security/79-of-third-party-libraries-in-apps-are-never-updated) said they always look at licensing when evaluating a new third-party library. That's self-reported and it still leaves a sizeable share who don't, which is reason enough to ask for the list rather than assume. What you want from any engagement is a written record of every dependency, its licence, and its version. Ask for it as a deliverable, the same way you'd ask for a build. It takes a developer minutes to generate and it saves a specialist days of untangling during due diligence. ## Who Holds the Accounts: App Store, Repositories and Infrastructure Ownership of the code means little if someone else holds the account the code gets published from. On a social football product we worked on, the client held the App Store Connect Account Holder role because the account was registered in their name. We were given admin access to most of the account and set up three internal testing groups, one for our team, one for the client, and one external QA beta group for their testers. That structure let us control which builds went where during deployment. As launch got closer, the client started bypassing it, sending uploaded builds to whichever group they fancied. That caused problems, and because everything sat on their account we had limited ability to stop it. The account holder decides, which is exactly why the account holder should be you. Register the App Store, Play Console, cloud, domain and repository accounts in your company name with your own billing details, then invite the developer in. Doing it the other way round means asking for your product back later. Repositories deserve the same care. The organisation should belong to you, with the developer added as a member, so that the history, the branches and the issue log stay where they belong when the engagement ends. ## What a Developer Can Reasonably Keep None of this means a freelancer should sign away everything they know. General skill and experience travel with a person, and no sensible contract tries to stop that. A developer who learns a better way to [handle offline sync on your project](https://weareaffective.com/learning-centre/how-to-decide-what-belongs-offline-what-belongs-online-and-what-belongs-in-a-que) takes that understanding to the next one, and so they should. Patterns of craft belong in the same bucket. Asking a user for permission before you request notification access is a framing and tone of voice change rather than a technical one, and it produces far better responses because people feel they have control. That's not an asset anyone owns. It's judgement, and it's the reason you hired someone. > General skill travels with the person, and your specific product travels with you. Three things a developer can fairly hold on to, and which you can agree to without weakening your position. - Pre-existing tools and internal libraries they bring with them, licensed to you for use in the product - The right to describe the work in a portfolio, within whatever confidentiality you agree - Generic utilities with no connection to your business logic or data Everything written specifically for your product, and anything that embodies your business rules, branding or user data, goes to you. ## Assignment Clauses That Actually Transfer Ownership A clause that says the client "will own all intellectual property" does less than it sounds like it does. UK copyright assignment has to be in writing and signed by the person giving it up, and it has to be a present assignment rather than a promise to assign at some future point. Promises need enforcing. Present assignments just work. What a usable clause contains. - A present-tense assignment of all existing and future rights in the work - A waiver of moral rights, so nobody can object to how the work is later changed - A licence back for any pre-existing material the developer brings in, wide enough to cover resale of the business - An obligation to get matching assignments from any sub-contractor - A duty to sign anything further needed to perfect the transfer, including after the project ends Payment conditions are worth thinking through. Tying the assignment to final payment is fair to both sides, and it also means an unpaid invoice leaves you holding a product you don't own. Settle invoices properly and get the signed confirmation that rights have passed. Ask for a short IP schedule at project close that lists what was assigned, what was licensed and by whom. It's one page and it answers every question due diligence will ask. ## When Discovery Decisions Change What You Own Rights paperwork protects what exists. Discovery decides what gets built in the first place, and that shapes the asset far more than any clause. On a dating app project built around verified profiles and keeping bots out, the client chose to skip discovery on the messaging side and focus purely on onboarding. What got built was a generic messaging feature that allowed automated and fake messages, which contradicted the entire premise of the product and undid the verification work. The whole messaging section had to be rewritten, at roughly £15,000 of additional [budget and two months of extra time](https://weareaffective.com/learning-centre/how-to-structure-a-pre-build-budget-that-accounts-for-the-cost-of-being-wrong). You owned the first version. It just wasn't worth owning. The other direction is more cheering. WAA worked with a property developer building a concierge app for high-rise buildings who arrived with a suggested budget and a formed idea, looking for validation rather than scoping. We convinced them to run a proper discovery phase with focus groups and user workshops. What we found was that the product needed to be far simpler than they'd imagined, so a lot of planned features came out and the focus moved to creating a human connection with the product rather than replacing systems already in the building. Better product, lower cost, and less code to own. ## Compliance Obligations That Travel With the Product Owning the product means owning its obligations too, and those don't stay behind with the developer who built it. We built a [peer-to-peer currency exchange product](https://weareaffective.com/learning-centre/what-makes-peer-to-peer-payment-apps-different-in-price) where travellers could swap leftover foreign currency with each other at interbank rates and avoid commission. The core transfer mechanism worked well. What we hadn't factored in was anti-money laundering, and Apple flagged the product as a possible vehicle for laundering because transfers were unlimited. We went back and retrofitted several layers, more stringent know your customer checks, tighter transfer security, and hard caps on how many transfers any two parties could make between them. Retrofitting [compliance costs more than designing for it](https://weareaffective.com/learning-centre/why-80-percent-of-business-apps-fail-and-how-to-be-in-the-20-percent), and the obligation sits with whoever owns the product afterwards. Among app developers whose apps didn't fully align to certain security and privacy elements, 48% said they had a plan over the next 12 months to meet minimum security and data protection requirements, per [Pye Tait Consulting, 2023](https://www.gov.uk/government/publications/app-store-security-and-privacy-app-developer-survey/app-developer-survey), which is self-reported intent rather than finished work. Write compliance into the brief and into the contract, with a named party responsible for each requirement. The alternative is discovering it at review, which is the most expensive place to find anything. ## Recovering Rights After the Work Is Done Sometimes the paperwork wasn't done and the relationship has already ended. There's still a path, and it's narrower than the one you had at the start. > Getting rights back after the fact depends on goodwill you no longer control, which is why you buy it upfront. On a well-funded sports club app, built to manage finances, games, schedules and players across different sports, the client rejected [an incremental release from the outset](https://weareaffective.com/learning-centre/how-to-build-an-incremental-release-plan-a-founder-will-actually-agree-to). We advised launching with a single sport on a single platform as an MVP. They wanted everything, all at once, and refused to go to market until the full thing was done. We warned early that the budget would run out before anything shipped. That's what happened. The [entire budget went on feature after feature](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), nothing reached the store, and the two sides parted ways. An unlaunched product is still an asset, and ownership of it matters most in exactly that situation. If you're in this position now, work in this order. 1. Gather every signed document, purchase order, email and statement of work that touches ownership 2. Work out what the implied licence actually covers, since it covers more than people fear 3. Offer a clean, paid retrospective assignment while relations are still civil 4. Rewrite the disputed components if the developer won't sign, and document the rewrite ## What to Ask Before You Sign The questions below take about ten minutes with a developer or an agency, and the answers tell you most of what you need to know about ip rights for freelance developers on your project. 1. Who owns the copyright in the code when the final invoice is paid, and does the contract assign it in the present tense? 2. Are moral rights waived, so the work can be changed later without objection? 3. Which sub-contractors will touch the project, and have they each signed matching assignments? 4. What pre-existing libraries of yours go into the build, and what licence do I get for them? 5. Can I have the full dependency list with licence types before we start? 6. Whose name holds the App Store, Play Console, repository, domain and cloud accounts? 7. What happens to all of this if we stop work halfway through? A developer who answers these easily has done it before. One who gets uncomfortable at question three is telling you something useful about how the rest of the engagement will go. Everything WAA produces is delivered under the WAA name, and the ownership terms are written into the engagement rather than negotiated at the end. It's a plainer conversation to have on day one than on the day you want to leave. ## Conclusion The default rule is simple enough to remember. Whoever writes it owns it, until a signed document says otherwise. Everything else follows from that, including the designs, the name, the recordings, the dependencies and the accounts the product gets published from. What we keep seeing is that the ownership problem and the product problem are the same problem wearing different clothes. The dating app rewrite cost £15,000 because discovery got skipped on messaging. The sports club app ended with a spent budget and nothing on the store because an iterative release was refused. The concierge app came out cheaper and better because the client agreed to focus groups and workshops first. In each case the paperwork mattered, and what mattered more was whether the thing being owned was worth owning. So do both. Get the assignment signed, hold your own accounts, keep the dependency list current, clear the name before the branding starts. Then spend your attention on [building something that earns the protection](https://weareaffective.com/app-planning-strategy). If you're about to hire a freelancer or an agency and you'd like a second pair of eyes on how the rights are set up, [let's talk about who owns your app](https://weareaffective.com/get-started). ## Frequently Asked Questions If I pay a freelancer to build my app, don't I automatically own it? No. Under UK law, copyright sits with the person who created the work, so a freelancer keeps ownership unless a signed agreement transfers it to you. Paying an invoice buys you the work, not the rights to it. What do I actually get if my contract says nothing about IP ownership? You usually get an implied licence to use the software for the purpose you commissioned it for. That is often enough to run the app day to day, but not enough to sell the business, sublicense the code, or hand everything to a new team for a rewrite. How is this different from hiring an employee? Where an employee creates work as part of their job, the employer owns the copyright by default. A freelancer is running their own business and selling you a service, so that rule does not apply and you need a written assignment instead. What should the contract actually say? You want a signed assignment of all intellectual property to you, with moral rights waived, rather than a licence. It is common to tie the assignment to final payment, and to name any third party licences the build depends on. I hired an agency rather than a freelancer. Am I safe? Not necessarily. An agency can only assign rights it actually holds, so if the agency used sub-contractors who never signed anything, the chain of ownership breaks before it reaches you. Ask the agency to confirm that matching assignments exist all the way up the chain. Beyond the code, what else should I be asking for? Designs, brand names, audio or video recordings, app store accounts, code repositories and third party licences all carry their own rules and are routinely forgotten. Each one can become a blocker later, so list them explicitly rather than assuming the code assignment covers everything. When does this problem usually surface? Almost never while the relationship is going well. It tends to appear when you want to switch developers, when an investor's lawyer asks for a schedule of what you own, or when someone makes an offer to buy the business and reads the contracts properly. We've already built the app without an IP clause. What now? Go back to the freelancer and ask them to sign a retrospective assignment, ideally before any relationship cools or they lose interest in helping. Sorting it early costs far less than a dispute, and it is much harder to negotiate once a sale or funding round is on the table. ## Related Articles [![App Store fees: Are they killing innovation in mobile?](https://weareaffective.com/hubfs/learning-centre-images/app-store-fees-are-they-killing-innovation-in-mobile.webp)](https://weareaffective.com/learning-centre/app-store-fees-are-they-killing-innovation-in-mobile) ### [App Store fees: Are they killing innovation in mobile?](https://weareaffective.com/learning-centre/app-store-fees-are-they-killing-innovation-in-mobile) App stores generate over £200 billion in annual revenue, yet a growing chorus of developers... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Game Engine Should Beginners Use for Mobile Games?](https://weareaffective.com/hubfs/learning-centre-images/what-game-engine-should-beginners-use-for-mobile-games.webp)](https://weareaffective.com/learning-centre/what-game-engine-should-beginners-use-for-mobile-games) ### [What Game Engine Should Beginners Use for Mobile Games?](https://weareaffective.com/learning-centre/what-game-engine-should-beginners-use-for-mobile-games) Most people who decide to build a mobile game spend the first few hours doing the same thing:... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Drives First Impression Bias in App Store Discovery?](https://weareaffective.com/hubfs/learning-centre-images/what-drives-first-impression-bias-in-app-store-discovery.webp)](https://weareaffective.com/learning-centre/what-drives-first-impression-bias-in-app-store-discovery) ### [What Drives First Impression Bias in App Store Discovery?](https://weareaffective.com/learning-centre/what-drives-first-impression-bias-in-app-store-discovery) Most users make their minds up about an app before they ever open it. The decision to download, or... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.