Why does a software contract need a separate IP assignment clause, and isn't paying for the work enough?

No. Paying an independent contractor to write code does not automatically make you the owner of that code under U.S. copyright law. Standalone software written by a contractor is almost never treated as a "work made for hire" by default, so without a written clause assigning the copyright to you, the developer can remain the legal author even after full payment.

What should an IP assignment clause actually say?

It should state plainly that all code, designs, and documentation created under the contract are assigned to you, not merely licensed, and that the assignment takes effect as each piece of work is created rather than only at final payment. It should also name any open-source or pre-existing components the vendor plans to reuse, so you know upfront what you own outright and what you are only licensed to use.

What are acceptance criteria, in plain terms?

Acceptance criteria are the written conditions a piece of work has to meet before you are required to accept it and pay for it. Without them, "finished" is whatever the vendor says it is, and a dispute becomes your opinion against theirs with nothing in writing to settle it.

How specific do acceptance criteria need to be?

Specific enough that someone outside the project could check the finished work against the document and get the same yes-or-no answer you would. A criterion like "the login page should work well" is not checkable; a criterion like "a user can log in with a valid email and password and reach the dashboard within a stated time" is.

What should a contract say about a vendor that cannot deliver?

It should define what counts as non-delivery (a missed milestone, a build that fails your acceptance criteria after a stated number of attempts, or the vendor going unresponsive for a stated number of days) and say exactly what happens next: a cure period to fix it, a refund or credit for undelivered milestones, and your right to take the work elsewhere. Without this, a stalled project has no clear next step and no clock running against the vendor.

What is an exit clause and why does a healthy project still need one?

An exit clause sets the terms for ending the contract before the work is finished, on notice, without either side having to prove the other broke a promise. You want this even in a project going well, because plans change, budgets change, and a contract that only ends through breach or full completion traps both sides in a relationship neither wants anymore.

What is source code escrow and when does a project actually need it?

Source code escrow is a three-party arrangement where a neutral company holds a current copy of the source code and releases it to you if the vendor goes out of business, stops supporting the software, or breaks the contract in a defined way. It matters most when your business depends on software only one vendor can maintain, especially a cloud-hosted product where the code alone will not restore service without the underlying infrastructure and configuration too.

Does escrow apply to software hosted in the cloud, or just code you install yourself?

It applies to both, but the cloud case needs a broader version usually called SaaS escrow. Source code by itself will not bring a hosted product back online, so a SaaS escrow arrangement also covers the database structure, configuration, and deployment steps needed to actually relaunch the service, not just a folder of files.

If we trust the vendor, do we still need all four of these in writing?

Trust is not the thing a contract protects against. It protects against the vendor being acquired, running out of money, losing the one person who understood your system, or simply disagreeing with you later about what was promised. None of those require anyone to have acted in bad faith, and a clear contract is what keeps a disagreement from becoming a dispute.

Who should review these clauses before signing?

A lawyer who has read software contracts before, not a general business lawyer reading one for the first time. IP assignment and acceptance criteria carry specific pitfalls (like the work-for-hire misconception above) that are easy to miss without experience in this exact type of agreement.

Can we add these clauses to a contract a vendor has already drafted?

Usually yes. Most of these are additions or clarifications rather than a rewrite of the whole agreement, and a vendor with nothing to hide will not resist adding a clear IP assignment clause, written acceptance criteria, or a non-delivery plan. Real resistance to any of these four is itself worth treating as information.

What to check before a software dev contract: Reveneau

We have been on the vendor side of enough contracts to know which clauses get skimmed and which ones matter the day something goes wrong. Almost nobody reads a software contract carefully when things are going well. They read it, carefully, for the first time, six months in, when a milestone has slipped or a vendor has gone quiet, and by then it is too late to change the terms.

The good news is that the terms that matter are a short list. Most software contracts fail their client in one of four specific places: who owns the code, what "done" means, what happens if the vendor cannot finish, and how either side gets out. Check these four before you sign, not after.

1. IP assignment: does paying for the work actually make it yours?

This is the clause people assume they don't need to check, and it's the one most likely to be wrong.

Here is the part that surprises most founders: paying a contractor to write software does not automatically transfer ownership of that code to you. Under U.S. copyright law, the person who writes a work owns it by default, and the "work made for hire" exception that flips that default only applies automatically to employees, not independent contractors. For an independent contractor, standalone software is almost never one of the narrow categories of work the law lets a written work-for-hire agreement cover in the first place. The practical result, confirmed by copyright attorneys who specialize in this exact question: without a written assignment, a contractor can remain the legal author of code you paid for and believe you own.

So the contract needs an assignment clause, not just a "work made for hire" label. It should say, plainly, that all code, designs, and related documentation created under the agreement are assigned to you: not licensed, assigned. It should also say when that assignment takes effect. A clause that only transfers ownership "upon final payment" leaves you with no rights to anything built along the way if the project ends early.

One more thing to check here: what open-source or pre-existing code the vendor plans to reuse. You will not own a third party's open-source library just because your product uses it, and a contract that pretends otherwise is not doing its job. A vendor who cannot name what they're bringing in from outside the project is a vendor who has not thought about this either.

2. Acceptance criteria: what does "done" actually mean?

Every dispute we have seen or heard about between a client and a vendor traces back to the same root cause: nobody wrote down what "finished" meant before the work started.

Acceptance criteria are the written conditions a piece of work has to meet before you are required to accept it and pay for it. Without them, whether something is done is a matter of opinion, and it is always the vendor's opinion that shows up in the invoice.

The test for a good acceptance criterion is simple: could someone outside the project check the finished work against the document and reach the same answer you would? "The checkout flow should work well" is not checkable. "A customer can add an item, enter a valid card, and receive an order confirmation within a stated time, and a declined card shows a clear error and does not create an order" is checkable. The second version protects both sides. It gives the vendor a target instead of a mood, and it gives you a document to point to instead of a feeling that something is off.

This is the same discipline behind writing an automated check before the code exists, which is how we scope any build we take on: state what correct looks like in a form that produces a yes or no answer, before anyone starts building toward it. A contract's acceptance criteria are the plain-language version of the same idea.

3. What happens if the vendor cannot deliver?

Most contracts describe what happens when everything goes right. Fewer describe what happens when it doesn't, and that is the clause you actually need on the days a project goes sideways.

The contract should define, in advance, what counts as non-delivery: a missed milestone date, a build that fails the acceptance criteria after a stated number of correction attempts, or the vendor going unresponsive for a stated number of days. Then it should say exactly what happens next. A reasonable structure has three parts: a cure period, during which the vendor gets a defined window to fix the problem; a refund or credit for any milestone not delivered; and your right to take the existing work and hand it to someone else without penalty.

Without this clause, a stalled project has no clock running against the vendor and no clear next step for you. You are left negotiating from nothing, usually while the project is losing money every week it sits unfinished.

4. The exit clause: can you leave a project that's going fine?

This is the clause people are least likely to think they need, which is exactly why it matters.

An exit clause sets the terms for ending the contract before the work finishes, on notice, without either side having to prove the other broke a promise. You want this in a contract for a project that's going well just as much as one that isn't, because business plans change. Budgets get cut. Priorities shift. A contract that only ends through a breach or full completion of the work traps both sides in an arrangement neither one wants anymore, and that kind of trap tends to produce resentful, low-quality work from whichever side feels stuck.

A workable exit clause states a notice period (commonly 30 days), what you owe for work completed up to that point, and confirms that the IP assignment clause and any escrow arrangement still apply even if the contract ends early. Ending well is not a sign the relationship failed. It's a sign the contract did its job.

5. Source code escrow: what happens if the vendor disappears?

This one matters most for a specific situation: your business depends on software that only one vendor can maintain, and losing access to that vendor, through bankruptcy, an acquisition, or simply the developer moving on, would stop your business from running.

A software escrow agreement is a three-party arrangement. You, the vendor, and a neutral escrow company. The vendor deposits a current copy of the source code with the escrow company, and the agreement states specific trigger events, such as the vendor going out of business, ceasing to support the software, or breaking the contract in a defined way, under which that code is released directly to you. It exists for exactly the situation the exit clause and the non-delivery clause do not fully cover: the vendor is gone, not just slow.

If your product is hosted in the cloud rather than installed on your own systems, plain source code escrow is not enough on its own. Source code by itself will not bring a hosted product back online. A cloud product needs a broader version, usually called SaaS escrow, which also covers the database structure, configuration, and deployment steps needed to actually relaunch the service, not just a folder of code.

Not every project needs this. A short internal tool with a short shelf life probably doesn't justify the cost of an escrow arrangement. A product your company depends on to run, built by a vendor you'd struggle to replace quickly, usually does.

Read the contract like the project will go wrong

None of this assumes bad faith on anyone's part. A vendor can be well-meaning, skilled, and still get acquired, run out of funding, or lose the one person who understood your system. None of that requires anyone to have done anything wrong, and a contract that only works when everything goes right is not protecting you from anything.

The four clauses here (IP assignment, acceptance criteria, a non-delivery plan, and an exit path with escrow where it's warranted) are not adversarial. A vendor with nothing to hide will not resist adding any of them, and a vendor who does resist has told you something worth knowing before you sign. When we scope a build, these are the terms we expect a client to ask about, because a contract that only reads well on a good day was never protecting anyone.

Sources

Work Made for Hire: Why Paying for Code Doesn't Mean You Own It: Confirms that software created by an independent contractor is almost never a statutory work made for hire, and that a written assignment is the actual path to ownership.
17 U.S. Code § 201. Ownership of copyright: The statutory basis for copyright vesting in the author by default, and the narrow categories the work-for-hire exception covers.
What Is a Software Escrow Agreement and Why It Safeguards Business Continuity: Explains the three-party escrow structure, release triggers, and the distinction between source code escrow and SaaS escrow.