Who Owns App Code Built by a Freelance Developer?

This applies whether you hired through a freelance platform, a referral from a friend, a development agency, or directly as an independent contractor, or wrote the first version yourself before the company existed. The legal question is the same in every version.

You had an idea for an app. You couldn't code it yourself, so you hired a freelance developer to build it. Ten or twenty thousand dollars later, you had a working product sitting in a repository (the online folder where the code lives) under your account. You paid the invoice, you have the login credentials, and you have been running the business on that app ever since.

You probably assume the company owns it.

That assumption is the single most common intellectual property mistake I see founders make, and it usually stays invisible right up until an investor, a buyer, or a new development team asks you to prove it.

Quick answer: Paying a freelance developer to build your app does not automatically give your company ownership of the copyright in the code. Ownership generally requires either a work-for-hire arrangement that legally applies to software (which is rarer than people assume) or a signed assignment where the developer actually transfers the rights to you. Without one of those two things, you may only have a license to use the software, not clean ownership of it. Here's how to clean it up.

Skip to FAQ.

Paying the Invoice Is Not the Same as Owning the Copyright

Under copyright law, the person who creates a work owns it the moment it's created. That rule doesn't bend just because someone else paid for the work to happen.

Think about it the way you'd think about buying a painting. If you buy a painting at a gallery, you own that physical canvas. You can hang it, sell it, or put it in storage. You do not automatically own the artist's copyright, the right to reproduce the image, print it on merchandise, or license it to someone else. The canvas and the copyright are two different things.

Source code works the same way. Having the files, having repository access, and having paid the invoice all tell you that a transaction happened. None of them tell you which rights actually changed hands. Your company almost certainly owns things like your brand, your business model, your customer data, and your domain name. What's genuinely uncertain is whether it owns the copyright in the specific code, graphics, and documentation the developer personally wrote, and that uncertainty is exactly what an investor's lawyer will be checking for.

Employees and Contractors Are Not Treated the Same Way

If you have an actual employee write software as part of their job, the company generally owns it automatically as a "work made for hire," meaning the law treats the employer as the author.

A freelance developer is usually not an employee. Courts look past whatever label the contract uses and examine the real working relationship: who controlled how the work got done, whether the person used their own equipment, whether they worked for other clients at the same time, how they were paid, and similar factors. The typical freelance developer, working independently, using their own laptop, invoicing by project, and juggling other clients, is going to look like a contractor no matter what the contract calls them. That distinction matters because it determines which legal path you need to rely on to actually own the work.

None of this depends on where you found the person. A developer you found on a freelance platform, one a friend referred you to, one you hired through a small development agency, and one you brought on as a straightforward 1099 independent contractor are all almost certainly contractors, not employees, in the eyes of copyright law. The label on the invoice doesn't change the analysis.

Why "Work Made for Hire" Usually Doesn't Cover Custom Software

This is the part almost every online contract template gets wrong.

For an independent contractor's work to count as a "work made for hire" (the employer-style rule described above), two things both have to be true: the parties signed a written agreement saying so, and the work falls into one of nine specific categories the Copyright Act actually lists. Those categories include things like contributions to a collective work, parts of a film, translations, and instructional texts. Custom application code isn't on that list.

So a contract that just says "everything is work made for hire" can be legally hollow for the actual app itself. The fix is to have the agreement do two things at once: say the deliverables are intended to be a work made for hire where that's legally possible, and separately have the developer directly and immediately assign (hand over ownership of) whatever isn't covered by that first part. The assignment is what actually does the work. The work-for-hire language alone often can't carry it for software.

One more caution worth knowing, particularly if your company operates in Pennsylvania: an agreement that leans too hard on work-for-hire language, or that starts describing too much control over how and when the contractor does the work, can create a separate problem that has nothing to do with copyright. Pennsylvania actively enforces worker misclassification under several different tests, the Unemployment Compensation Law's two-condition test, the Minimum Wage Act's six-factor economic reality test, and the Workers' Compensation Act's right-to-control test, and the state ran a formal task force on this through 2022 that found real numbers of misclassified workers. A contract built to fix your copyright ownership problem shouldn't accidentally create an employee-misclassification problem instead. The two issues need to be handled with an eye on both at once.

An Implied License Is Real, But It Is Not Ownership

Even without a signed assignment, you're probably not committing copyright infringement just by running your own app. Courts have found that when a client asks for something, a developer builds it and hands it over, and both sides clearly intended the client to use it, the client gets an implied license, essentially an unwritten permission slip to keep using the software.

That protects you from the worst-case scenario. It does not give you ownership. A license is permission to use something someone else owns. Depending on what was actually said and done, the developer may still be free to reuse that code for another client, and your company may be in a genuinely gray area on things like modifying the app yourself, hiring someone else to build a new version, selling the software to your own customers, folding the code into a different product, transferring it if you sell the company, or suing a copycat for stealing it. None of that makes the app unusable tomorrow. It does mean you may have bought the right to operate an asset without buying the asset itself, which is a strange position to be in when that asset is most of your company's value.

Why This Surfaces During Fundraising

This problem is almost always invisible while the product just quietly works. It becomes visible the moment someone outside the company asks you to prove you own it.

A serious investor or acquirer will typically ask for your founder IP assignments, your contractor agreements, a list of any open-source pieces in the app, proof you control your domains and repositories, and confirmation that anyone who touched the code, including subcontractors you may not have even known about, signed something transferring their rights. That last one trips people up constantly: you hired an agency, the agency hired individual programmers, and those programmers never signed anything with the agency. The agency can't hand you rights it never actually had.

When that gap shows up mid-raise, the outcomes range from mildly annoying to genuinely deal-threatening: a delayed closing while everyone scrambles for signatures, an investor demanding a cleanup assignment before wiring money, a lower valuation, an escrow set aside to cover the risk, a developer who senses leverage and asks for more money to sign now, or, in the worst cases, a developer who can't be found or won't respond at all.

If You Hired Through Upwork or Fiverr: Does the Platform Solve This?

Not automatically, but it's closer to solved than people assume, and the details matter.

Upwork's standard optional contract terms say that once the freelancer is paid in full, the work product becomes the client's property, with an automatic fallback that assigns anything not already covered. Fiverr's terms work similarly: intellectual property generally transfers to the buyer once the work is delivered and paid for. Both platforms carve out an exception for what's sometimes called "background technology," meaning code, libraries, or tools the developer already owned or reused rather than built fresh for you.

So the platform's default terms may already be doing a lot of the work you'd otherwise need a contract for. The questions worth actually answering before you assume you're covered: Did you pay in full, or is there an outstanding milestone? Did the developer flag anything as their own pre-existing technology? Did you and the developer agree to different terms than the platform default, or move the relationship off-platform later, where those defaults may no longer apply? Was the person who actually wrote the code a subcontractor the platform never had a direct relationship with? And do you still have records of the actual terms that were in effect at the time, since platforms do update these terms over time. The lesson isn't that Upwork or Fiverr leaves you exposed. It's that the platform name alone doesn't answer the question, you still have to check the specifics.

If You Hired Directly, Through a Referral, or Through an Agency

This is actually the higher-risk version, and it's the more common one. A lot of founders don't hire through a marketplace at all. They hire a developer a friend recommended, someone they found on LinkedIn, or a small agency or dev shop, and everything gets handled through a simple contract, a handshake, or a string of emails.

None of Upwork's or Fiverr's default assignment language applies here. There is no marketplace terms of service quietly transferring ownership to you in the background. Whatever you and the developer actually signed, or didn't sign, is the entire ballgame. If that was a one-page template, a verbal understanding, or a project description in an email thread, you likely have exactly the gap this article describes, with nothing behind it. If you went through an agency, the same subcontractor problem shows up again: the agency's contract with you doesn't create rights the agency never actually obtained from the individual programmer who wrote the code. This is generally the scenario where a real written assignment matters most, precisely because there's no platform default there to catch you if the contract is thin.

What If You Wrote the First Version Yourself?

This is the version of the problem founders are least likely to see coming, because there's no invoice, no contractor, and no one to point to. You coded the first prototype yourself, nights and weekends, before the company was even incorporated. Then you formed an LLC or a C-corp, and the code just moved into the business along with everything else, or so it felt at the time.

Legally, it didn't move anywhere on its own. You, as an individual, owned the copyright in whatever you personally wrote before the company existed, the same way a contractor would have. Incorporating a company doesn't automatically transfer your personal pre-existing work into that company's ownership. It has to be assigned, in writing, from you to the entity, the same assignment you'd want from any outside developer. Founders skip this constantly, partly because it feels strange to "assign" something to yourself, and partly because nobody's invoice ever prompts the question the way a contractor relationship does.

This gets caught the same place everything else in this article gets caught: diligence. An investor's counsel asking for founder IP assignments isn't just asking about the developer you hired last year. They're asking whether you, personally, ever signed over the code you wrote before the company was a company. If you never did, the fix is simple and should happen as early as possible, ideally as part of formation itself: a founder IP assignment agreement, executed at incorporation, covering everything you built before the entity existed.

The Code Nobody at Your Company Wrote: Open Source and Reused Code

Even a perfectly written assignment can't give you ownership of something the developer never owned in the first place. Developers routinely build on open-source libraries, reusable code modules, stock design assets, and pieces borrowed or adapted from other projects.

A good agreement separates what the developer actually created fresh for you from what they brought in from elsewhere, and gives you a broad enough license to that outside material that you're not stuck dependent on the original developer to keep operating your own product. For anything genuinely open source, the agreement should require the developer to disclose it and flag anything with license terms that could conflict with you running the app as a proprietary, closed product. This is why "the company owns everything" is never quite the right sentence for a development agreement. Ownership, licensing, and disclosure are three separate jobs, and all three need to happen.

What a Good Development Agreement Actually Needs

A solid agreement generally does four things well.

First, it clearly describes what's being built and then immediately assigns the copyright in it to you, in writing, rather than resting on work-for-hire language alone. That assignment should cover source code, documentation, designs, and anything else the developer creates, including unfinished or partial work if the relationship ends early.

Second, it separates the developer's own pre-existing technology from what's new, and gives you a license broad enough to keep operating and modifying the product without the original developer's continued involvement.

Third, it handles the open-source and third-party question directly: disclosure requirements, and a check on anything with licensing terms that could interfere with your business model.

Fourth, it covers the practical mechanics that founders forget until they need them: a requirement that any subcontractors sign the same kind of assignment, delivery of full repository and account access, a promise that the developer will sign anything further needed later if a gap turns up, and what happens if the developer simply doesn't deliver.

If the App Is Already Built, Here's How to Clean It Up

If you're reading this because the app already exists and you're not sure what you actually have, this is fixable, and it's usually easier to fix now than during a live deal.

1. Make a list of everyone who touched the code, design, or documentation, including anyone your original developer subcontracted, and including yourself if you wrote any of the original version.

2. Pull together everything you have: signed agreements, emails, platform terms of service, invoices, and payment records.

3. Check whether anything you already have actually counts as a written assignment, as opposed to just an invoice or a friendly email.

4. Identify anything in the app that's open source or borrowed from elsewhere.

5. Confirm your company, not an individual, controls the repository, hosting, domain, app store accounts, and admin credentials.

6. Go back to anyone whose rights are unclear, including yourself if you coded any of it pre-incorporation, and get a confirmatory assignment signed now, while the relationship is still good.

7. Get a license for anything you can't or shouldn't own outright, like third-party or open-source components.

8. Keep all of it organized somewhere you can hand it over quickly the next time someone asks.

A signed assignment executed after the fact still works, but your company is exposed until it's actually signed. The cleanup conversation is almost always easier before a deal is on the table than during one.

Frequently Asked Questions

Does paying my developer mean I own the code? Not automatically. Ownership generally requires either a work-for-hire agreement that legally applies to the type of work, or a separate signed assignment of the copyright. Payment alone establishes that a service was purchased, not which rights transferred.

Is app development legally "work made for hire"? Usually not on its own. Custom software doesn't fall into any of the nine categories the Copyright Act allows for contractor work-for-hire agreements, so most development contracts need a direct assignment as a backup, not just work-for-hire language.

What's the difference between an implied license and owning the code? A license is permission to use something someone else owns. It can protect you from an infringement claim for running your own app, but it may leave the developer free to reuse the code elsewhere and can leave you uncertain about your right to modify, resell, or transfer the software.

Do Upwork and Fiverr automatically transfer ownership to me? Generally yes, once you've paid in full, subject to some exceptions for the developer's pre-existing technology and whatever specific terms applied to your project. The platform's involvement doesn't remove the need to check the specifics of your situation.

Does it matter if I hired my developer directly instead of through a platform? It matters more, not less. Platforms like Upwork and Fiverr have default terms that transfer ownership to you in the background even if your own contract is thin. Hire someone directly, through a referral, or through an agency, and there's no platform default behind you. Your written agreement is doing all of the work, which makes having a real assignment even more important, not less.

What if I wrote the code myself before the company existed? The same rule applies to you as to any outside developer. Code you personally wrote before incorporating belongs to you as an individual until you assign it to the company in writing. This is one of the most commonly missed assignments because there's no invoice or contractor relationship to prompt the question, and it's exactly what an investor's diligence checklist is looking for when it asks for founder IP assignments.

What should I do if I already built my app without a proper agreement? Gather your existing records, identify everyone who contributed code, including yourself if applicable, confirm you control your accounts and repositories, and go back for confirmatory signed assignments on anything unclear. This is almost always solvable, and easier before an investor or buyer is asking about it.

If your company is preparing to raise money, bring on a new developer, or simply isn't sure what it actually owns, this is exactly the kind of gap a fractional general counsel arrangement is built to catch before it becomes a deal problem. I help founders review existing development agreements, draft new ones, clean up missing assignments before diligence starts, and sort out open-source exposure.

Make an appointment online.

This is general information, not legal advice. Every company, every agreement, and every fact pattern is different, and nothing here creates an attorney-client relationship.