The 7 Things Your Software Contract Must Answer Before You Sign Anything

Most software development contracts are written to protect the agency. The payment terms are airtight. The liability caps are low. The scope definition is vague enough to justify change orders on anything you thought was included. Founders sign them anyway because the sales process was good and the demo looked great. Then the project starts and the contract becomes the document that decides who wins every argument you have for the next six months.

Before you sign anything, your contract needs to give you a clear answer to each of these seven questions. If it does not, ask for an amendment. If the agency pushes back on any of them, treat that as signal.

1. Who owns the code the moment it is written?

This should not be a question you have to ask, but it often is. Some agencies retain a license to reuse components they build for you in other client projects. Others assign IP only after final payment is received, which means you do not own your own codebase during the build. The contract should state explicitly that all intellectual property produced during the engagement is assigned to you from the moment it is created, not upon delivery or payment. If there are carve-outs for pre-existing libraries or open-source components, those should be listed specifically. Blanket IP carve-outs that could cover custom work are a red flag.

2. What is the exact scope — and what is explicitly excluded?

Vague scope documents are the most common source of billing disputes in software projects. A contract that says "build a patient management system" is not a scope document. A contract that lists every feature, every integration, every user role, every environment, and every third-party dependency — and explicitly states what is not included — is a scope document. Before signing, ask the agency to list three things that are explicitly out of scope for this contract. If they cannot answer quickly, the scope is not well-defined. Insist on a detailed specification as an appendix to the contract, not a separate document that may or may not be referenced in a dispute.

3. How are scope changes priced and approved?

Every project has scope changes. The question is whether the process for handling them is defined before they happen. The contract should specify: who can request a change, what written form the request must take, how long the agency has to provide a cost and timeline estimate, and that no change order work begins until you have approved it in writing. Verbal approvals that get billed later are a common mechanism for blowing project budgets. If the contract does not have a formal change control process, add one before you sign.

4. What are the payment milestones tied to?

Payment schedules should be tied to deliverables, not to calendar dates. A contract that bills 25% on the first of each month regardless of what was delivered gives you no leverage if the project slips. Milestone-based payments — tied to specific, testable deliverables like "working user authentication," "completed API integration," or "staging environment passing QA" — give you a natural checkpoint to verify progress before releasing funds. If the agency insists on time-based billing rather than milestone-based billing, make sure the milestones are at least defined as a separate delivery schedule that both parties sign.

5. What happens if the project is terminated early?

Projects get cancelled. Priorities shift, funding changes, the product direction pivots. The contract must define what happens in each termination scenario: you terminate for convenience, you terminate for cause, the agency terminates. Specifically, it needs to answer: what work has been paid for, what deliverables you receive upon termination, who owns the partially-built codebase, and whether there is a termination fee. Some agencies include clauses that require 60 to 90 days notice before termination, which means you keep paying for two to three months after you have decided to stop. Read the termination clause carefully.

6. Who holds the credentials and infrastructure access?

At the end of the project — or if the relationship ends mid-build — you need to be able to access everything the agency built or set up on your behalf. The contract should require that all cloud accounts, domain registrars, code repositories, third-party API keys, and deployment credentials are registered in your name or transferred to your control immediately upon request. Agencies that set up infrastructure under their own accounts and then transfer access at the end of the project create unnecessary risk. If the agency goes out of business or the relationship sours, you want to be able to operate your product without their involvement.

7. What is the warranty period and what does it cover?

Software has bugs. The question is who is responsible for fixing them after launch and for how long. Most professional software contracts include a warranty period of 30 to 90 days post-launch during which the agency fixes defects in the delivered work at no additional charge. The contract should define what constitutes a defect (something that does not work as specified) versus a change request (something new you want added). Without this definition, every post-launch bug fix becomes a billable conversation. After the warranty period, the contract should specify what support and maintenance options exist and at what rate.

The contract is a filter, not just a formality

How an agency responds to your questions about the contract tells you as much as the contract itself. An agency that has delivered many successful projects will have already thought through all of these questions. Their contracts will have clear answers because they have seen what happens when these things are left ambiguous. An agency that pushes back on IP assignment, resists milestone-based payments, or provides a vague scope document is showing you something important before the project even begins.

The best software partnerships do not need lawyers. But the contract that makes them possible is the one that was written carefully enough that neither party ever has to refer to it.