When you pay someone to build custom software, you might assume the code is yours the moment the invoice clears. It usually isn’t, not automatically, and not the way most people imagine. Ownership is something you have to write down, and a “clean handoff” means more than getting a zip file at the end.
What “owning the code” actually means
There are a few separate things people lump together when they say they own their software, and it helps to keep them apart.
The first is the copyright to the source code itself. Under US law, when you hire an independent contractor or an agency, the default is that the developer owns the copyright to what they write, not you, even though you paid for it. The “work made for hire” doctrine that people cite mostly applies to actual employees. For contractors, a few narrow categories can qualify as work for hire, but custom application code generally isn’t one of them. So if your contract is silent, you may have paid for a thing you don’t legally own. You’d have a license to use it, maybe, but not the right to modify it freely, hand it to another developer, or stop the original builder from reusing it.
The second is the underlying ideas and IP: any patentable methods, trade secrets, or distinctive designs. These need their own assignment language.
The third, and the one people forget, is practical control: do you have the accounts, the credentials, the deployment pipeline, and the knowledge to actually run and change the software without the original builder in the room? You can own every line of code on paper and still be stuck if the only person who can deploy it is someone you no longer work with.
What to put in the contract
You don’t need a 40-page agreement, but a few clauses do real work.
An IP assignment. Look for language that says all work product, including source code, is assigned to you on payment, not merely licensed. The phrase “assigns all right, title, and interest” is what you want. Tie it to payment so the developer is protected too: ownership transfers as you pay, which is fair to both sides.
A definition of deliverables. Spell out that deliverables include source code, configuration, database schemas, infrastructure-as-code, build scripts, and documentation, not just a running application. “We’ll deliver the app” is ambiguous. “We’ll deliver the full source repository and everything needed to build and deploy it” is not.
Carve-outs for pre-existing and third-party material. Honest builders reuse their own libraries and standard open-source packages. You can’t own those, and you don’t want to. A reasonable contract lists what the developer brings in and grants you a perpetual, transferable license to use it inside your project. Be wary of the opposite: a builder who claims to assign everything but is quietly building on a proprietary framework only they can license.
Confidentiality, both directions. Your data and business logic stay yours.
We go into more depth on scoping and contracts on our custom software development page, but the short version is that ownership language belongs in the agreement before work starts, not in a scramble at the end.
What a clean source handoff looks like
A real handoff is something you can verify, not a promise. When we finish a project, the test is simple: a competent developer who has never seen the code should be able to take what we hand over and run, build, and deploy it without calling us. That means:
- The complete Git repository, with its full history, in your own account, not a folder of files with the history stripped out.
- A README that explains how to set up a development environment, run the tests, and deploy, with the actual commands.
- Environment configuration documented, with a list of every secret and external service the app depends on.
- All accounts and credentials in your name: domain, hosting, third-party APIs, app store listings. If something must start in the builder’s account, there should be a written plan to transfer it.
- A short architecture overview so the next person understands the shape of the system before they touch it.
The Git history matters more than it sounds. It’s the record of why decisions were made. Handing over code with the history flattened into a single commit is a quiet way to keep you dependent on the people who remember the reasoning.
Red flags to watch for
A few patterns reliably signal trouble:
- The contract only grants a license. If you can use the software but can’t modify it or move it to another developer, you don’t own it, you’re renting it.
- The app is locked to a platform only the builder controls. Some “custom” builds are really configurations of a low-code platform with monthly fees and no export path. When the relationship ends, so does your access. This is exactly the trap we try to help people avoid; we build software you can run yourself, which is part of why we care about local-first approaches where it fits.
- No source code in the deliverables. If you’re only promised a running service and not the code behind it, ask why.
- Vague “we own our tools and methods” language with no carve-out for your project. Read it carefully; it can swallow the work you paid for.
- Resistance to putting credentials in your name. Owning your domain, your hosting account, and your data is non-negotiable.
An honest tradeoff
Full ownership and a clean handoff cost a little more up front. Writing real documentation, transferring accounts properly, and keeping the build reproducible takes time, and time is billable. The payoff is that you’re never trapped: you can hire anyone to maintain the software, or bring it in-house, or walk away from us and take everything with you. We think that’s the right deal, and we’d rather earn repeat work by being good than by being the only ones who hold the keys.
If you’re about to commission custom software and want to make sure the ownership terms are right before you sign anything, get in touch and we’ll walk through it with you.