You have found the right team, the demo looks sharp, and the proposal is sitting in your inbox. Then you reach the contract, and it is thirty pages of indemnification, warranties, and schedules you did not write. Signing it as-is is how founders end up paying for code they do not own, on a timeline nobody controls.
Negotiating a custom software development contract is not about winning points against your vendor. It is about aligning incentives so both sides stay motivated through month six, when the feature list has shifted and the budget is tighter than anyone planned.
This playbook walks through the clauses that actually move money and risk: IP ownership, payment milestones, change-order rates, acceptance criteria, and termination. Read it before your next legal review, and you will know exactly which lines to push on and which to leave alone.
Key takeaways
- IP ownership should transfer to you on final payment, with a broad license granted immediately so development is never blocked.
- Payment milestones should be tied to demonstrable deliverables, not calendar dates, and never front-load more than a modest deposit.
- Change-order rates must be locked in writing at signing, including the hourly rate, the approval process, and how scope creep is priced.
- Termination and exit terms determine whether you can walk away with working code, documentation, and credentials. Negotiate them before you need them.
- Everything you agree verbally is worthless unless it is written into the contract or a signed statement of work.
Start with the statement of work, not the master agreement
Most disputes are not caused by bad legal language. They are caused by a vague scope. The master services agreement sets the rules of engagement, but the statement of work (SOW) defines what you are actually buying.
Before you negotiate a single clause, make sure the SOW answers these questions:
- What specific features or outcomes are in scope, described concretely enough that a third party could verify delivery?
- What is explicitly out of scope? This list matters more than the in-scope list.
- What are the acceptance criteria for each deliverable, and who signs off?
- What assumptions is the vendor making about your team, your APIs, and your availability?
If the SOW is thin, no amount of clever contract language will save you. Push back on the scope document first, then negotiate the legal terms around it.
The clauses that decide whether you own your product
IP ownership in software development contracts
This is the clause founders most often get wrong. The default position of many vendors is that they retain ownership of the code and grant you a license to use it. That is fine for a SaaS subscription. It is a disaster for custom software you are paying to build.
What you want:
- Full assignment of IP to your company upon final payment, covering source code, designs, documentation, and any reusable components created specifically for you.
- A broad, irrevocable license granted immediately at signing, so the vendor can work on your code without waiting for payment to clear.
- A clear carve-out for the vendor's pre-existing tools, frameworks, and libraries. They keep those, and you get a perpetual license to use them as embedded in your product.
- An assignment of third-party dependencies or at least a disclosure list, so you know what open-source or commercial licenses you are inheriting.
Watch for language that assigns IP only on "full and final payment" without defining what triggers final payment. If the vendor can delay acceptance indefinitely, they can delay your ownership indefinitely.
Moral rights and contributor assignments
If the vendor uses subcontractors or offshore contributors, confirm that those individuals have assigned their rights to the vendor, who then assigns them to you. Without that chain, a contractor could theoretically claim rights to code they wrote. Ask for a representation that all contributors have signed appropriate assignments.
Payment milestones for custom software projects
How you structure payments determines who carries the risk if the project stalls. The vendor wants cash flow. You want leverage. Both are reasonable.
A structure that works for most engagements:
- Deposit (10-20%) at signing, to reserve the team and cover initial discovery.
- Milestone payments tied to demonstrable deliverables: a working prototype, a completed module, a passing test suite, a deployed staging environment.
- Final payment (10-20%) on acceptance and handover of code, credentials, and documentation.
Push back on any schedule that front-loads more than a quarter of the total before you have seen working software. If the vendor insists on calendar-based billing, ask what happens if the date slips for reasons within their control.
Also clarify what "demonstrable" means. A demo video is not a deliverable. A running build in a staging environment that you can click through is.
How to negotiate software development pricing without breaking the relationship
Pricing negotiation is not just about the number. It is about the structure, the assumptions, and the change mechanism.
Fixed price, time and materials, or capped T&M
- Fixed price gives budget certainty but usually comes with a risk premium and a rigid scope. Good for well-defined, short projects.
- Time and materials is flexible but exposes you to scope creep. Good when requirements will evolve.
- Capped T&M combines a not-to-exceed ceiling with hourly billing. Often the best fit for custom software, provided the cap is realistic.
Change-order rates
This is where projects quietly go over budget. Lock in the following at signing:
- The hourly rate for each role (senior engineer, designer, QA, project manager).
- The approval process for change orders, including who on your side can authorize and what constitutes written approval.
- A threshold below which small changes are absorbed without a change order, so you are not signing paperwork for a two-hour tweak.
- A cap on change-order markup, if the vendor applies one.
If the vendor refuses to commit to change-order rates, treat that as a red flag. It means every scope change becomes a fresh negotiation, and you have no leverage once the project is underway.
Acceptance criteria and the definition of done
Vague acceptance language is the most common cause of payment disputes. Define it precisely.
- What tests must pass? Unit, integration, end-to-end?
- What performance thresholds must be met, if any?
- How long does the vendor have to fix defects found during acceptance?
- What happens if you do not respond to an acceptance request within a set number of days? Silence should not equal acceptance unless you agree to it.
Also negotiate a warranty period after acceptance, typically 30 to 90 days, during which the vendor fixes defects at no cost. Distinguish defects (bugs) from enhancements (new features), or every bug report becomes a change order.
Termination, exit, and what you take with you
You hope never to use this clause. Negotiate it anyway.
- Termination for convenience with a defined notice period, so you can stop the engagement if priorities change.
- Termination for cause with a cure period, so a single missed deadline does not automatically end the contract.
- Transition assistance at an agreed rate, so the vendor helps hand over code, infrastructure, and knowledge to your team or a new vendor.
- Return of materials, including source code, repositories, design files, credentials, and documentation.
- Payment on termination for work completed and accepted, not for work in progress that was never delivered.
The exit clause is where a well-negotiated contract proves its worth. If you can leave cleanly, you can also stay confidently.
Practical negotiation tactics that work
- Negotiate in parallel with legal review. Do not let legal and commercial conversations run sequentially, or you will lose weeks.
- Prioritize three clauses. IP, payment milestones, and termination. Trade on the rest.
- Ask for the vendor's standard contract early. Reviewing it before you are emotionally committed gives you real leverage.
- Put every verbal promise in writing. A follow-up email summarizing what was agreed is enough to prevent later disputes.
- Involve a lawyer for anything above your risk threshold. A few hours of legal review is cheap compared to a stalled project.
If you are evaluating build partners and want to see how a team structures delivery, ownership, and handover in practice, it is worth looking at the work we have shipped before you start negotiating.
When to walk away
Some contracts are not worth fixing. Walk away if the vendor refuses to assign IP, will not commit to change-order rates, insists on payment for work in progress without deliverables, or denies you a termination-for-convenience clause. Those are not negotiation positions. They are deal-breakers.
Avaton builds custom software, AI systems, and mobile apps for founders and CTOs, and we are happy to talk through how we structure contracts and delivery. If you want a second opinion on a contract you are reviewing, get in touch and we will share what we have seen work.
Frequently Asked Questions
Who owns the IP in a custom software development contract?
By default, the developer owns the IP unless the contract says otherwise. In a custom software engagement, you should negotiate full assignment of IP to your company upon final payment, plus a broad license granted immediately so development is not blocked. Pre-existing vendor tools and open-source components are typically carved out, with a perpetual license granted to you for their use within your product.
How should payment milestones be structured for custom software projects?
Tie payments to demonstrable deliverables rather than calendar dates. A common structure is a deposit of roughly 10-20% at signing, milestone payments on working builds or completed modules, and a final payment on acceptance and handover. Avoid schedules that front-load more than a quarter of the total before you have seen working software, and clarify in writing what counts as a deliverable.
What change-order rates should I lock in before signing?
Lock in the hourly rate for each role, the approval process for change orders, the threshold below which small changes are absorbed without paperwork, and any markup the vendor applies. If a vendor refuses to commit to change-order rates at signing, treat it as a red flag, because every scope change will become a fresh negotiation once the project is underway.
Can I terminate a custom software development contract early?
Only if the contract gives you that right. Negotiate termination for convenience with a defined notice period, termination for cause with a cure period, transition assistance at an agreed rate, and return of all materials including source code, credentials, and documentation. You should also confirm that payment on termination covers only work completed and accepted, not work in progress that was never delivered.
Do I need a lawyer to review a software development contract?
For any engagement above your personal risk threshold, yes. A lawyer can catch indemnification, liability, and warranty language that founders often overlook. That said, you can and should negotiate the commercial terms yourself: IP ownership, payment milestones, change-order rates, acceptance criteria, and termination. Bringing legal in after you have agreed the commercial shape of the deal saves time and money.
Cover: Photo by Boris Hamer on Pexels