Seven questions to ask before signing a software contract

The questions below are not legal review items your solicitor handles those. They are business and operational questions that reveal how a vendor actually works, what they will do when things go wrong, and whether the relationship is structured for your success or for theirs.

Most vendors will not volunteer this information. Not because they are concealing it, but because the sales process is optimised for closing, not for surfacing risk. It is your responsibility to ask. The answers will tell you more than any proposal document.

One: Who, specifically, will be working on our project? Not the team structure the named individuals. Ask to meet them before you sign. Bait-and-switch on seniority is the single most common cause of disappointed clients in this industry.

Two: What happens if a key person leaves mid-engagement? The answer reveals whether the firm has genuine institutional knowledge or whether it depends on individual contributors with no transfer mechanism in place.

Three: Who owns the intellectual property? Code, designs, documentation, database schemas everything. It should transfer to you on payment. Any carve-out platform components, shared libraries should be specified explicitly, not referenced vaguely in the contract.

Four: What does the handover include? A well-run engagement ends with running infrastructure in your accounts, documented architecture, recorded walkthroughs, and runbooks for common operations. If a vendor is vague on this, they are planning a dependency.

Five: How are scope changes handled? Fixed-price contracts that do not specify a change control process will always result in disputes. Ask to see the actual change request form they use and how changes are priced.

Six: What is the process when the work is not meeting expectations? Not the escalation path the actual corrective process. Vendors who have handled this well before will answer quickly and specifically.

Seven: Can we speak to two clients whose projects did not go exactly to plan? References for successful projects are table stakes. References for recoveries are what you actually need.

A vendor who answers questions one through seven with confidence and specificity has done this before. They have thought about what makes engagements work, and they have probably had to recover from the failures these questions are designed to surface.

Hesitation on question three IP ownership is a serious flag. Hesitation on question seven references for difficult projects is equally serious. A firm that has never had a difficult project either has not been in business long enough or is not being candid about its history.

The goal is not to find a vendor with a perfect record. The goal is to find one whose failure modes are recoverable, whose processes are real, and whose interests are genuinely aligned with yours once the contract is signed.