Amine
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
5+ years software engineer
Do not assume you own the code because you paid for it. In the United States and many other jurisdictions, when you hire an independent contractor, freelancer, or agency, the creator generally retains copyright in what they produce unless a written agreement transfers it — and commissioned software often does not qualify as a "work made for hire" on its own, so that phrase alone doesn't save you.
This is the cheapest problem in software to prevent and one of the most expensive to discover late. It usually surfaces during a funding round or an acquisition, when a lawyer asks for your IP chain and finds a gap. This is part of how to hire a developer for your MVP.
I build software, not law. Everything here is delivery practice — what I hand clients and what I'd insist on as a buyer. Have a lawyer draft the actual agreement, especially if you plan to raise money.
The wording matters. You want the developer hereby assigns all rights, title, and interest — not "will assign" or "agrees to assign." A future promise is a promise you may need to chase someone to honour, possibly years later, possibly after a falling out.
Assignment should explicitly cover: source code, documentation, UI/UX designs, databases and schemas, APIs, architecture, test code, specifications, and any logos or trademarks produced under the engagement.
Include a work-made-for-hire clause where it legally applies, and then immediately follow it with an assignment clause stating that anything which isn't legally a work made for hire is assigned instead. Belt and suspenders. This is standard practice precisely because the work-for-hire category is narrower than most people assume.
Developers reuse things. I have utilities and patterns I bring to every project, and so does anyone with experience — that's part of why hiring an experienced developer is faster.
The agreement should say the developer keeps ownership of their pre-existing tools, discloses which ones are included, and grants you a perpetual licence to use them as incorporated into your product. That's the fair version. What you don't want is a developer's private library sitting at the centre of your product with no licence at all.
Require the developer to identify open-source components, comply with their licences, and avoid any licence that could require you to publish your own code — unless you've explicitly approved it.
This is not paranoia. Copyleft licences buried in a dependency tree are a real and recurring diligence problem, and it's much easier to ask at the start than to unpick later.
The IP should be assigned to your company, not to you personally. Investors expect the company to own the technology. If you haven't incorporated yet, this is a reason to do so before the build starts, or to make sure the agreement anticipates the assignment moving to the entity.
Be alert to:
"Client receives a perpetual licence to use the software."
That is a licence, not ownership. It might be acceptable for a piece of tooling. It is not acceptable for the product your company is.
Here's the practical part, and it's the part I'd care about most as a buyer:
Create every account under your company from day one, and give the developer access. Not the other way around.
The difference this makes is enormous. If a relationship ends badly and everything is already in your name, it's an access revocation — an afternoon of admin. If it's in the developer's name, it's a negotiation, and possibly a legal one, conducted with someone who has no incentive to hurry.
Any reasonable developer will agree to this immediately. Someone who insists on owning your repository or your cloud account is telling you how the relationship ends.
If you hire an agency rather than an individual, the agency can only assign rights it actually holds. Confirm that:
Otherwise a subcontractor you've never met can later claim ownership of part of your product. This is rare, but it's exactly the kind of thing that surfaces in diligence.
Ownership on paper is worth much less than possession in practice. Confirm you've actually received:
Commit history matters more than founders expect: it's the record of who wrote what and when, and it's the first thing a technical diligence process asks for.
The handover checklist is the full version of this, including how to verify each item without being able to read code.
Some agreements transfer ownership on full payment; others assign immediately. Both are workable as long as it's stated clearly.
If ownership transfers on final payment, understand the implication: until you pay, you may not own what's been built. That's a reasonable position for a developer to take, and it's a reason to keep milestones small — so the amount of unowned work in flight at any moment is bounded.
Almost nothing, at the start. A properly drafted development agreement is a few hours of a lawyer's time. Creating accounts in your company's name is free and takes an afternoon.
The alternative is discovering during a funding round that you have a licence rather than ownership, or that a contractor from eighteen months ago has never signed anything. Both are fixable — by tracking down that person and asking them to sign, at a moment when they know exactly how much leverage they have.
Sort it before the first payment. It's never cheaper than it is right now.
If you want a straight answer on what you should be receiving from a current build — or a review of what's actually in your repo — get in touch.
Four different products, not four prices for the same thing. What each option is actually good at, how each one fails, what an agency's overhead buys you, and where offshore genuinely fits.
Sixteen items, and how to verify each one without being able to read code. The test that proves a handover is real — and why commit history matters more than founders expect.
Shortlisting, comparing proposals, spotting the agency that sells with seniors and delivers with juniors, and getting ownership in writing — the full hiring process, written from the side that receives the brief.