Most software engagements do not fail because the code was bad. They fail because nobody agreed upfront on what “done” means, who owns the rights and what happens when something goes wrong. The questions below cost ten minutes in a meeting and save you months.
Question 1: Who owns the code and where does it live?
The answer must be “you”, written into the contract, together with where the repository lives and who has access. If the code exists only on the contractor’s machine or account, you do not have a project — you have a dependency.
Ask for read access to the repository in the first week, not at delivery. Any difficulty with that request is the cheapest warning you will ever get.
Question 2: What exactly does “complete” mean?
“We’re done” without a definition is the primary cause of disputes. Ask for acceptance criteria per deliverable: which actions must work, with what test data, and who confirms the result.
A good sign is a partner who proposes acceptance criteria before you ask for them — it means they have been through project handovers and are not afraid of being measured.
Question 3: How will I see progress along the way?
A project that only appears at the end is a risk. There should be a staging environment where you see working versions at regular intervals and give feedback while it can still be acted on.
Note the difference: presenting design mockups is not implementation progress. Ask to click the buttons yourself.
Question 4: Who will actually write the code?
Often the meeting is held by an experienced person and the work is delegated to someone else without supervision. That is not necessarily a problem — delegating to a team is normal — but you need to know who carries technical responsibility and how involved they are.
Ask by name who the responsible engineer will be, and what happens if they leave the project midway.
Question 5: What about data and backups?
Ask for specifics on three points: how often backups are taken, how far back you can go, and when a restore was last tested. The third one separates the serious ones — a backup that has never been restored is an assumption, not protection.
If the system processes personal data, also ask where it is stored geographically and who has access.
Question 6: How are changes priced?
Requirements change in every project — that is normal and should not be treated as a transgression. The question is whether there is a predictable process: a written estimate for the change, your approval, then implementation.
Avoid both extremes: the contractor who bills for every clarification, and the one who says yes to everything without an estimate, because that cost reappears later as delay or poor quality.
Question 7: What happens the day after delivery?
Ask to see in writing what support covers, the response time, and what counts as an implementation defect versus a new requirement. Also: the process if you want to continue with a different team.
A partner who has thought clearly about their own exit is usually the one you will want to stay with.
The pattern behind the seven questions
We are not looking for the technically “correct” answer to each question. We are looking for whether the person has thought about it before being asked. A partner who answers specifically, admits their limits and puts things in writing is almost always a better choice than one who agrees with everything.