Software agency contract red flags: 8 clauses to check in 2026
Eight clauses decide who owns your code, when you pay, and how you leave. Here are the software agency contract red flags to catch before you sign in 2026.
The most expensive line in a software agency contract is usually the one nobody reads. A founder pays a six-figure invoice, ships the product, then tries to move to a new team and finds the agency still owns the code. That is the pattern behind most software agency contract red flags: the clauses that decide ownership, payment, and exit sit under the scope language, and they only surface when something has already gone wrong.
We build SaaS products, and we also inherit them from other teams. We have read enough of these agreements to see the same eight red flags recur. None of them need a law degree to spot. They need you to know where to look. This is not legal advice: for any contract that commits real money, have a qualified attorney review it before signing. What follows is how these clauses actually behave once the project is running, so you know which sentences to hand your lawyer first.
Red flag 1: no explicit IP assignment, only "work made for hire"
This is the single most expensive misunderstanding in software contracts. Many agreements label the deliverables a "work made for hire" and stop there. Under US copyright law, that phrase alone often does not transfer ownership of commissioned software. The work made for hire doctrine is built for employees and a short list of specific categories, and commissioned code frequently falls outside it. Courts have repeatedly declined to treat software as a work made for hire just because the contract said so (CCBJournal, Association of Corporate Counsel).
The fix is a separate, explicit assignment clause: on final payment, the agency assigns all right, title, and interest in the work product to you, including copyright, patents, and trade secrets. Paying for the work does not, by default, mean you own it. If the contract has the "work made for hire" label but no backup assignment, that is a red flag, not a formality.
Red flag 2: full payment upfront or dates tied to the calendar
A vendor who asks for 100% before meaningful work, or who ties payments to dates rather than to accepted deliverables, has removed their own incentive to finish. A healthy structure looks like a 20 to 30% deposit, 40 to 50% across two or three milestones tied to completed features, and 20 to 30% on final acceptance. Each milestone should map to something you can verify, not to a week on a calendar.
The trap we see most often is a founder who pays 50% upfront for a "discount." The discount is almost always smaller than the rework cost when the project drifts. Milestone-linked payment keeps both sides honest.
Red flag 3: no acceptance criteria, no definition of done
If the contract never says what "finished" means, every deadline becomes negotiable and every dispute becomes your word against theirs. Acceptance criteria are the checklist that defines a completed deliverable. If the agency cannot write them before the build, they do not yet understand the work.
Look for a defined review window too, commonly five business days, in which you accept a milestone or raise specific issues. A contract where acceptance has no deadline, or where silence never counts as either acceptance or rejection, leaves the project in permanent limbo. Poor requirements and scope management remain the top reasons software projects miss: the Standish Group's long-running CHAOS research has kept full project success below one in three, with unclear requirements and scope creep among the leading causes (ReqSuite, on Standish CHAOS).
Red flag 4: no source code access during the build
You should see the repository from day one, not receive a zip file at the end. When code lives only on the agency's machines until final delivery, you cannot verify progress, you cannot bring in a second opinion, and you have no leverage if the relationship breaks down mid-project. Insist on your own version control organization, with the agency working inside it. A contract that delivers source "on completion" and gives no interim access is a lock-in mechanism dressed as convenience.
Red flag 5: no warranty and no defect-fix window
Software ships with bugs. The question is who fixes them, and for how long, after launch. A contract with no warranty period and no service level for defects treats the day of handover as the end of all responsibility. A reasonable term is a defined window, often 30 to 90 days, in which the agency fixes defects in the delivered scope at no extra charge. Without it, the first production bug becomes a new paid engagement.
Red flag 6: vendor lock-in through proprietary infrastructure
Some agencies tie deliverables to their own hosting, their own internal libraries, or a proprietary CMS you cannot run without them. The code may be "yours" on paper and still be unusable by another team. Ask a blunt question before signing: can I take the full codebase and run it with a different team tomorrow. If the answer is not an immediate yes, you are looking at lock-in. Standard, portable tooling matters more here than any clause.
Red flag 7: undefined change requests and silent scope creep
Requirements change on almost every project. The contract should say how. A clear change-request process defines how new work is quoted, approved, and billed before it starts. When that process is missing, one of two things happens: the agency absorbs the changes and quality drops, or the agency bills them silently and the invoice balloons. Around three quarters of software projects experience scope creep, so treat the change process as a core term, not boilerplate.
Red flag 8: one-sided liability and indemnity
Read the liability section from your side of the table. A common imbalance: the agency caps its own liability at the fees paid (or less), while asking you to indemnify it broadly. That combination means you carry most of the risk for work you did not write. You will not remove all risk from a services contract, and you should not try to. You should make sure the liability is not wildly asymmetric, and that any indemnity you give is tied to your own conduct, not the agency's.
How to fix what is already there
If you have already signed and now recognize a red flag, you are not out of options. Ask for a written amendment on the specific clause: an assignment of IP on final payment, a defect-fix window, repository access. Agencies that intend to do good work usually agree, because the ask is reasonable and the alternative is a nervous client. An agency that refuses a clean IP assignment after you have paid is telling you something worth hearing. Tie any new work or milestone to the amendment so there is a natural moment to sign it.
How to prevent it next time
Prevention starts before the contract. A tight brief and a clear scope reduce the surface area where these clauses can hurt you. Writing a specific RFP that attracts the right vendors filters out the shops whose margin depends on ambiguity. Understanding how to hire a product engineering studio and which model fits your stage tells you what a fair contract looks like before one lands in your inbox. Keep a short standing checklist: explicit IP assignment, milestone payments, acceptance criteria, live repo access, a defect warranty, portable infrastructure, a change process, and balanced liability. Eight lines. Read them every time.
Sources
Frequently asked questions
Who owns the code if the contract only says "work made for hire"?
Often not you. Under US copyright law, the work made for hire doctrine is built mainly for employees and a short list of categories, and commissioned software frequently falls outside it. Courts have declined to treat code as work made for hire just because the contract used the phrase. To actually own the software, the agreement needs a separate, explicit assignment clause that transfers all rights to you on final payment. Treat the two as distinct: the label alone is not ownership.
How much should I pay a software agency upfront?
A common healthy structure is a 20 to 30% deposit, 40 to 50% across two or three milestones tied to completed features, and 20 to 30% on final acceptance. Avoid paying 100% upfront, even for a discount: the discount is usually smaller than the rework cost if the project drifts. Payments tied to accepted deliverables, not to calendar dates, keep the agency motivated to finish.
Should I get access to the source code during the project or only at the end?
During, from day one. Insist that the agency works inside your own version control organization so you can see progress, bring in a second opinion, and keep leverage if the relationship breaks down. A contract that promises source "on completion" with no interim access is a lock-in mechanism. Interim access does not mean you review every commit; it means the code is yours to inspect at any time.
Is it worth paying a lawyer to review a software development contract?
For any contract committing meaningful money, yes. A focused review of the IP assignment, payment schedule, acceptance criteria, warranty, and liability clauses usually costs a fraction of what a single unowned codebase or a stalled milestone costs later. Point your lawyer at those specific sections rather than asking for a general read: it is faster and cheaper, and those are the clauses that actually decide your exposure.
Related articles
Studio
Start a project.
One partner for the whole build. Faster delivery, a modern stack, lower cost.