Custom Software Development Services: Checklist Before You Sign

It’s commonly assumed that a signed statement of work protects you once the ink is dry. It doesn’t — not on its own, and not without the specific clauses that address what actually goes wrong six weeks into a build. Most vendor relationships in custom software development don’t fail because of bad engineers; they fail because the contract governing the relationship never specified the things that turn into disputes once real work is underway. A statement of work that reads well is not the same as one an engineer could actually run a project against.

If you’re a CTO or VP of Engineering about to sign an agreement for custom software development services, the document in front of you almost certainly reads well. Most SOWs do — they’re written by people whose job is to get contracts signed, and vague language rarely triggers objection at first read. The problem surfaces later, when an ambiguity that seemed harmless in the document becomes a dispute in production. Here’s the checklist worth running before you sign, item by item.

1. Scope Defined as Explicit Inclusions AND Exclusions

Most SOWs describe what’s included reasonably well. Far fewer state explicitly what’s excluded, and that omission is where scope disputes are born. If the SOW describes “a customer-facing web portal with account management and reporting,” ask for an explicit exclusions list: does reporting include exportable PDFs? Does account management include SSO integration? Every ambiguous noun in your scope description is a future change-order conversation waiting to happen.

Push your vendor to produce a scope boundary document as a companion to the SOW — a simple table of features with an “in scope / out of scope / to be scoped later” column for each. This single artifact resolves more disputes before they start than any amount of legal language protecting either party after the fact.

Run this exercise feature by feature with your own product team present, not just the vendor’s account manager. It’s common for a CTO to assume a feature is obviously included because it’s implied by the product vision, while the vendor scoped only the literal words in the written requirements document. That gap is invisible until someone asks the specific question, which is exactly why the exercise needs to happen before signature rather than being discovered during a sprint review three months in.

2. Named Team Roles With Explicit Allocation Percentages

A statement of work that says “a dedicated team will be assigned” without specifying roles and allocation is functionally unenforceable if staffing turns out thinner than you expected. Insist on a staffing table: role, name (or role profile if names aren’t finalized), and percentage allocation to your project specifically. If your SOW promises a senior backend engineer at 100% allocation, that person shouldn’t also be listed at 60% on another client’s SOW for the same period — ask directly whether allocation percentages are exclusive to your project or shared across concurrent engagements.

This matters especially for full-stack capabilities spanning frontend, backend, DevOps, and QA — verify that DevOps and QA roles are explicitly staffed and allocated, not folded silently into developer time, since these are the roles most often quietly under-resourced when a vendor is managing margin pressure.

Also ask what happens contractually if a named team member leaves mid-engagement, which is a realistic scenario over a multi-month build. A mature SOW specifies a replacement timeline (typically two to three weeks for a comparable-seniority replacement) and a knowledge-transfer requirement between outgoing and incoming staff, rather than leaving you to discover, after the fact, that your project has gone quiet while the vendor scrambles to backfill a role nobody committed to covering contractually.

3. A Definition of Done Tied to Each Milestone, Not Just the Final Delivery

Milestone-based payment structures are common and reasonable, but they only protect you if each milestone has explicit, testable acceptance criteria attached — not vague language like “feature complete” or “client satisfaction.” A strong SOW ties each milestone payment to specific criteria: passing test coverage thresholds, defined performance benchmarks under load, and a structured client review window with a clear process for raising and resolving objections before payment is due.

Without this, milestone payments become a negotiating tool rather than a quality gate — a vendor under schedule pressure has every incentive to declare a milestone “done” on a technicality if the criteria were never specified precisely enough to dispute.

A useful test: hand your draft SOW’s Definition of Done language to an engineer who wasn’t involved in negotiating it, and ask them to explain, without asking anyone else, exactly what would need to be true for a milestone to be considered complete. If they come back with follow-up questions, so will your vendor’s team when they’re the ones deciding whether they’ve met the bar — and that ambiguity resolves in the vendor’s favor by default, not yours.

4. Continuous IP and Source Code Transfer, Not Just Final Handover

This is the single most consequential clause in the entire document and the one CTOs most often assume is standard without verifying it explicitly. The SOW should specify that you receive full repository access and IP ownership on an ongoing basis throughout the engagement — commit by commit, not only at project completion. If the relationship ends early for any reason, you should walk away with a working, current codebase, not a promise of one at a future milestone that never arrives.

Verify this isn’t just a general statement in the master services agreement but explicitly reiterated in the SOW itself, since SOWs sometimes get amended or extended in ways that can quietly drift from the parent agreement’s terms if nobody is checking.

5. A Documented Change Management Process With Pricing Attached

Every real project changes scope. The question is whether your SOW specifies how that happens or leaves it to be negotiated under pressure mid-project, which almost always favors whoever has more leverage at that moment — usually the vendor, since switching costs by then are high. A strong SOW specifies a change request template, a maximum turnaround time for impact assessment (cost and timeline), and a pre-agreed hourly or milestone rate for approved changes, so you’re not negotiating pricing from scratch every time your product needs to evolve.

It’s also worth specifying who on your side has authority to approve a change request, and who on the vendor’s side can commit to it, so that a single Slack message from an enthusiastic stakeholder doesn’t accidentally become a binding scope change neither party formally tracked. A documented approval chain protects both sides equally and tends to reduce, not increase, the friction of legitimate mid-project pivots.

6. Communication Cadence and a Real Escalation Path

The SOW should specify meeting cadence (daily standups, sprint reviews, retrospectives) and, critically, a named escalation contact above the day-to-day project lead who can be reached directly if something isn’t working. Vague language like “regular communication will be maintained” gives you no recourse if communication quietly degrades three months in. For distributed teams specifically — European project governance paired with Southeast Asian engineering talent, in Manifera’s delivery model — the SOW should also specify actual overlap hours guaranteed for synchronous communication, not just time zones listed for informational purposes.

Test this before signing rather than taking it on faith: ask to sit in on a live standup with the proposed team during the evaluation period. Communication quality is one of the few checklist items you can verify directly rather than inferring from contract language, and thirty minutes observing how a team actually runs a standup tells you more about day-to-day communication reality than any clause describing it in the abstract.

7. Explicit Post-Launch Support Terms

Ambiguity about what happens immediately after go-live is one of the most common sources of dispute in custom software engagements. The SOW should specify the length and scope of a post-launch stabilization period (commonly 30-90 days), what’s covered under that period at no additional cost (bug fixes tied to originally specified functionality) versus what constitutes a new billable request (new features, scope not in the original specification), and what ongoing support options exist afterward with clear pricing.

8. A Clean Termination and Transition-Out Clause

Nobody signs a contract planning to terminate it early, which is exactly why this clause gets the least attention and causes the most damage when it’s needed. The SOW should specify notice periods for termination by either party, what deliverables and documentation you receive upon termination regardless of cause, and a defined transition-out period during which the vendor commits to knowledge transfer support. A vendor confident in the relationship they’re proposing won’t resist a fair, symmetric termination clause — resistance here is itself useful diagnostic information.

Running This Checklist Before You Sign

None of these eight items require a lawyer to identify — they require an engineering leader reading the SOW with the same scrutiny they’d apply to a system design document, looking for the ambiguous nouns and unstated assumptions that will matter later. Manifera builds every custom software development engagement SOW around explicit versions of all eight items above by default, and our way of working page documents the sprint cadence and communication structure referenced in items six and seven in more detail if you want to compare it directly against what’s in front of you right now.

Book a 30-minute architecture and contract review with one of our senior team members before you sign anything — we’ll go through your current SOW against this checklist with you, whether or not you end up working with us.

The Ninth Item: Liability Caps and Data Processing Terms

Most eight-point SOW checklists stop before the clause that determines what happens if something actually goes wrong. Check the liability cap specifically — many vendor-drafted SOWs cap total liability at the value of fees paid in the prior one or three months, which on a €150,000 annual engagement can leave you covering the bulk of a security incident’s real cost yourself. Push for a cap tied to a meaningful multiple of the contract’s annual value, or an uncapped carve-out specifically for data breaches, IP infringement, and gross negligence — the three failure modes that actually produce catastrophic cost.

If any EU user data touches the build, the SOW needs a Data Processing Agreement (DPA) referenced explicitly, not assumed to exist in a master agreement you haven’t checked. Confirm it names the sub-processors actually involved (cloud hosting, monitoring tools, any third-party APIs handling personal data), specifies breach notification within 72 hours per GDPR Article 33, and states where data is processed and stored geographically. A vendor operating a distributed delivery model should be able to produce this without friction — if a finalist hesitates on naming their actual sub-processor list, that hesitation belongs on the same red-flag list as an unnamed engineering team.

FAQs