When a business compares software vendors, it usually compares portfolios and prices. Both are easy to see and neither tells you much about whether the project will finish on time, at the agreed price, with something that works.
The things that decide that are process questions, and most vendors will answer them honestly if asked directly. These are the six we would ask, and what a good answer sounds like.
1. What happens when the scope changes?
It will change. Once people see working software they notice things they could not have known to ask for. That is normal and healthy, and the question is how it is handled.
A good answer describes a process: the change is written down, priced or estimated, and you approve it before work starts. A poor answer is either "we'll be flexible", which tends to mean the change appears on a final invoice, or "no changes", which means you will receive exactly what was written months ago whether or not it still makes sense.
2. How often will I see working software?
This is the single most useful question on the list.
"At the end" is the wrong answer. Projects that disappear for two months and reappear with a finished product are the ones that most often reappear with the wrong product. Weekly or fortnightly demos of something you can actually click through keep everyone honest, surface misunderstandings while they are cheap to fix, and give you a clear picture of progress that does not depend on status reports.
3. What do you test, and how?
Nobody tests everything, and a vendor who claims to is either overstating or overcharging. A good answer names the critical paths: the steps where a failure costs money or trust, such as payments, bookings, and anything that sends a message to a customer. Those should have automated tests, so they are checked every time the code changes, not just on the day someone remembers.
4. Who owns the code and the accounts?
The answer should be you, from the first day, with the repository and every service account registered to your business and the developer invited in. We wrote about why this matters in our post on owning your code. If the answer is hesitant, or ownership only transfers at the end, ask why.
5. What does handover include?
Handover is where many projects quietly fall short. Ask specifically: will there be written documentation that another developer could use to run and deploy the system? Will all the credentials be in a place you control and can change? Will someone walk you through how it works?
A vague answer here usually means handover is whatever is left when the budget runs out.
6. What happens after launch?
Software needs looking after. Bugs surface once real users arrive, third-party services change, and small improvements accumulate. Ask who fixes problems after launch, how quickly, whether there is a warranty period, and what support costs once it ends.
There is no single right answer. Some businesses want an ongoing arrangement; others prefer to call when they need something. What matters is that the answer exists before you need it.
How the answer is given matters as much as the answer
Listen to the tone as well as the content. Vague confidence, "don't worry, we've done this many times", is a warning sign however impressive the portfolio. Specific, slightly boring process, with named steps and documents, is a good sign.
It is also fair to ask for the answers in writing. A vendor who describes a good process in a meeting should have no difficulty putting it in the proposal.
We are happy to be asked all six. Our packages set out the answers in advance: weekly demos on the App MVP, work beyond the agreed scope quoted before it is built, a repository and accounts you own, and documentation and handover at the end.
