Most buyers reviewing a software development contract focus almost entirely on price and timeline, and skip past the clauses that actually determine what happens when something goes wrong: IP ownership, source code delivery, acceptance criteria, and post-launch maintenance. This article walks through 15 clauses worth checking in any 2026 software development contract, explains why each one matters, and what wording to look for, with a payment milestone example you can use as a starting point.
Note: This is general information, not legal advice — have a lawyer review any contract before you sign.
The 15-Clause Contract Checklist
Every contract will look a little different depending on project size and industry, but the 15 clauses below are the baseline for most custom software engagements. Go through the vendor's draft line by line against this table rather than jumping straight to the total price on the last page.
| # | Clause | Why It Matters | Suggested Wording |
|---|---|---|---|
| 1 | IP / copyright ownership | Without assignment language, code copyright can default to the vendor even after full payment | State that "all IP in code, documentation, and UI design created under this agreement transfers to the client upon acceptance and final payment" |
| 2 | Source code delivery & escrow | Getting code only at project close leaves you unprotected for the entire build, especially if the vendor closes shop mid-project | Require code delivery at every milestone, or host the repository under the client's own account from day one |
| 3 | Acceptance criteria | Vague "completion" language leads to disputes that delay both sign-off and payment | List specific, testable criteria per feature in writing, plus a fixed review window (e.g., 10 business days) |
| 4 | Milestone payment schedule | Full payment upfront shifts all the risk to the client; full payment at the end shifts it all to the vendor | Split payment across 4-5 milestones: signing, design approval, MVP, UAT, final handover |
| 5 | Warranty period | Without one, a bug found in week one after launch can be billed as a new feature request | Specify a warranty period (e.g., 60 days post-acceptance) for free fixes of vendor-caused defects |
| 6 | Post-launch maintenance SLA | Without an SLA, response time for outages depends entirely on the vendor's available capacity that day | Define severity tiers (P1/P2/P3) with matching response and resolution times |
| 7 | Change-request pricing | Without a pricing mechanism, scope creep can absorb unlimited budget and time | Require written approval for scope changes, billed at an agreed hourly or fixed rate |
| 8 | Termination clause | Without one, either party trying to exit the engagement can end up in a standoff | Define termination triggers, notice period (e.g., 30 days), and post-termination deliverables and refunds |
| 9 | Confidentiality / NDA | Development work exposes business logic and operational data with real leak risk | Specify scope, duration (e.g., 2-3 years post-termination), and damages for breach |
| 10 | Data ownership | Without a separate clause, data ownership can get conflated with code copyright | State that "user and operational data generated by the system belongs to the client" |
| 11 | Third-party license disclosure | Undisclosed or improperly licensed open-source components can create legal exposure or forced removal later | Require the vendor to list third-party packages used, their licenses, and any restrictions |
| 12 | Liability cap | Without a cap, theoretically unlimited exposure makes vendors reluctant to sign, or pushes them to bury protective terms elsewhere | Cap each party's liability, commonly a multiple of total fees paid |
| 13 | Subcontracting rights | Undisclosed subcontracting to an unknown team removes visibility into quality and confidentiality | Require written client consent for subcontracting, with the vendor liable for the subcontractor's conduct |
| 14 | Dispute resolution / governing law | Without this, cross-border disputes start with an argument over which court even has jurisdiction | Name the governing law and either a court or arbitration body |
| 15 | Deliverable format | Undefined "delivery" can mean you get a compiled binary instead of a maintainable project | List exactly what's delivered: source code, database schema, deployment docs, user manual |
The "Suggested Wording" column isn't meant as drop-in legal language — it's a prompt for what to pin down during negotiation. Most contract disputes don't start from a clause being completely missing; they start from a clause being vague enough that each side reads it the way that favors them. As an anonymized composite example drawn from multiple engagements, not a specific client: a 20-person B2B SaaS startup once received a draft that simply said "final payment due on acceptance," with no acceptance criteria or timeline attached. After renegotiating, the parties added the specific acceptance conditions from clause 3 and a 4-milestone payment schedule from clause 4, so both sides could confirm progress at each checkpoint instead of discovering a mismatch only at the very end. Treat this table as a line-by-line checklist against every draft you receive, not just a reference to skim once.
IP Ownership and Source Code: The Two Clauses Buyers Get Wrong Most Often
IP ownership sits at the top of this checklist because most clients assume that paying for the work automatically means they own the code. That assumption doesn't always hold. Copyright law in many jurisdictions treats code written by an independent contractor as belonging to the contractor by default — as one review of software agreement clauses puts it, code "cannot be made a 'work made for hire' just by saying so," and ownership needs to be assigned explicitly in writing rather than assumed. If your contract is silent on this point, you may end up with only a license to use the software you paid for, not full ownership — which becomes a real problem the moment you want to switch vendors, modify the code yourself, or resell the product.
Source code delivery is the second most commonly mishandled clause. Many clients assume they'll simply "get the code when it's done," but without a delivery clause specifying timing and format, a vendor may only hand it over at project close — sometimes only compiled binaries, not the underlying source. The stronger arrangement is to host the repository (GitHub, GitLab, or similar) under the client's own account from day one, with the vendor added as a collaborator. That way, even if the relationship ends early or turns adversarial, the client always holds the current, working codebase. For larger or mission-critical builds, source code escrow — a third party holding a copy of the code, released only if the vendor breaches or goes out of business — is worth the added cost.
How to Write Acceptance Criteria That Don't Lead to Disputes
Acceptance disputes rarely happen because the software is "bad" — they happen because the two sides never agreed on what "done" meant in the first place. A solid contract breaks each major feature down into specific, testable conditions instead of a blanket line like "complete the e-commerce platform." For example: "checkout must support both credit card and bank transfer, and a successful transaction must be correctly recorded in the order database."
The contract should also set a firm review window — for instance, the client has 10 business days after delivery notice to test and respond, after which acceptance is deemed to have occurred if there's no response. If issues are found, define severity tiers and matching fix timelines so a minor bug doesn't stall the entire project. A review of acceptance-clause best practices puts it plainly: define exactly how each deliverable will be tested and approved — for example, "the login feature is accepted if it passes user testing with no critical bugs" — rather than relying on subjective language like "meets client satisfaction."
Payment Milestone Example: From Signing to Final Handover
The payment schedule is really a risk-sharing decision. Paying everything at the end shifts all the cash-flow risk onto the vendor, which can hurt delivery quality; paying everything upfront leaves the client with no leverage if things go wrong. A more balanced structure splits the total across 4-5 milestones tied to real project checkpoints:
| Milestone | Suggested % | What It Covers |
|---|---|---|
| Signing | 20-30% | Project kickoff, covering discovery and initial architecture work |
| Design / spec approval | 20% | Paid once UI designs and the technical spec are reviewed and approved in writing |
| MVP delivery | 20-30% | A working version of core functionality, delivered for hands-on testing |
| UAT / acceptance | 20% | Paid once user acceptance testing (UAT) is complete with no critical defects |
| Final handover | 10-20% | Paid at go-live, after training and documentation are delivered |
Based on our 2026 project experience, this 4-5 milestone structure is common for SMB custom software engagements in Taiwan and internationally. Holding back 10-20% for final handover keeps the vendor incentivized to stay responsive through the post-launch period, rather than deprioritizing support once most of the fee has already been collected.
Where do these percentage ranges actually come from, and how should you read them? The split reflects risk-sharing and trust at the moment of negotiation, not an arbitrary number pulled from a template. A signing payment near the low end of 20% usually means the two sides are still building trust in a first-time engagement, and the vendor is willing to accept less upfront protection; a signing payment closer to 30% usually means the vendor's early architecture and discovery work is genuinely heavy, or that there's an existing track record between the parties that justifies more upfront commitment. The same logic applies to the final handover holdback — 10% is often enough for a low-risk internal tool, while a system touching payments, member data, or public-facing services is worth pushing toward the 20% end, so the vendor still has a real incentive to stay responsive right after go-live. The useful question when you see one of these ranges isn't "what's the average" — it's "where does our project sit in this range, and why."
Warranty Period vs. Maintenance SLA
Warranty and post-launch maintenance often get collapsed into a single vague "support" line item, but they're two different things. Warranty typically covers bug fixes for defects caused by the vendor's own errors, and while there's no universal standard, 30 to 90 days after acceptance is a common range. Once the warranty period ends, further fixes or feature changes are generally billed separately.
A maintenance SLA is the longer-term arrangement that follows the warranty period, and it should specify at least three things: severity tiers (P1 for system-wide outages, P2 for partial feature loss, P3 for minor UI issues), matching response and resolution times (a P1 might require a 4-hour response and 24-hour fix), and how the fee is calculated — flat monthly rate or usage-based. Based on our 2026 project experience, annual maintenance typically runs 15-20% of the original build cost, though the exact figure depends on system complexity and the SLA tier chosen.
As an anonymized composite example: a 50-employee retail client discovered in the second week after launch that order-confirmation emails were occasionally not sending. Because the contract defined warranty as 60 days post-acceptance and explicitly covered defects in existing functionality, the vendor investigated and fixed it at no charge. In the same conversation, the client asked for a new SMS notification feature — since that fell outside the original acceptance scope, it was treated as a change request and billed separately under the change-pricing clause. The distinction isn't about how big the issue is; it's about whether something that was already promised doesn't work, versus something new being requested. Having this written down means both sides have something to point to when the question comes up, instead of arguing about it after the fact.
Common Mistakes and Red Flags
These are the mistakes we see most often when SMEs sign a software development contract without a full review:
- A single lump-sum price with no breakdown. Without itemized pricing per module, it's nearly impossible to fairly price scope changes later.
- Acceptance criteria written as "meets client requirements." This kind of subjective language has no teeth in a dispute — insist on specific, testable conditions instead.
- No stated timing for source code delivery. If the contract doesn't say when code is delivered, assume it defaults to "only at the very end, if you ask."
- Warranty and maintenance treated as the same thing. Confirm what's covered for free during warranty versus what triggers a separate maintenance fee.
- No liability cap at all. This sounds client-friendly, but in practice it often makes vendors reluctant to sign, or pushes them to bury protective language elsewhere in the contract.
- Subcontracting without consent. If the contract doesn't require approval for subcontracting, the team that actually writes your code may not be the one you vetted.
- Governing law and jurisdiction left blank. This is especially risky with an overseas vendor — without it, a dispute starts with an argument over which court even has authority.
Most of these red flags don't require a legal background to spot on a first pass. Read the draft once specifically looking for clauses that are vague or simply absent, mark them, and bring that shortlist to the vendor for clarification or to a lawyer for review. That's a faster and more focused way to work through a contract than reading it start to finish and hoping the risky parts jump out on their own.
Next Steps
Contract clarity is often the difference between a project that ships smoothly and one that stalls halfway through. If you're preparing an RFP or about to sign a software development contract, use the 15-clause checklist above to review the vendor's draft line by line, then have a lawyer do a final pass. Noise & Signal provides end-to-end custom software development services, from discovery and contract scoping through architecture, delivery, and post-launch maintenance — see our Custom Software Development Services page for how we define scope and deliverables. For a look at our engagement stages and typical pricing at each one, see our Process & Pricing page.