Software Agency Proposal Teardown: 12 Clauses That Change Price, Scope and Ownership

To review a software development proposal properly, ignore the polish for ten minutes. Read it as a map of who pays when an assumption breaks, who decides whether the work is finished, and who can operate the product after the agency leaves. The headline fee is only comparable after those three questions have answers.

Below is a clause-by-clause teardown of a fictional composite proposal: a EUR 96,000, sixteen-week build for a B2B customer portal. No real agency or client is represented. The weak language is assembled from recurring proposal patterns, then rewritten as instructions a buyer can take to technical counsel. This is a commercial and technical review, not legal advice; contract language and remedies must be adapted to the governing law.

How do you review a software development proposal?

Use four passes. First, confirm the proposal describes the same product you asked for. Second, test each clause for an owner, evidence, a date and a consequence. Third, add excluded and recurring costs back into the quote. Fourth, let the right specialists review the result: a senior engineer for feasibility and operational risk, security or privacy specialists where the data demands it, and a lawyer for enforceability.

1. Collect the whole contract stack. Proposal, Statement of Work (SoW), master services agreement, data-processing agreement, rate card and every referenced schedule. A promise in a sales deck does not repair a contradictory contract.
2. Search for elastic words. "Reasonable", "standard", "material", "substantially", "as needed", "industry best practice" and "timely" all need a test or a named decision-maker.
3. Score the twelve clauses. Zero means missing, one means present but subjective, two means testable and allocated. Do not average away a hard-stop ownership or security gap.
4. Normalise the price. Add exclusions, recurring services, required client labour and exit costs. Compare like with like.

If you are still deciding which company deserves the work, start with our guide to choosing a software agency. This teardown begins one step later: an agency is shortlisted, a document is on your desk, and you need to understand what it actually buys.

The fictional proposal in one page

The fee may be fair. The problem is that the document cannot yet prove it. Here are the twelve clauses that decide.

The 12-clause software contract scope checklist

1. Acceptance criteria: can you prove the deliverable passed?

Proposal says: "The client will review each milestone and provide approval within five business days. Approval will not be unreasonably withheld."

Why it is a red flag: The clause has a clock but no test. If the portal displays a dashboard while its reports are wrong under production data, the agency can argue the milestone exists and the client is withholding approval. The buyer can argue the feature is unusable. Both are negotiating from adjectives.

Redline instruction: Attach acceptance criteria to every payment-bearing deliverable. Name the test data, environment, supported roles, expected result and non-functional floor. Define the UAT window, how defects are recorded, what counts as material, the cure and retest cycle, and whether payment follows acceptance or merely submission. The UK government's model-services guidance treats the acceptance criteria, test strategy and implementation plan as documents to agree before signature for exactly this reason.

Better commercial wording: "Milestone 2 is ready for acceptance when the three named user roles can complete workflows A-C in the staging environment against dataset D, automated tests pass, and the performance and security gates in Schedule 4 are met." Your lawyer can turn that instruction into the right clause.

2. IP ownership: do you own enough to use, change and sell the product?

Proposal says: "Upon final payment, the client owns all final deliverables. The agency retains its tools, know-how and reusable components."

Why it is a red flag: "Final deliverables" could mean a deployed binary and some screens. "Reusable components" could swallow the framework-specific code that makes the product work. Ownership also does not materialise by assumption: the agreement must distinguish client materials, pre-existing agency IP, newly created project IP and third-party components, then say which rights transfer or are licensed.

Redline instruction: Define the foreground IP created for the project and the full artifact set: source code and history, designs, documentation, schemas, infrastructure code, tests and build configuration. State when rights transfer, whether they are exclusive, and the buyer's rights to use, modify, host, assign and sublicense. List background IP and give a durable licence broad enough to operate the product. Require the agency to obtain matching rights from every employee and subcontractor. The European IP Helpdesk's assignment checklist makes the same separation between the property transferred, warranties, payment and future obligations.

Hard stop: Do not sign while the agency can repossess a component that the product cannot run without, or while a subcontractor may own code the agency promises to transfer.

3. Change requests: who decides whether new work is really new?

Proposal says: "Requests outside the agreed scope will be billed at EUR 1,200 per day. The agency will notify the client where a request may affect timeline or budget."

Why it is a red flag: The rate is clear; the boundary and approval are not. An agency could label correction of a missed requirement as a change. A well-meaning product owner could approve work in Slack without seeing its cumulative effect on price and launch.

Redline instruction: Require a written change request that describes the requested change, why it is outside the baseline, price, schedule effect, dependencies and any acceptance-criteria changes. Nobody starts it until named representatives approve it. State that remedying a failure against the signed scope or acceptance criteria is defect correction, not chargeable change. Keep a versioned scope baseline.

If you need to decide which commercial model should carry that risk, the separate fixed price versus time-and-materials guide owns that question. This page assumes the model is chosen and checks whether its change mechanism is usable.

4. Warranty: what gets fixed after acceptance, and how quickly?

Proposal says: "The agency provides a 90-day warranty and will correct bugs at no additional cost. Enhancements are excluded."

Why it is a red flag: A duration without a defect definition, severity, response target or remedy is a promise to discuss the problem later. "Bug" and "enhancement" become the same argument as scope versus change. It is also unclear whether the clock starts per milestone, on launch or on final acceptance.

Redline instruction: Tie a defect to failure against the specification, acceptance criteria or agreed security requirements. Name when the warranty begins, severity categories, response and remediation targets, retesting, and what happens when a critical defect cannot be fixed promptly. Separate warranty correction from ongoing maintenance and exclude only clearly named causes such as unauthorised client changes.

Buyer check: Ask for one example each of a warranty defect, a maintenance task and a new feature. If the agency cannot classify the examples consistently, the clause is not operational.

5. Dependencies: which client delay moves which agency date?

Proposal says: "The timeline assumes timely access, feedback and decisions from the client. Delays may extend delivery dates and incur additional costs."

Why it is a red flag: Every real project has client dependencies. This clause names none of them and gives every delay the same unlimited consequence. A one-day delay providing a logo should not automatically move a database migration on the critical path.

Redline instruction: Add a responsibility matrix with the artifact or decision, owner, due date, minimum usable format and the milestone it blocks. Require prompt written notice when a dependency is at risk, reasonable mitigation, and a documented schedule impact limited to the affected critical path. Price standby or restart costs in advance where they are genuinely possible.

Green flag: The agency names the uncomfortable client work before the project starts: domain-expert time, data cleanup, legal approvals, account access and acceptance owners. That is planning, not pessimism.

6. Hosting: whose account keeps the product alive?

Proposal says: "The solution will be deployed to a modern cloud environment managed by the agency. Hosting is billed monthly based on usage."

Why it is a red flag: The buyer has no provider, region, service list, expected range, billing model or exit path. If production lives in the agency's master account, leaving the agency can become an infrastructure migration. That is a hidden termination fee.

Redline instruction: Put production cloud, domain, DNS, email, app-store and observability accounts in a client-owned organisation wherever practical. Name the environment, region, services, cost assumptions, budget alerts, backups, restore tests, monitoring and support boundary. Deliver infrastructure as code. Agency access should be named, least-privilege and revocable. If an agency-owned account is temporarily necessary, price and test the migration path before launch.

Comparable-price rule: Add twelve months of realistic hosting, monitoring and support to the bid. "Usage based" is not zero.

7. Third-party licences: what else must you pay for or comply with?

Proposal says: "The agency may use industry-standard open-source and commercial components to accelerate delivery."

Why it is a red flag: Open source is often the right choice, but licences carry conditions and commercial services renew. The buyer needs to know whether a component affects distribution, source disclosure, field of use, seat count, transaction cost or the right to transfer the product.

Redline instruction: Require a component register or software bill of materials with version, source, licence and known recurring fee. Pre-approve components with restrictive obligations or material switching cost. Require direct or transferable commercial licences where needed, plus vulnerability and licence checks at handover. The European Commission's ICT IP clauses require a list of open-source components and their licence terms, and prior approval where licence conditions could restrict distribution or require source disclosure.

Hard stop: A core service licensed only to the agency, with no direct client right and no practical replacement, is vendor lock-in even if the custom code transfers cleanly.

8. Handover: could a competent replacement team deploy next week?

Proposal says: "At project completion the agency will provide source code and reasonable documentation."

Why it is a red flag: A repository snapshot is not a handover. Without build history, CI/CD, infrastructure, credentials, data model, runbooks and open-issue context, the next team pays to rediscover the system. "Reasonable documentation" cannot be accepted because nobody has named the reader or the task it must enable.

Redline instruction: List the artifacts: client-owned repository with history; build and deploy pipeline; infrastructure as code; architecture and data-flow diagrams; schema and migration history; automated tests; admin and support runbooks; backup and restore steps; credential and account inventory; dependency and licence register; known issues and decisions; training sessions and recordings. Make a clean deployment or restore by the client or a replacement engineer part of handover acceptance.

The full operational artifact list lives in the software handover checklist. The contract should point to a similarly explicit schedule, not a promise to document later.

9. Termination: what do you receive if the project stops in week nine?

Proposal says: "Either party may terminate on 30 days' written notice. Fees paid are non-refundable and all outstanding invoices become due."

Why it is a red flag: The clause explains how notice works, not how the product exits. It says nothing about work in progress, partially completed milestones, data export, access, transition help, deletion, licences or whether the client must pay for work that has not met acceptance.

Redline instruction: Separate termination for convenience, uncured breach and insolvency. Define payment for accepted work, treatment of work in progress, the artifact and data package delivered, the deadline for transfer, credential rotation, deletion evidence, continuing licences, and a capped transition-assistance rate. State which IP, confidentiality, warranty, data-protection and payment provisions survive. The UK model contract uses a dedicated exit-management schedule because an orderly transition is a delivery obligation of its own.

Exit test: Ask, "If we stop after the next milestone, what exact files, accounts, rights and help arrive within ten business days, and what do we owe?" The answer should fit in a table.

10. Security obligations: which controls and evidence are part of scope?

Proposal says: "The agency follows industry best practices for security and data protection."

Why it is a red flag: There is no single set of industry best practices, no verification level and no evidence. The phrase cannot tell the buyer whether threat modelling, access-control tests, dependency scanning, secrets management, incident notification or a penetration test are included in the price.

Redline instruction: Start with data classification and a responsibility matrix. Name a baseline and version, such as an agreed subset or level of OWASP ASVS for a web application, and use NIST SSDF to describe secure-development responsibilities. Specify threat modelling, code review, scanning, security testing, remediation, secrets, encryption, logging, incident notice, evidence and any independent assessment. If personal data is processed, the DPA must cover documented instructions, confidentiality, security measures, assistance and subprocessors under GDPR Article 28.

Scope warning: "Pen test ready" is not a penetration test. "GDPR compliant" is not a list of processing instructions. Name the artifact and who pays for it.

11. Subcontractors: who is actually building and who can access the data?

Proposal says: "The agency may engage qualified specialists as needed and remains responsible for delivery."

Why it is a red flag: Commercial responsibility is useful but incomplete. The buyer does not know which work is subcontracted, where it happens, whether personal data is accessed, whether the same confidentiality and security terms flow down, or whether the agency owns the subcontractor's output well enough to transfer it.

Redline instruction: Disclose material subcontractors, role, location and system or data access. Require notice and a meaningful objection or approval process for changes where risk warrants it. Flow down confidentiality, security, data protection, audit and IP-assignment obligations. Keep the agency accountable for the work and make removal or replacement mechanics explicit. The European Commission's GDPR guidance is direct: a processor cannot appoint another processor without prior specific or general written authorisation.

Buyer distinction: A specialist named early to solve a known problem is a green flag. An invisible bench used to replace the seniors who sold the project is a delivery risk.

12. Definition of done: what quality work is included before acceptance?

Proposal says: "A feature is complete when substantially implemented and demonstrated to the client."

Why it is a red flag: A demo proves the happy path once. It does not prove code review, automated tests, accessibility, security, documentation, deployment, observability or cleanup happened. Those tasks can later reappear as "hardening" outside the fixed price.

Redline instruction: Define done at the engineering level: code reviewed and merged; agreed automated tests passing; acceptance criteria met; security checks clear; accessibility and supported-browser checks complete where applicable; documentation updated; deployed to the named environment; monitoring and error handling active; no blocker defects open. Version the definition and state who approves changes to it.

The official Scrum Guide attaches the Definition of Done to the Increment as a quality commitment. Use that idea even if the project is not Scrum: "done" describes the quality state of the work, not the agency's confidence during a demo.

"The price in a software proposal is not one number. It is the headline fee plus every ambiguity the buyer will have to fund later. Good clauses do not make the relationship adversarial. They stop ordinary uncertainty from becoming a negotiation under pressure."

Acceptance criteria, definition of done and handover are not the same

Collapsing all three into "client sign-off" is one of the most expensive software agency proposal red flags. A feature can pass its business test while the code is unmaintainable. A clean codebase can exist while the client still cannot deploy it. Test the three states separately.

How to compare the real price of two agency proposals

Use a first-year comparable price, not the quoted build fee:

Comparable price = build fee + excluded required work + first-year recurring cost + valued client workload + expected exit work.

These are invented figures for the fictional proposal, not Wavect price benchmarks. The point is the method: a lower bid can be more expensive when it moves mandatory work outside the border. Ask each agency to fill the same inclusion matrix, then compare.

How to score the proposal: 0, 1 or 2 points per clause

• 0 - missing. The proposal does not address the clause, or a referenced schedule was not provided.
• 1 - subjective. The clause exists but relies on "reasonable", "standard", "timely" or another judgment with no owner, test or consequence.
• 2 - operational. It names the owner, artifact or test, timing, dependencies and what happens when the condition is not met.

Regardless of total, stop if the IP chain is unclear, personal-data processing has no workable security and processor terms, core hosting or licences cannot transfer, or termination leaves you without code and data. A score is a triage tool, not a way to trade away a fatal clause.

Download the printable 24-point software agency proposal review rubric. It includes the scorecard, hard-stop gates, comparable-price worksheet and the twelve redline questions.

What should happen after the teardown?

1. Send the agency one consolidated redline brief, not twelve disconnected email threads.
2. Ask them to explain every exclusion and assumption in a working session with the person who will lead delivery.
3. Update the SoW and schedules. Meeting notes are not the contract.
4. Have a senior technical reviewer test feasibility, dependencies, security scope and handover.
5. Have qualified counsel adapt and review the legal language for your jurisdiction and risk.

A good agency should welcome most of these questions. Precise boundaries protect its margin as much as your budget. Resistance to all detail is the signal; disagreement on a specific, reasoned allocation is negotiation.

Sources and further reading

1. UK Cabinet Office (2025), Model Services Contract guidance, version 2.2. Acceptance, testing, intellectual property, change control and exit-management guidance. Available at: gov.uk (Accessed: 13 July 2026).
2. European Commission (2021), Additional IP clauses for ICT contracts. Commissioned source code, object code and documentation; open-source approval and component-list requirements. Available at: commission.europa.eu (Accessed: 13 July 2026).
3. European IP Helpdesk, Frequently asked questions on IP assignment and licences. Assignment scope, warranties, indemnification and sublicensing. Available at: intellectual-property-helpdesk.ec.europa.eu (Accessed: 13 July 2026).
4. European Commission, Can someone else process data on my organisation's behalf? Processor guarantees, written authorisation for another processor and minimum contract content under GDPR Article 28. Available at: commission.europa.eu (Accessed: 13 July 2026).
5. NIST (2022), Secure Software Development Framework, SP 800-218 v1.1. A common vocabulary for security requirements and supplier acquisition. Available at: csrc.nist.gov (Accessed: 13 July 2026).
6. OWASP, Application Security Verification Standard v5.0.0. A testable security baseline designed for use in procurement and contracts. Available at: owasp.org (Accessed: 13 July 2026).
7. OWASP, Secure Software Contract Annex. Negotiation prompts for security requirements, verification, reporting and secure deployment. Available at: owasp.org (Accessed: 13 July 2026).
8. WIPO GREEN (2016), Licensing Checklist. Development-agreement prompts covering SoWs, deliverables, specifications, testing, acceptance and foreground/background IP. Available at: wipo.int (Accessed: 13 July 2026).
9. Schwaber, K. and Sutherland, J. (2020), The Scrum Guide. The Definition of Done as the commitment attached to an Increment. Available at: scrumguides.org (Accessed: 13 July 2026).