What to Ask a Dev Partner Before You Sign the SOW

For: A seed-to-Series-A SaaS founder who has chosen a dev partner, received a statement of work, and is 48 hours from signing — but has never commissioned a custom software build before and does not know which clauses will hurt them post-launch

If you only have time to interrogate one clause in your statement of work, make it the acceptance-criteria definition. If 'accepted' means the vendor decides the milestone is done rather than a signed sign-off tied to a written test plan you both agreed to before work started, every disputed milestone will default in the vendor's favor and you will have no contractual remedy short of a lawsuit. That single clause matters more than the payment schedule, more than the hourly rate, and more than the delivery date — because it determines what all of those actually mean in practice.

What follows is a checklist for the 48 hours between receiving the SOW and signing it. It assumes you have already done reference calls, the technical deep-dive, and the pricing negotiation. This is the contract-review pass — the questions to ask your prospective partner directly, in writing, before you countersign. Save the email thread. It becomes your interpretive record if things go sideways.

Some context on why this matters: the Standish Group CHAOS Report 2024 found that 71% of software projects fail to fully deliver on their original objectives, with unclear requirements cited as the top cause in 39% of failures. A separate 2024 survey of 600 engineers found projects with clear requirements documented before development were 97% more likely to succeed. The SOW is where those requirements get locked in — or don't.

The acceptance and quality questions (ask these first)

1. How is 'acceptance' defined for each milestone, and who signs off?

Why it matters: Acceptance is the trigger for payment and for the clock starting on your warranty window. If the definition is vague, the vendor controls the interpretation.

Good answer: "Each milestone has a written test plan attached as an appendix. Acceptance means your named product owner signs off after running the documented test cases in a staging environment. You have a defined review window — say, 10 business days — after which silence counts as acceptance, but rejection must be itemized in writing."

Red flag: "We demo it, you approve it," or "acceptance is at our reasonable discretion," or the SOW references acceptance criteria "to be defined during the sprint." Inadequate testing accounts for 29% of software project failures — much of it traceable to undefined acceptance.

2. What is the written test plan for milestone one, and can I see it before I sign?

Why it matters: If they cannot produce a draft test plan for the first milestone before you sign, the acceptance clause is theoretical.

Good answer: A draft plan, even a rough one, listing the specific user flows, edge cases, and non-functional requirements (load, response time, browser matrix) that will be tested.

Red flag: "We'll write it in sprint zero." That means you sign a contract whose main enforcement mechanism doesn't exist yet.

3. Who writes the acceptance test cases — you, us, or jointly?

Why it matters: Vendor-written tests tend to test what the vendor built, not what you asked for.

Good answer: Joint authorship, with your product owner having final approval, and the SOW naming that person by role.

Red flag: Vendor writes them and you approve at the end. That is a rubber stamp dressed up as a control.

4. What is the defect severity classification, and which severities block acceptance?

Why it matters: Without a severity taxonomy, every bug becomes a negotiation. "It's a minor issue, ship it."

Good answer: A written scale — for example, Sev 1 (blocker: core flow broken), Sev 2 (major: workaround exists), Sev 3 (minor: cosmetic) — with Sev 1 and Sev 2 blocking acceptance and Sev 3 tracked into a backlog.

Red flag: No taxonomy, or "we'll triage together."

The IP and ownership questions

5. When exactly does IP assignment transfer to me?

Why it matters: Under U.S. copyright law, the developer owns the code by default unless the contract explicitly assigns it to you. Vendors often make assignment conditional on "full and final payment of all invoices" — which means one billing dispute can block your ownership of the entire codebase.

Good answer: "IP for each deliverable assigns to you upon payment of the invoice for that deliverable," or better, "upon creation, with a security interest retained until payment." Assignment is per-milestone, not contingent on the entire engagement being paid.

Red flag: "All IP assigns upon full and final payment of all sums due under this agreement." Founders lose IP on this clause routinely — a $4,000 dispute at the end can hold a $400,000 codebase hostage.

6. What third-party code, open-source libraries, or pre-existing vendor IP is embedded in what you deliver, and what are the license terms?

Why it matters: You can own the code your vendor writes and still not be able to ship it — if it depends on a GPL library or a vendor's proprietary framework licensed only for the duration of the engagement.

Good answer: A written list of dependencies with license types (MIT, Apache 2.0, etc.), and an explicit perpetual, royalty-free license to any vendor pre-existing IP embedded in the deliverables.

Red flag: "We use our internal framework, licensed for the term of the engagement." That is a rug-pull waiting to happen.

7. On day one after the engagement ends, what do I get and in what form?

Why it matters: Ownership is worthless if you cannot access, build, or deploy the code without the vendor.

Good answer: Full Git history transferred to your organization's repo, all credentials and infrastructure access, deployment runbooks, architecture documentation, and a 30-day handover window with named engineers available for questions.

Red flag: "We'll send you a zip file of the final code." No history, no context, no runbook — you own a building with no keys and no blueprints.

The change-order and scope questions

8. What is the threshold above which a change requires a formal change order, and what is the process?

Why it matters: McKinsey found scope creep adds 20–40% to outsourced project costs, and PMI reports 52–55% of projects experience it. A vague change-order clause means every small addition becomes a "we'll figure it out" that shows up as an invoice you didn't expect.

Good answer: A specific hour threshold (e.g., anything over 8 hours of work) triggers a written change order with scope, cost, and timeline impact, requiring your signature before work begins.

Red flag: "We'll flag material changes," with no definition of material. Or the reverse: every 30-minute tweak requires a change order, which just means the vendor stops trying and starts billing.

9. What happens if I want to descope — cut features to hit a date?

Why it matters: Most SOWs handle adding scope but say nothing about removing it. If you cut 20% of the build, does the price come down?

Good answer: Descoping is handled symmetrically with change orders. Reductions in scope reduce cost proportionally, with a documented method (fixed-price milestone credits, or unbilled hours returned).

Red flag: Silence on descoping, or "the fixed price stands regardless."

10. If a milestone slips because of your team, what is the remedy? If it slips because of my team, what is the remedy?

Why it matters: Timelines slip. The question is who bears the cost.

Good answer: Symmetric. Vendor delays extend at no cost to you and may trigger a credit past a threshold. Client delays (late feedback, missing approvals) extend the timeline and may trigger a re-mobilization fee, defined in advance.

Red flag: Only client-side delays have consequences. Or vendor delays trigger vague "reasonable efforts to remediate."

The warranty, security and exit questions

11. What is the post-launch warranty window and what does it cover?

Why it matters: Bugs that trace back to the original build should be fixed on the vendor's dime, not yours.

Good answer: A defined warranty period (typically 30–90 days) covering defects — code that does not meet the accepted acceptance criteria — at no additional cost. New feature requests and environmental issues (your AWS bill, a third-party API changing) are explicitly excluded.

Red flag: No warranty. Or a warranty so narrow ("defects reproducible in the original test environment within 7 days of delivery") that it is unenforceable.

12. What is your security posture for our code and data during the build?

Why it matters: Your MVP source code, your customer data used in staging, your API keys — the vendor holds all of it during development.

Good answer: Named practices: SSO on the code repo, MFA on all vendor accounts touching your systems, an offboarding checklist when engineers rotate off, encrypted backups, and a written data-handling policy. If you handle regulated data (health, financial, EU personal data), they should reference the relevant framework (HIPAA, PCI, GDPR) without prompting.

Red flag: Hand-waving, or "our engineers are trusted." For regulated verticals, this is a walk-away. If you are building something like a healthcare product handling patient data or a lending product with KYC, security posture is a gate, not a preference.

13. What are your data deletion obligations at the end of the engagement?

Why it matters: Your data on their laptops, their backups, their staging environments — where does it go and when?

Good answer: A written obligation to delete all client data within a specified window (30–60 days post-handover), with a signed certificate of destruction. Backups included, with a defined retention period justified by their backup policy.

Red flag: No mention. Or "we retain project artifacts for our records."

14. If the engagement ends early — either side — what does the transition look like?

Why it matters: McKinsey and Oxford's study of 5,400 large IT projects found the average ran 45% over budget and delivered 56% less value than predicted. Some engagements need to end. The SOW should make that possible without a hostage situation.

Good answer: A defined termination-for-convenience clause on both sides with a notice period (typically 30 days), a paid transition window with named engineers available for handover, code and IP transferred immediately, and pro-rated payment for work-in-progress.

Red flag: Termination only for cause, or a punitive early-termination fee, or IP transfer contingent on "successful completion of the engagement."

The team, communication and dispute questions

15. Who specifically is on my team, and what is your policy on staff substitution?

Why it matters: You interviewed a senior engineer and signed based on their involvement. What stops them being rotated off in week three?

Good answer: Named individuals in the SOW for key roles (tech lead, senior engineers), with a substitution clause requiring written notice, an equivalent-or-better replacement, and your approval right.

Red flag: "A team of similar seniority will be assigned," or the SOW names only roles, not people.

16. What is the escalation path when we disagree, and what is the dispute-resolution mechanism?

Why it matters: You will disagree. The question is whether resolution takes a day or a lawsuit.

Good answer: A tiered path — engineer, project manager, executive sponsor — with time limits at each tier, followed by mediation before litigation. Governing law and jurisdiction specified (and reasonable — a Delaware SaaS company should not be litigating in a jurisdiction where enforcement is uncertain).

Red flag: No escalation path, or mandatory arbitration in an inconvenient venue, or governing law that makes enforcement impractical for you.

17. Can you show me the same SOW you signed with two other clients of similar size, with pricing redacted?

Why it matters: The best test of whether a vendor's contract is fair is whether they use the same one with everyone. Bespoke terms invented for you are often bespoke in the vendor's favor.

Good answer: Yes, with client names redacted and NDA-appropriate handling. The core clauses (IP, acceptance, warranty, change orders) look the same.

Red flag: Refusal, or the shared SOWs have materially different protective clauses than yours.

A note on cost and timeline commitments in the SOW

Every SOW ties price and duration to a scope. The scope is an assumption set: this many screens, these integrations, this data model, this compliance regime. When the assumptions move, the number moves — that is not a vendor being difficult, that is how fixed-price software actually works.

What determines whether your final invoice is close to the SOW figure or 40% higher is mostly under your control: how well-defined the requirements were at signing, how quickly your team gives feedback and approvals, and how disciplined you are about deferring "while we're at it" additions to a v2 backlog. The 97% success-rate lift from documented requirements is the single biggest lever you have.

Before signing, the three specifics that would tighten any cost or timeline range into something close to a real number are: (1) a written functional spec or clickable prototype, not just a feature list; (2) named integrations with API documentation reviewed by the vendor; and (3) clarity on any compliance regime (HIPAA, SOC 2, GDPR) that changes the architecture. If two of those three are missing, the SOW number is a placeholder — a starting point, not a commitment — regardless of what the cover page says.

None of this is a substitute for a lawyer reading the SOW. IP assignment, warranty, liability caps, and indemnification clauses have material legal consequences that vary by jurisdiction, and a startup lawyer's fee to review a development SOW is small relative to the downside of getting one of these wrong. Get one to read it.

Frequently Asked Questions

Should I sign a fixed-price SOW or time-and-materials?

Fixed-price works when the scope is genuinely well-defined — a documented spec, clickable prototype, known integrations. Time-and-materials works better when you are still discovering the product, because fixed-price on a fuzzy scope just means you pay for a change order every two weeks. Most seed-stage MVPs are somewhere in between; a hybrid (fixed-price discovery phase, then either fixed or T&M for build) often fits the reality.

What is the single most common SOW clause that hurts startups post-launch?

IP assignment tied to "full and final payment of all invoices." It sounds reasonable until a small billing dispute at the end of the engagement freezes your ownership of the entire codebase. Push for per-milestone or per-deliverable assignment, so paid work is your work regardless of what happens with the final invoice.

How long should the post-launch warranty be?

30 to 90 days is standard for a custom build, covering defects against the agreed acceptance criteria. Longer warranties sound good but are often paired with narrower definitions of what counts as a defect. A tight 60-day warranty with a clear defect definition is usually more useful than a 6-month warranty covering only "reproducible reproducible critical failures."

Can I negotiate the SOW if the vendor says it is their standard template?Yes. "Standard template" is a negotiation tactic, not a legal constraint. The clauses that matter most — acceptance criteria, IP trigger, change-order threshold, warranty scope, termination — are all negotiable with any vendor that wants the work. If a vendor refuses to move on any of them, that itself is information about how the relationship will go.

Do I need a lawyer to review a development SOW?

Yes, and specifically a lawyer who has reviewed technology contracts before, not just any commercial lawyer. IP assignment, warranty disclaimers, limitation of liability, and indemnification clauses have material consequences that vary by jurisdiction, and generic contract review will miss the software-specific traps. This post is a checklist for the business questions to ask — it is not legal advice, and your lawyer should read the actual document.