How to Write a Software Development Contract (That Actually Protects You)

You found a dev shop you like. Their portfolio looks good, the discovery call went well, and they sent over a contract. You skimmed it, it seemed reasonable, and you were tempted to just sign and start building.

Don't.

That contract was written by their lawyer, for their benefit. It protects their cash flow, limits their liability, and gives them maximum flexibility if things go sideways. Yours is the name on the dotted line — but you're not the one this contract was designed to protect.

This isn't about assuming bad faith. Most dev shops are run by decent people. But contracts reflect incentives, and a dev shop's incentives don't always align with yours. Knowing what to negotiate — and what to reject — is the difference between a smooth build and a $60,000 lesson.

Why the Standard Dev Shop Contract Is Written to Protect Them

The default software development contract evolved to minimize vendor risk. That means:

Scope is deliberately flexible. Vague deliverable definitions give the agency room to redefine what "done" looks like.
Payment flows regardless of progress. Monthly retainers and time-and-materials billing mean you pay whether milestones are hit or not.
IP ownership is murky until final payment. Many contracts include clauses where you don't own the code until 100% of fees are paid — including disputed fees.
Liability is capped at what you paid them. If the project fails and costs you $200K in lost opportunity, you might recover $30K. Maybe.
Jurisdiction favors them. Disputes resolved in their home state, under their local laws, with their preferred arbitration clauses.

None of this is illegal. All of it is negotiable. And most founders never push back — because they don't know what to look for.

The 5 Clauses Every Founder Must Negotiate

1. IP Assignment

This is the most important clause in any hire developer contract. It should state clearly and unambiguously that all intellectual property — code, designs, documentation, APIs — transfers to you upon payment of each milestone.

Watch for: conditional IP transfers ("IP transfers upon receipt of full payment"), shared IP arrangements, or licenses instead of assignments. If you're paying for custom software, you should own it outright. Period.

Push for: "All work product created under this agreement is work-for-hire and all intellectual property rights are assigned to [Your Company] upon completion and payment of each applicable milestone."

2. Milestone-Based Payments

Never sign a contract with open-ended monthly billing without hard milestones attached. A software project contract template that protects you should tie every payment to a specific, testable deliverable.

Bad: "We'll invoice $15,000/month until the project is complete."

Good: "$10,000 upon delivery and acceptance of the user authentication module. $10,000 upon delivery and acceptance of the core dashboard. $10,000 upon delivery and acceptance of payment integration."

Milestone payments give you leverage. If a milestone isn't delivered, you don't pay. Simple.

3. Kill Clause

Projects get cancelled. Markets shift, funding falls through, priorities change. A kill clause (also called a termination for convenience clause) lets you exit the contract without paying for work not yet started.

Most dev shop contracts have kill clauses that favor them — 30-day notice periods where you keep paying full rate, or cancellation fees that make exiting expensive.

Push for: 14-day notice period. Pay only for completed milestones and work-in-progress proportional to the next milestone. No punitive cancellation fees.

4. Source Code Escrow

If the dev shop goes under mid-project, what happens to your code? Without source code escrow, the answer is: nothing good.

Source code escrow means all code is committed to a neutral third-party repository (or simply your own GitHub) at defined intervals — ideally weekly. If the vendor relationship breaks down, you have the codebase and can continue with another team.

This is especially critical for long-term projects. Insist on weekly commits to a repository you control, or to an escrow service like EscrowTech.

5. Acceptance Criteria

"Feature complete" means nothing without a definition of what "complete" looks like. Acceptance criteria are the specific, testable conditions a deliverable must meet before you approve it and trigger payment.

Vague: "User authentication will be implemented."

Specific: "Users can register with email/password, receive a verification email, log in, reset their password via email, and be blocked after 5 failed login attempts. All flows work on Chrome, Firefox, Safari, and mobile web."

If your contract doesn't define acceptance criteria per milestone, add them in a project specification appendix. Reference the appendix in the contract. Make it binding.

What to Push Back On

Unlimited Revision Clauses (Or No Revision Limits)

Some contracts offer "unlimited revisions" as a selling point. What they actually mean is "unlimited minor revisions at our discretion." What you're risking is a dev shop that calls every scope change a "major revision" requiring a new quote.

Get clarity in writing: what constitutes a revision vs. new scope? How many revision rounds are included per milestone? What's the rate for out-of-scope requests?

Vague Deliverable Definitions

If the contract says "we'll build your MVP," that's not a deliverable — that's a vibe. Every contract should be backed by a detailed specification that lists features, platforms, integrations, and performance expectations.

No spec = no accountability. Don't sign until the spec is attached.

"Time and Materials" With No Cap

T&M billing isn't inherently bad. But T&M with no cap means you're writing a blank check. Costs can spiral and you have no contractual protection.

If you accept T&M, push for a monthly or total project cap. Something like: "T&M billing not to exceed $X per month / $Y for the full project without written authorization from [Your Name]."

Red Flags in Contracts

These aren't just things to negotiate — they're reasons to walk away and find a different vendor:

No liability cap at all. The contract should cap the vendor's liability at some amount (even if low). A contract with zero liability mention means you have no idea what you can recover if things go badly.

Unsigned NDA. If they sent you detailed IP and won't sign a mutual NDA before you share your specs, that's a character signal, not just a legal one.

Jurisdiction far from you with no negotiation. A dev shop in California insisting all disputes be resolved in their state, under their laws, with their preferred arbitration firm — for a client in Vietnam or New York — is structuring the agreement so litigation is practically impossible for you.

Payment on invoice rather than milestone. "Net 30 from invoice" means they invoice whenever they want and you have 30 days to pay. Without milestone gates, you lose payment leverage entirely.

No warranty period. Software breaks after launch. A short warranty period (typically 30–90 days) where the vendor fixes bugs at no charge is standard. No warranty clause means every post-launch fix is billable.

The Milestone Payment Structure That Reduces Your Risk

Here's a framework that balances the vendor's need for cash flow with your need for accountability:

Milestone	Payment	Trigger
Kickoff / Setup	10–15%	Signed contract, project kickoff
Design approval	10–15%	Wireframes + visual design approved
Core feature delivery	25–30%	Primary features pass acceptance criteria
Full build delivery	25–30%	All features pass acceptance criteria
Launch + warranty start	15–20%	Deployed to production, warranty period begins

This structure means you never pay more than 15–30% ahead of proven delivery. It keeps the vendor motivated (they need the next payment) and gives you real leverage at every stage.

Adjust percentages based on project size, but keep the structure: small upfront, meaningful milestone gates, payment on acceptance — not on invoice.

When to Get a Lawyer (and When a Template Is Enough)

Use a template when:

Project budget is under $20K
You're working with a freelancer, not an agency
The vendor is flexible and you're just adding standard protections
You've worked with this vendor before

Good starting points: Clerky, Bonterms (open source SaaS contracts), or a lawyer-reviewed template from your network.

Hire a lawyer when:

Budget is $50K or more
The vendor's contract is complex or aggressive
IP is central to your business (custom algorithms, proprietary data models)
International jurisdiction issues apply
There's significant ambiguity in what's being built

A startup attorney for a contract review typically costs $500–$1,500. On a $100K project, that's a rounding error — and it changes the negotiation dynamic. The vendor knows you're serious.

The Bottom Line

You're not being paranoid by reading the contract carefully. You're being professional.

Dev shops deal with contracts every week. Most founders do it once or twice per year at most. That asymmetry means the standard contract leans their way. Your job is to rebalance it.

The five things that matter most: IP assignment, milestone payments, kill clause, source code escrow, acceptance criteria. Get those right, and you've reduced your risk by 80%.

If you want to work with a team that builds these protections in from the start — clear milestones, weekly code commits, defined acceptance criteria — talk to us at VL Studio. We work the way a good contract says you should.