Questions to Ask a Software Vendor Before Signing a Contract: The 12 That Protect You

Last updated: September 6, 2026 · By Joseph Olivas, Founder, MEAN Consultors · 9 min read

By the time a contract lands in your inbox, you have usually already decided you like the vendor. That is exactly when businesses stop asking questions and start signing. I have reviewed enough software agreements — ours and other people’s — to know that the disputes that end up costing five and six figures almost never come from bad code. They come from clauses nobody read and questions nobody asked. This guide covers the twelve I insist clients ask, and what a good answer sounds like.

Why the contract stage deserves its own set of questions

Vetting a vendor’s capability and vetting their contract are different jobs. You may have already worked through how to choose a custom software development company and screened for the red flags that signal a bad agency. Those steps tell you whether the firm can build what you need. The contract determines what happens when reality diverges from the plan — and it always diverges somewhere.

The stakes are well documented. McKinsey’s analysis of more than 5,400 IT projects found that large software projects ran, on average, 66% over budget and 33% over schedule, while delivering 17% less value than predicted. Smaller projects fare better, but the mechanisms are the same: unclear requirements, uncontrolled scope changes, and misaligned incentives. Every one of those is a contract problem before it is an engineering problem.

Figure 1 shows how we weight eight contract areas by the share of disputes we see traced back to each. Intellectual property and scope definition alone account for more than 40% — and they are the two areas business owners most often assume are “standard.”

Figure 1: IP ownership and scope definition account for over 40% of the contract disputes we see — ask about those first.

The 12 questions to ask a software vendor before signing

1. Who owns the code, and when does ownership transfer?

This is the question most owners assume they do not need to ask. Under U.S. copyright law, software written by an independent contractor is generally not a “work made for hire” unless a written agreement says so and the work fits specific statutory categories — and custom software usually does not. Without an explicit written assignment of copyright, the vendor may legally own the code you paid for. A good answer: “All custom code is assigned to you upon payment of each milestone, in writing, in section X.” A bad answer: “You get a perpetual license.” A license is not ownership.

2. What third-party or pre-existing components are included, and under what terms?

Every modern application uses open-source libraries and often the vendor’s own reusable modules. Ask for a list, the license for each, and confirmation that nothing forces you to open-source your own code. If the vendor retains ownership of a “framework” the app depends on, you need a perpetual, irrevocable, royalty-free license to it — otherwise you cannot leave.

3. Exactly what is being delivered, and how will we both know it is done?

“A customer portal” is not a deliverable. A statement of work with named features, user roles, integrations, environments, and written acceptance criteria is. If you have not yet documented what you need, our guide to writing a software requirements document non-technical founders can use is the place to start. A vendor who resists acceptance criteria is asking you to accept whatever ships.

4. How are scope changes requested, estimated, and approved?

Scope will change; the question is whether the process is written down. Look for a change-order procedure: request in writing, vendor estimates impact on cost and schedule, you approve before work starts. Without it, you will either be surprised by invoices or the vendor will quietly absorb changes and cut corners elsewhere.

5. Is pricing fixed, time-and-materials, or hybrid — and what does each protect?

Neither model is wrong, but each shifts risk. Fixed price protects your budget and pushes the vendor to hold scope tightly; time-and-materials protects flexibility and pushes the risk to you. Our comparison of fixed price vs. time and materials contracts covers when each fits. Whatever the model, ask how estimates are produced and what happens when they are exceeded.

6. How do payments tie to milestones, and what happens if a milestone is late?

Payments should follow accepted deliverables, not calendar dates. A reasonable structure for an SMB project is a modest deposit followed by milestone payments upon acceptance, with a final payment after a short production-stability period. Ask what remedy you have if a milestone slips: a schedule credit, a re-plan, or nothing.

7. How long is the warranty period, and what does it cover?

A warranty is the window after delivery during which the vendor fixes defects at no charge. Thirty to ninety days is common for SMB projects. Ask how “defect” is defined — a bug against agreed acceptance criteria — versus an enhancement, which is billable. Also ask what response times apply during the warranty period and what happens after it. That “after” is your ongoing software maintenance budget, and it should be priced before you sign, not discovered later.

8. What happens if we end the relationship — early or at the end?

Exit terms are the clause you hope never to use and the one that determines how much leverage you have for the entire relationship. Ask for: notice periods, delivery of all source code, documentation, credentials, and infrastructure access within a defined number of days, a reasonable transition-assistance provision billed at the standard rate, and no termination fee beyond work actually performed. If the vendor hosts your application, confirm you can move it.

9. Where does our data live, who can access it, and how is it protected?

Ask which cloud provider and region hosts the application, who at the vendor has production access, whether data is encrypted at rest and in transit, how backups are handled and tested, and how a breach would be disclosed to you. If your business handles health, financial, or consumer personal data, the contract needs to name the applicable regulations and who is responsible for compliance. Secure development practices such as those in NIST’s Secure Software Development Framework are a reasonable thing to ask a vendor to follow.

10. Who actually does the work, and can the team change?

Ask whether developers are employees or subcontractors, where they are located, whether any part of the work will be subcontracted without your approval, and who your day-to-day contact is. It is legitimate for vendors to use subcontractors; it is not legitimate for the team that impressed you in the sales process to vanish after kickoff without notice.

11. What environments, documentation, and handover materials are included?

You should receive, at minimum: source code in a repository you control, a written deployment procedure, architecture and data-model documentation, and admin credentials for every service the application depends on. Ask whether these are deliverables or “available on request” — only the first is enforceable.

12. What are the limits on liability, and are they mutual?

Almost every vendor contract caps liability at the fees paid, and that is normal. What to check: the cap should be mutual, should not apply to breaches of confidentiality or IP indemnity, and the vendor should indemnify you if their code infringes someone else’s intellectual property. Have a lawyer read this section — it is the one place where a small fee for review reliably pays for itself.

What good and bad answers look like

Vendors will answer all twelve questions; the signal is in how. The table below summarizes the pattern I look for.

The review sequence: from proposal to signature

Asking the questions is half the job; the other half is making sure the answers change the paperwork. Figure 2 shows the sequence we recommend. It adds two to three weeks before kickoff on a typical SMB project — time that is repaid many times over the first time scope shifts.

Figure 2: The five-step path from proposal to signature — written answers feed directly into the SOW and redlines.

• Map the proposal to the contract. Every feature, timeline, and promise in the sales proposal should appear in the SOW. Anything missing is not part of the deal.
• Send the 12 questions in writing. Give the vendor a week. Evasive or verbal-only answers are themselves an answer.
• Build the SOW around acceptance criteria. Each deliverable gets a definition of done you could hand to a third party to verify.
• Redline the four high-risk clauses first: IP assignment, change control, exit and handover, warranty. These are where leverage lives.
• Have counsel review liability and indemnity. An hour of a technology attorney’s time is inexpensive relative to the project.
• Attach everything as exhibits. SOW, schedule, acceptance criteria, and the vendor’s written answers become part of the signed agreement.

One last point about tone. None of these questions is adversarial, and a professional vendor will welcome them — we do, because clients who ask them tend to be the clients whose projects go well. When we scope custom software development or AI automation work at MEAN Consultors, most of these answers are already in our standard agreement precisely because we have watched what happens when they are not. If a vendor treats the questions as an insult, you have learned something important before spending a dollar.

Frequently Asked Questions

What are the most important questions to ask a software vendor before signing a contract?

The four that matter most: who owns the code and when ownership transfers, exactly what will be delivered and how acceptance is judged, how scope changes are priced and approved, and what you receive if the relationship ends. Then cover payment milestones, warranty, data security, team and subcontracting, handover materials, and liability limits.

Do I automatically own custom software I pay a vendor to build?

Not necessarily. Under U.S. copyright law, work by an independent contractor is generally only a ‘work made for hire’ if a written agreement says so and the work fits specific statutory categories, which custom software usually does not. Require an explicit written assignment of copyright to your company; a license is not ownership.

What should a software development statement of work include?

Named deliverables and features, user roles, integrations, environments, a schedule with milestones, written acceptance criteria for each deliverable, the change-order process, payment terms tied to acceptance, warranty period, and the handover materials (source code, documentation, credentials) you will receive.

How long should a software warranty period be?

Thirty to ninety days after acceptance is typical for small and mid-size business projects. The contract should define a ‘defect’ as a failure against agreed acceptance criteria, state response times, and clarify that enhancements are billable. Ongoing maintenance after the warranty should be priced before signing.

Is it normal for a software vendor to cap liability?

Yes. Capping liability at the fees paid is standard. Check that the cap is mutual, that it does not apply to confidentiality breaches or intellectual-property indemnity, and that the vendor indemnifies you if their code infringes a third party’s IP. Have an attorney review this section.

What exit terms should a software contract include?

A defined notice period, delivery of all source code, documentation, credentials, and infrastructure access within a set number of days, transition assistance billed at standard rates, and no termination fees beyond work actually performed. If the vendor hosts the application, confirm your right to migrate it.

Should I ask whether the vendor uses subcontractors?

Yes. Subcontracting is legitimate, but the contract should require your approval before work is subcontracted, name your day-to-day contact, and address where developers are located — which affects data-handling obligations and communication.