Working together

What to put in a software development contract

Published September 15, 2026 · Lefty Software LLC

What should go into a software development contract? Less law than you fear, more specificity than most contracts bother with. A good custom software contract is not primarily a legal weapon; it is the written form of the conversation you should have had anyway — what gets built, how you will know it is finished, what happens when the plan meets reality, and who owns the result. Here is the checklist I would hand a friend before they signed any development agreement, whether with me, an agency, or a platform shop. One honest caveat up front: I am a developer, not a lawyer — have a lawyer review the final document, especially for anything regulated or high-value.

Scope: what will exist, and what will not

The scope clause is the contract. It should describe what the software will do in terms a non-developer can verify — screens, workflows, roles, integrations — and, just as important, what it explicitly will not do. Exclusions feel adversarial to write and are worth their weight in gold later: "does not include data migration from the legacy system", "does not include native mobile apps". The scope should also define "done" per feature in observable terms, so acceptance is a comparison against writing, not a feeling. If a vendor resists writing exclusions, that tells you how change orders will go later.

Change: how the scope is allowed to move

Every real project changes; a contract that pretends otherwise just hides the mechanism. What you want is a written change process: any work outside the scope arrives as a short written estimate of its cost and schedule effect before it starts, and you approve or decline it. This protects both sides — you never discover work on an invoice, and the developer never works for free on the assumption that you meant to include it. Ask directly how out-of-scope requests are handled; the answer is a better interview question than any reference check.

Price and payment

The payment clause should say which model you are buying: New projects are fixed-price. I agree a written scope and quote with you before development starts, so the initial build has a defined cost — that is how I run engagements, and it is the model I would generally recommend for a defined first version. Time-and-materials suits work whose scope genuinely cannot be known; if you choose it, insist on regular itemized reporting so the burn is never a surprise. Beyond the model, look for: a deposit that is meaningful but not the whole price (100% up front is a walk-away), payments tied to something observable — milestones, deliveries, or dates you can verify — and the agreed rate for any post-launch hourly work written down before you need it. Changes and maintenance can be provided at an agreed hourly rate.

Acceptance: how you will decide it is done

An acceptance clause turns "done" from a debate into a procedure: you get access to a staging environment during the build, you review each delivered piece against the written scope within an agreed review window, and silence beyond that window counts as acceptance. Watch for the two pathological versions: contracts where the vendor declares the work done unilaterally, and contracts where acceptance is so open-ended that a paying customer can hold a finished product hostage to invented requirements. A review window with a definition of done protects everyone from both.

Ownership: the clause that matters most

When you have paid, the work product should be yours: source code, configuration, documentation, designs — assigned to you outright, with no ongoing license fees and no lock-in. Just as important are the accounts around the code: the repository, the domain registrar, the cloud provider, and the email sender should live in accounts you control. Where control needs to transfer, agree a documented transfer procedure and responsibilities before work starts. I describe the full standard in what to expect when hiring a solo developer, but the one-line version belongs in your contract review: if the code "lives on the developer's server", that is not ownership, whatever the contract says.

Timeline and dependencies

A timeline clause should distinguish calendar time from effort, and name the dependencies honestly: your feedback within the review window, access to the third-party systems being integrated, and content or data only you can provide. Delays should restart the affected clock, not silently absorb into the developer's margin or your blame. Ask what happens on both sides if a dependency slips — a vendor who has thought about it will have a boring, workable answer.

Support, maintenance, and what happens after launch

Look for a defined support window after launch — what defects are covered, for how long, and what happens after it ends. My website projects include 30 days of support for defects and questions after the website goes live; after that, maintenance can continue at the agreed hourly rate, and monitoring is available as a separate purchase. Whatever the offer, the contract should state the boundary between "broken as delivered" (the developer's problem) and "new work" (a scoped request). For the difference between a standing maintenance agreement and ad-hoc hourly work, I compared them in software maintenance retainers, explained.

Confidentiality, data, and the exit

Two quieter clauses deserve attention. Confidentiality: a developer will necessarily see your business logic and data shapes; a mutual confidentiality term is standard and reasonable. Exit: the contract should say what you receive if the relationship ends early, from either side — the code as it stands, the documentation, the credentials, and any handover walkthrough owed. The test I would apply: could a different developer pick up the project from the handover alone? If the contract does not guarantee the materials for that, you are negotiating leverage, not commissioning software. See the StringBench case study: it describes a business-specific system where the exit path is worth more than any discount, because the platform's value lives in details only a well-documented handover can carry. And if you are weighing whether the project should exist at all, start with buy vs build for internal tools before you paper anything.

That is the checklist: scope and exclusions, change process, price and payment, acceptance, ownership, timeline, support, confidentiality, exit. I agree a written scope and quote with you before development starts. For how that engagement runs, see my custom web app development service. I am based in Bradenton and work with clients remotely; Gulf Coast businesses can read about custom software development in Bradenton, Sarasota & Tampa Bay. Have a lawyer read what you sign — this checklist is how to arrive at that meeting with the right questions.

← More from the blog