Contract terms every founder should require from a dev agency

What a Software Development Agreement Actually Does

A software development agreement is a contract between you and the agency that defines the software to be built, the timeline, the payment structure, and the legal terms, including who owns the resulting code. It turns a project brief into an enforceable deal with clear scope, acceptance criteria, and remedies if either side fails to perform. The agreement does three jobs at once: it defines the work so both sides share a single definition of done, it ties money to milestones, and it settles ownership and risk before any code is written. Skipping the third job is what turns a successful build into a legal fight. The contract matters most for custom builds, milestone projects, anything involving sensitive data or valuable IP, and any engagement large enough that you would want to enforce it.

For repeat engagements with the same agency, a Master Services Agreement paired with individual Statements of Work is often the cleaner structure. The MSA sets the default rules on confidentiality, IP, liability, invoicing, and termination. Each SOW works as a project-specific blueprint, specifying what a given phase includes, what it excludes, the timeline, and the payment triggers. For a one-off project, a standalone agreement can be enough. For ongoing work, negotiating the heavy legal terms once and launching new phases under shorter project documents saves time and reduces friction.

Common Problems Founders Face Without the Right Contract

The legal gaps that cost founders the most tend to cluster around the same handful of issues. Understanding them before you negotiate is the first step toward fixing them.

Scope That Expands Without a Paper Trail: Agencies describe this pattern accurately. It starts with one extra integration, one dashboard adjustment, one mobile optimization that seems simple. Then the contract problem becomes a budget problem. Without a written change-control process, every informal request is an unpriced commitment, and the dispute over what was included begins.

Paying for Hours Rather Than Outcomes: Agencies prefer time-and-materials billing because it shifts the risk of underestimation onto you. You pay for effort regardless of whether the result works. Without milestone-tied payment and a defined acceptance process, you have limited leverage to withhold payment if deliverables fall short.

Assuming You Own the Code Because You Paid for It: This is the single most expensive misunderstanding in software contracts. Under U.S. copyright law, paying for the work does not transfer ownership. Code written by an independent contractor belongs to the contractor by default. The work-made-for-hire doctrine that applies to employees does not apply to independent contractors for software. A written IP assignment, signed before work begins, is the only way to ensure you own what gets built.

Accepting Software Without Defined Criteria for Done: If the contract does not define acceptance criteria, then done means whatever each side wants it to mean. The agency presents a deliverable, calls it complete, and issues an invoice. You disagree. Without objective criteria written into the contract, you have no contractual mechanism to reject what was delivered.

Inheriting Open Source Licensing Obligations You Did Not Know About: Agencies routinely incorporate open source libraries and frameworks. Some of those licenses impose obligations on you as the downstream user, including requirements to publish your own source code if you distribute the software. If the contract does not require the agency to disclose what open source components they use and to warrant license compatibility with your intended use, you may not find out until an investor's due diligence process raises the flag.

These problems are predictable and preventable. The clause-by-clause sections below address each one directly.

What to Require in Each Clause

Scope and Statement of Work

The Statement of Work is the most important document in the engagement. Vague language like build a mobile app or develop a website is a red flag. It creates disputes when your expectations do not match what the agency delivers. A properly written SOW names specific features, functional requirements, supported platforms and versions, performance benchmarks, integration points, and explicit exclusions. If it is not written down in the SOW, assume it is out of scope.

What agency paper typically says: A general description of the project, often copied from your brief, with output-neutral language that gives the agency maximum flexibility on what they deliver and how.

Where you push: Attach a detailed SOW as an exhibit, written by you or reviewed by your counsel. Define features with enough specificity that a third-party engineer could read it and know what done means. List exclusions explicitly so there is no ambiguity about what is not included. If the agency wants to start before the SOW is final, that is a warning sign, not a compromise.

Change Control

Change control is how you prevent the informal scope creep that derails most software projects. A change order process requires written approval from both parties before any additional work begins, along with adjustments to pricing and timelines. Without it, every conversation about a new feature is a potential unpriced commitment.

What agency paper typically says: Changes are approved verbally or by email, with pricing discussed after the work is underway. This gives the agency significant leverage once development has started.

Where you push: Require that all changes to scope, timeline, or price be documented in a signed change order before work on the change begins. No written change order, no obligation to pay for it. This is a standard ask that reasonable agencies accept without objection.

Payment Structure

Payment structure is your primary risk management tool. The core problem is that you usually cannot verify whether an agency can build what you need until they have already started. That makes payment design consequential. Agency paper tends to favor front-loading payment and tying invoices to time spent rather than outcomes delivered.

What agency paper typically says: A significant deposit before work begins, often 30 to 50% of the total, followed by monthly invoices for hours logged, with final payment due on delivery rather than on accepted delivery.

Where you push: The goal is payment against accepted deliverables, not payment against effort. The standard market structure for milestone-based development projects is roughly 20 to 30% upfront to cover discovery, setup, and demonstrate commitment, 40 to 50% in two or three milestone payments tied to completed and accepted features, and 20 to 30% upon final delivery and acceptance. Avoid 100% upfront, which gives the agency no financial incentive to finish. Avoid pure time-and-materials billing without a cap, which creates budget uncertainty and removes all delivery risk from the agency.

A holdback on the final milestone is underused but effective. Holding back 5 to 10% of the total contract value until a defined post-deployment warranty period expires, typically 30 to 90 days, keeps the agency financially engaged during the period when bugs are most likely to surface. The agency has real money on the table, which incentivizes prompt fixes.

Require written pre-approval for all reimbursable expenses. Without this, travel, software licenses, and third-party service costs can arrive on an invoice with no prior authorization.

Be straight about the trade-off. An agency asked to carry significant payment risk will price higher or walk. Milestone payment with acceptance gating is worth the leverage spend. A holdback is usually accepted by established agencies. Trying to get to zero prepayment on a new relationship is the ask most likely to stall negotiations without meaningful return.

Good milestone language ties payment to artifacts and events, not labels. Approved wireframes, completed API integration, deployment to staging, passed test scripts, and production release are all concrete. Design complete and beta delivered are too soft unless the contract defines exactly what those terms mean.

Acceptance Testing

Acceptance testing is how you determine whether a deliverable actually meets the requirements before you pay for it. Without defined acceptance criteria, done is whatever each side wants it to mean, and disputes follow.

What agency paper typically says: A short review window, often five to ten business days, after which a deliverable is deemed accepted regardless of whether you have tested it. The agency invoices on deemed acceptance.

Where you push: Define acceptance criteria in the SOW, not in the body of the agreement. Name who performs testing, what constitutes a defect, how defects are categorized by severity, and what the agency's cure period looks like for each severity level. Specify the number of revision rounds included and what happens if a deliverable still fails after revisions. Escalation should lead to mediation or termination for cause, not to deemed acceptance by default. The agreement should give you the right to terminate and get a refund of payments for unaccepted work if the agency cannot cure material defects after a defined number of attempts.

IP Assignment

This is the clause that determines whether you actually own the software you paid to build. Under U.S. copyright law, code written by an independent contractor belongs to the contractor by default. Payment alone does not transfer ownership. The work-made-for-hire doctrine that applies to employees does not apply to independent contractors for software, and software is not one of the nine statutory categories that can be designated as work-for-hire by written agreement. A work-made-for-hire label in the contract does not reliably transfer contractor-written code. An express assignment does.

What agency paper typically says: IP transfers on full and final payment, with work-made-for-hire language that sounds complete but is not legally sufficient on its own. Some agency agreements assign only the final deliverable and retain rights to underlying tools and components without disclosing what those are.

Where you push: Require an express assignment clause under which the agency assigns all right, title, and interest in all deliverables created specifically for your project, including source code, object code, documentation, databases, designs, and APIs. The assignment should be effective upon each milestone payment, not only upon receipt of the final payment. This way, if the relationship ends early, you own what you paid for up to that point.

Also require the agency to represent and warrant that it has clean rights from every contributor, including subcontractors, offshore team members, and any individual who touched the codebase. A surprising number of ownership problems stem not from the lead developer but from contributors whose own assignment obligations were never documented. If the agency does not have clean rights from every contributor, it has nothing clean to assign to you.

On AI-assisted code: require the contract to address this explicitly. The agency should warrant that it is responsible for all code it delivers, regardless of the tools used to generate it, and that AI-assisted code does not introduce third-party claims or unresolvable ownership ambiguity.

Background IP

Background IP refers to tools, libraries, frameworks, and code that the agency developed before your engagement or uses across multiple clients. This is distinct from the custom work product created specifically for you. The agency will not and should not assign you its pre-existing tooling. The question is whether you get a sufficient license to use it inside your product.

What agency paper typically says: The agency retains all pre-existing IP. The license grant to you may be narrow or conditional, and the contract may not describe what background IP is actually included in the deliverables.

Where you push: Require the agency to list all material background IP in an exhibit before the engagement begins. For each item, the contract should grant you a license that is broad enough to use, modify, and commercialize the deliverables for your intended purpose. If the agency's background IP is deeply embedded in the core functionality of your product, you face a dependency risk. Surface that dependency before you sign, not after launch.

Confidentiality

You will share sensitive business information, technical specifications, user data, and strategic plans during a development engagement. The confidentiality clause is what makes that sharing legally protected.

What agency paper typically says: Standard NDA boilerplate that covers information shared during the engagement and expires within one to two years.

Where you push: The confidentiality obligation should cover all information shared in connection with the engagement, including source code, product specs, user data, and business plans. It should survive termination of the agreement, not expire on a fixed date. Require the agency to ensure that subcontractors and offshore team members are bound by equivalent obligations. Sensitive data shared during the engagement should be returned or destroyed within a defined period upon project completion or termination.

Warranty

A software warranty is the agency's promise that the delivered software will conform to the agreed specifications for a defined period after acceptance. Without it, the agency's obligation to fix bugs ends at the moment you accept the deliverable.

What agency paper typically says: A short warranty window, often 30 days, covering only defects that existed at the time of delivery and excluding anything touched by your team after delivery. Some agency agreements disclaim all implied warranties, which means you receive the software effectively as-is.

Where you push: A 60 to 90 day post-acceptance warranty is a reasonable ask on most engagements. The warranty should specify that the software will conform to the specifications in the SOW, that the agency will fix bugs at no additional charge during the warranty period, and that the warranty is not voided by minor configuration or content changes you make after delivery. Avoid accepting software with a total disclaimer of implied warranties unless the warranty term and scope are strong enough to compensate. The holdback structure described in the payment section works in parallel with the warranty to keep the agency engaged.

Limitation of Liability

Most development agreements cap each party's liability at the total fees paid under the contract and exclude consequential damages such as lost profits or business interruption. Some cap is standard and reasonable. The question is whether the cap applies to everything or whether specific categories of harm are carved out.

What agency paper typically says: Liability is capped at contract fees paid, with a broad exclusion of consequential, indirect, incidental, and special damages. This cap often applies to IP infringement and confidentiality breaches, which are the two categories most likely to cause you outsized harm.

Where you push: The dollar cap on direct damages is generally not worth fighting. What is worth pushing on is carving IP indemnification and confidentiality breaches out from the cap and the consequential damages exclusion. If the agency's deliverable infringes a third party's patent and you face a lawsuit, the harm will likely exceed any fee cap. If the agency leaks your trade secrets, the same is true. These are the carve-outs that matter. Be realistic about leverage: most agencies will resist removing the cap on consequential damages entirely. A negotiated carve-out for IP and confidentiality is a more achievable and more useful outcome.

Open Source

Open source components are present in virtually every modern software build. Some open source licenses are permissive and impose minimal obligations. Others, particularly copyleft licenses, impose significant restrictions, including requirements to publish your own source code if you distribute the software. Not knowing what is in your codebase is not a defensible position with investors or acquirers.

What agency paper typically says: Generic language acknowledging that open source may be used, with no disclosure schedule and no warranty of license compatibility.

Where you push: Require a complete disclosure schedule listing all open source and third-party components used in the deliverables, with the specific license applicable to each. Require the agency to warrant that all open source licenses are compatible with your intended commercial use. If you plan to embed the software in a commercial product for distribution or resale, this compatibility warranty matters significantly more than it would for an internal tool. For copyleft components specifically, consider requiring the agency to warrant that no copyleft license will require you to disclose your own proprietary source code as a condition of distribution. This is a technical ask that experienced agencies understand and should be able to address.

Termination

Termination clauses govern how either party exits the engagement and what happens to deliverables, payments, and IP when they do.

What agency paper typically says: Termination for convenience by either party on 30 days notice, with the agency entitled to payment for all work performed through the notice period and a kill fee that may be calculated on the remaining contract value. IP transfer on partial work is often undefined.

Where you push: You want two distinct termination rights. Termination for cause, which is triggered by material breach and should allow immediate exit after a defined cure period, typically 10 to 14 days. And termination for convenience, which is the right to exit on reasonable notice without a cause requirement, typically 30 days. On termination for cause, you should owe nothing for unaccepted work. On termination for convenience, payment for completed and accepted milestones is fair; a kill fee calculated on unstarted work is not.

Critically, the termination clause should specify that all work product created and paid for to date transfers to you immediately on termination. The agency should be obligated to deliver all source code, documentation, credentials, and access in a usable form within a defined period. Confidentiality obligations should survive termination. So should the agency's IP warranty obligations on work already delivered.

Best Practices for Structuring the Engagement

The contract is necessary but not sufficient. How you structure the engagement around the contract matters just as much.

Define the SOW Before Signing, Not After: Agencies sometimes want to begin immediately and finalize the SOW later. Resist this. The SOW is the operational document for the project. If it is not complete at signing, you do not yet have an agreement on what you are buying.

Tie Every Milestone Payment to a Testable Deliverable: Milestone labels like design complete or backend done are too soft. Every payment trigger should reference a concrete artifact or event: approved wireframes in Figma, API integration documented and passing tests, staging environment live, production release deployed. Vague milestones like substantial progress create the exact disputes that milestone payment is supposed to prevent.

Run Acceptance Testing Seriously: Acceptance is not a formality. Use the window. Test against the criteria in the SOW. Document defects in writing. If you accept a deliverable without testing it, you lose the contractual leverage to reject it later. Deemed acceptance on an untested deliverable is one of the most common and most expensive mistakes founders make.

Document Every Material Communication in Writing: Text messages and voice notes do not amend a contract. If the agency agrees to a timeline extension, a scope change, or a revised acceptance criterion, put it in a signed change order. The contract should be the single authoritative record of what both parties agreed to do.

Require the Agency to Identify Subcontractors: Many agencies use subcontractors or offshore contributors. You need to know who is touching your codebase. Require the contract to name key personnel, restrict substitution without your consent, and confirm that all contributors have signed IP assignment and confidentiality agreements with the agency that flow through to your benefit.

Get Source Code Access Throughout the Engagement: Do not wait until project completion to receive source code. Require access to the repository from the start of development. This gives you visibility into progress, protects you against sudden agency unavailability, and ensures you are not locked out if the relationship ends early.

Address Post-Launch Support Before You Sign: Many agencies offer a limited warranty period followed by optional paid maintenance agreements. The transition from warranty to paid support should be defined in the contract before signing, not negotiated after launch when bugs are live in production and you have no leverage.

The Future of Dev Agency Contracts

The structure of a sound development agreement has not changed fundamentally, but two trends are reshaping what the clauses need to address. AI-assisted code generation is now standard practice at most agencies. That means the IP assignment and warranty clauses need to address AI-generated code explicitly, including who owns it, who is responsible for its quality, and what happens if it introduces third-party claims. Open source obligations are also becoming more complex as agencies incorporate more third-party components and AI tooling with its own licensing terms.

The other trend is increasing use of distributed and offshore development teams, which makes subcontractor assignment obligations and contributor IP chains more important and harder to verify. A contract that does not address these realities is already behind.

For founders building in 2026, the right move is to treat the development agreement as a living document that reflects the actual structure of the engagement, including who is building the code, what tools they are using, and what your rights look like at every stage of the project. Story.law builds these agreements for founders every day. If you are about to sign a dev agency contract or receive one that needs review, contact our team or start a conversation through Aegis to get legal eyes on it before you commit.

FAQs About Dev Agency Contracts for Founders

• What should be in a contract when hiring a software development agency?

  A software development agreement should define the scope of work in a detailed Statement of Work, specify milestone-based payment tied to accepted deliverables, include an express IP assignment clause that transfers ownership of all custom work product to you, define acceptance testing criteria and cure periods, address confidentiality, warranty, limitation of liability, open source disclosure, and termination rights. Story.law recommends treating each of these clauses as a negotiation point, not a formality, particularly the IP assignment, payment structure, and acceptance provisions.

• Should I use my own contract or the agency’s when hiring developers?

  You should start from your own contract whenever the engagement involves significant fees or core product IP. Agency paper is drafted to protect the agency’s interests. Starting from your own paper means the default positions on IP, payment, acceptance, and termination reflect your interests, and the agency marks up your baseline rather than defending their own. Story.law drafts buyer-side development agreements for founders and can review agency paper when you receive it, flagging the provisions that need to move before you sign.

• How much should I pay a development agency upfront?

  A reasonable upfront payment for a development engagement is 20 to 30% of the total contract value, covering discovery, setup, and initial work. The remaining amount should be released against accepted milestones, with a 5 to 10% holdback on the final payment released after a post-deployment warranty period of 30 to 90 days. Paying 100% upfront removes your leverage entirely. Paying only at the end puts unfair cash flow pressure on the agency and tends to inflate pricing. Story.law advises founders to treat the payment structure as the primary risk management tool in the contract.

• What happens if a development agency doesn't deliver?

  If your contract includes well-drafted acceptance criteria, a cure period, and a termination-for-cause provision, you have contractual remedies. You can reject deliverables that do not meet the acceptance criteria, require the agency to cure within a defined window, and terminate the agreement for cause if they cannot. On termination, you are entitled to all work product created and paid for to date. Without these provisions, your remedies are limited to breach of contract litigation on vague terms, which is expensive and uncertain. Story.law structures termination and acceptance clauses specifically to give founders meaningful remedies without requiring litigation to enforce them.

• What is the difference between IP assignment and work-made-for-hire in a software contract?

  Work-made-for-hire is a doctrine that automatically assigns copyright to the hiring party, but it applies to employees, not independent contractors, and software is not one of the nine statutory categories that can be designated as work-for-hire by written agreement. Relying on a work-made-for-hire label in an agency contract does not reliably transfer ownership of the code. An express assignment clause, in which the agency assigns all right, title, and interest in the deliverables to you, is the legally reliable mechanism. Story.law includes express assignment language as a baseline requirement in every development agreement it drafts for founders.

• Why does background IP matter in a dev agency contract?

  Background IP refers to tools, libraries, and code that the agency developed before your engagement or uses across multiple client projects. The agency will not assign you their pre-existing tooling, which is reasonable. But if background IP is embedded in your product’s core functionality, you need a license to use, modify, and commercialize it. Without a defined license, you may discover after launch that your product depends on IP you do not own and cannot use freely. Story.law requires agencies to disclose background IP in a schedule at the start of the engagement and to grant a sufficient license to cover your intended use.

• What open source risks should I address in a development agreement?

  Open source components are standard in modern software, but some licenses impose material obligations. Copyleft licenses in particular may require you to publish your own source code if you distribute the software. Your contract should require the agency to provide a complete disclosure schedule of all open source and third-party components and to warrant that all licenses are compatible with your intended commercial use. For software embedded in a commercial product for distribution or resale, this compatibility warranty is essential. Story.law addresses open source disclosure and warranty as a standard clause in development agreements for product companies.