IP Assignment at Every Milestone: You Own What You Pay For

The engagement ends. You've paid every invoice, hit every milestone, and the product is in market. Then the vendor's lawyer sends a letter outlining the conditions under which the IP will formally transfer — and those conditions, it turns out, haven't been met.

This is the end-of-project IP dispute. It is more common than most agencies will admit, and it almost always starts with the same clause buried somewhere past the payment terms in your software development contract: IP vests on completion, or on acceptance, or on final payment.

These phrases sound reasonable. What they actually do is create a gap — sometimes a significant one — between when you paid for something and when you legally own it. 

Software development is delivered in pieces. You fund sprints. You release milestone payments. You approve deliverables. But in most agency contracts, none of that intermediate work product is legally yours until the end — until a specific clause is triggered, a document is signed, and the vendor's side agrees that "completion" has occurred. If the engagement terminates early, if a dispute opens over scope, if the vendor's business changes — that gap becomes the problem.

The Built to Last™ 2.0 framework takes a different position: intellectual property transfers at every milestone, concurrent with payment. You own what you've paid for at the moment you've paid for it. Not at project completion. Not after the lawyers finish. 

This article makes a single argument for why that standard should be your minimum requirement in any software development engagement — and what happens to the clients who accept less.

The Clause That Gets Skipped in Contract Review

Software development contracts are long and review time is usually short. Most founders and procurement leads scrutinise the scope, the timeline, and the price. Legal teams focus on liability caps and indemnity clauses. The IP assignment clause — typically tucked into a later section — gets a skim. 

What it often says: IP vests in the client upon final payment. Or upon acceptance of the final deliverable. Or upon completion of the engagement.

Unpack those words. 

"Final payment" means the vendor retains IP throughout the entire build. Every sprint, every feature, every database schema and API specification — none of it is legally yours until the last invoice is cleared. If the engagement is terminated early, your claim to the work already delivered is ambiguous at best. You may have paid for six months of development and own nothing that can be acted on. 

"Acceptance" introduces a trigger that can be disputed. If the vendor disputes that acceptance has occurred — because the final sprint has outstanding defects, because scope changed, because the relationship deteriorated — you don't own the code until that dispute resolves. Acceptance disputes can take months.

"Completion of the engagement" is the loosest framing of all. Engagements rarely end cleanly. They have punch lists, follow-on requests, and support obligations that blur the finish line. When "completion" is undefined, the IP transfer date is undefined too — and the vendor holds the ambiguity.

None of this is hypothetical. Disputes over code ownership at the conclusion of software engagements are a recognised pattern in technology law. The most common shape: the relationship ends under tension, the vendor claims the final transfer conditions haven't been met, and the client is locked out of their own product while the dispute resolves.

Under Australian copyright law, IP in work created by a contractor belongs to the contractor unless a written assignment says otherwise. That's the baseline position your contract is correcting. If the correction is deferred to the end of the project, you are exposed for the entire duration of the build.

What Milestone-Level IP Assignment Actually Looks Like

The alternative is simple in principle and not difficult in practice.

IP transfers to the client at each milestone, as the corresponding invoice is paid. The transfer is explicit — it names the deliverables, the codebase state, the design files, the documentation generated in that sprint or phase. It doesn't wait for a completion trigger. It moves with the money.

In our custom software development practice under the Built to Last 2.0 framework, the IP assignment clause works this way: code, designs, database schemas, API specifications, test suites, and documentation generated in a milestone are formally assigned to the client when the milestone payment clears. The assignment is contractual, not implied. It covers partial work if the engagement terminates early — you own what you paid for up to that point, and you have it unconditionally.

Three situations make this arrangement matter most.

Early termination. Engagements end before planned completion more often than anyone expects at signing. Budget shifts. Direction changes. Teams change. If you need to transition to a new vendor mid-build, milestone IP assignment means you arrive with a clean codebase and unambiguous title. The new vendor can read the code and continue. Without it, the ownership question becomes a negotiation before the work can resume.

Investor due diligence. Technical due diligence for a funding round will ask who owns the codebase and whether the assignment is documented. "The agency assigns IP at project completion and we're still mid-build" creates uncertainty for any investor reviewing your data room. Milestone assignment means the answer is clean at every stage of the company's life, not just at the end of the engagement. 

Vendor insolvency. Rare, but it happens. Software agencies do fail. If an agency becomes insolvent while your product is in development and IP hasn't transferred, the work product may become part of the insolvency estate — an asset the liquidator can treat as recoverable. Milestone-level assignment significantly reduces this exposure: the work you've already paid for has already been assigned.

The practical requirements for making this work are modest. The contract needs a clause that transfers ownership per milestone, enumerates the deliverable categories (code, designs, documentation, schemas, test suites), and specifies that partial work is covered on termination. A competent technology lawyer can draft this clause in an hour. You can review how we structure this inside our broader project delivery framework to understand how IP assignment sits alongside the other handover commitments in a Built to Last 2.0 engagement.

The Pattern We See When This Goes Wrong

A composite that captures what we hear from clients who come to us after these situations: a mid-sized Australian professional services firm engaged a development vendor for a twelve-month build. The contract had a standard end-of-project IP clause. The engagement was terminated at month seven, following disagreements over scope and delivery pace. The vendor's position was that IP hadn't transferred because the final milestone hadn't been reached. The client's position was that seven months of invoices had been paid and the work was theirs.

Both positions were legally arguable. The dispute took four months to resolve. Legal costs through that period approached the value of multiple sprint cycles of development work. They eventually got access to the code — but delayed, with the codebase in an uncertain state, and months of momentum lost.

A comparable engagement running milestone IP assignment would have looked different. At the point of termination, ownership of the completed work would have been unambiguous. The conversation would have been about what to do next, not about who owned what. The legal cost drops to near zero. The new engagement starts from a clean position.

That is the real cost of the clause: not just worst-case exposure, but the friction it creates in every transition — vendor changes, scope reductions, early exits — that happen in entirely normal engagements.

When This Is Non-Negotiable and When It Can Wait

For any engagement over three months in duration or above a threshold where dispute cost would meaningfully exceed legal fees, milestone IP assignment should be a non-negotiable contract term. The risk window is too wide and the cost of dispute too high to accept end-of-project assignment. 

For very short engagements — a two-week proof of concept, a design sprint, a scoped audit — end-of-engagement assignment is probably acceptable. The exposure is bounded. A design sprint that transfers IP on completion creates a narrow window of ambiguity, not a year of it.

But for a product build, this is the standard to hold any vendor to. Any agency that resists milestone IP assignment is worth pressing on why. The answer will tell you how they think about the client relationship and what their exit posture looks like. An agency that builds the way it should — with clean, well-documented code delivered milestone by milestone — should have no objection to assigning it that way too.

One detail that is often missed: the assignment clause should cover designs and wireframes specifically, not just code. Figma files, design system components, UX research artefacts, and documentation are all protected by copyright and are part of your product's IP. A clause that only says "code" may leave the design layer ambiguous — and your design system is sometimes more valuable and transferable than the codebase it governs.

If you want to understand how we handle custom software delivery end-to-end — including how IP assignment, knowledge transfer, and post-launch accountability connect — that's the right place to start.

Frequently Asked Questions