You own the code. All of it. From the first commit. Intellectual property vests in the client upon creation — not upon final payment. If your contract says otherwise, the developer holds a pressure mechanism, not a policy. The fix is a single clause change before you sign, not after a dispute starts.
Most founders find out their contract is wrong when something breaks — a delayed delivery, a disputed invoice, a developer who goes quiet. By that point, who controls the code is already settled — and not in your favour.
Here is what the contract needs to say, and what it must never say.
What does "IP vests upon creation" actually mean?
It means every line of code belongs to you the moment it is written. Not when you pay the final invoice. Not when the project is delivered. When it is written.
The alternative — "IP transfers upon final payment" — is the clause that creates hostage situations. We have seen an 11-day platform freeze during a $14,000 invoice dispute. The developer stopped returning repo access until the invoice was cleared. The client's live users experienced 11 days of degraded functionality. The dispute itself was legitimate — there was a genuine disagreement about scope. The control came from the IP clause, which put the developer in charge of a live product the client thought they owned.
That clause costs you nothing to change before signing. It costs you everything to fix during a dispute.
What should the IP clause say?
The clause that works: "All intellectual property, including source code, documentation, designs, and derivative works, vests in the client upon creation and is hereby assigned to the client with no further act required."
The clause that doesn't: "IP transfers to the client upon receipt of final payment" — or any variant that ties ownership to a financial event rather than a creative one.
The difference is not semantic. One clause means you own your platform. The other means your platform is collateral.
Who should own the repo, and from when?
You. From day one. Before the first commit lands.
The common arrangement — "we'll transfer the repo at project handover" — is the repo equivalent of the bad IP clause. It means the developer controls access to your codebase throughout the engagement. You cannot verify what is being built. You cannot bring in a second developer to review the work. You cannot ship patches independently if the relationship breaks down.
The correct setup: repo lives under your organisation's GitHub (or equivalent) account. You are listed as admin. The developer is a contributor. That configuration never changes — not for the duration of the project, not until handover, not ever. You were always the owner.
We invite every client to their own repo before kickoff ends. Not during handover. Before the first commit.
What if the relationship ends early?
Every contract needs an exit clause. An exit clause has three components — all three, or it does not protect you:
- Immediate IP assignment for completed work. Whatever has been built at exit is assigned to you unconditionally, regardless of invoice status.
- Partial refund at milestone boundary. If you exit mid-milestone, you get a refund for the undelivered portion. The exact percentage should be defined in the contract, not negotiated at exit.
- Two-week handover window. The developer provides documented handover — code comments, architecture notes, environment variables, third-party credentials — within two weeks of exit notice. This window is capped and non-negotiable.
Without item one, the developer can claim the in-progress work during a dispute. Without item two, you pay for work that was never delivered. Without item three, you inherit a codebase with no map.
What if the developer refuses to include the IP clause?
Walk away.
A developer who refuses the "IP vests upon creation" clause is telling you exactly how disputes will go. The refusal is the information. A developer who is confident in their work, who expects to deliver what they promised, has no reason to retain IP as a pressure mechanism. That clause is only useful if they expect to need it against you.
This is not a negotiation about trust. It is a filter for which engagements are safe to enter.
The comparison: what you should have on day one
| Item | Correct | Wrong |
|---|---|---|
| IP clause | "Vests in client upon creation" | "Transfers upon final payment" |
| Repo ownership | Client org, client as admin | Developer account, transferred at handover |
| Repo access timing | Before first commit | "We'll give you access when it's done" |
| Exit IP | Assigned unconditionally for completed work | "TBD subject to invoice clearance" |
| Exit refund | Defined percentage at milestone boundary | No provision |
| Handover window | Two weeks, documented in contract | Verbal promise, no timeline |
What do we do by default?
IP assigns from the first commit. The assignment clause is in our standard contract and is not negotiable. The client's repo invite goes out before kickoff ends. The client is admin. We are contributors.
Exit terms are in every contract: IP assignment for completed work, partial refund at the milestone boundary, two-week handover window. These are not concessions we make when asked. They are defaults we include because we expect every engagement to end on the client's terms, not ours.
We cover the broader due-diligence questions — beyond just contracts — in questions to ask before hiring to build your MVP. The IP clause is the most consequential one, but it is not the only one.
The question worth asking before you sign
Ask the developer: "If we disagree on scope mid-project and stop paying, who controls the repo?"
The answer tells you everything. A developer who hesitates — or who says "well, it's complicated" — has designed the contract to leave that question open. It is not complicated. You own the repo. You are the admin. You always were.
If they can't say that clearly, the contract says something else.
Written 2026-07-03 by Naman Barkiya.