For buyers
Twelve questions to ask any software vendor
Including us. Print it, take it into every meeting, and write down the answers. The differences between vendors show up here and almost nowhere else.
Most companies choosing a software supplier compare three proposals that all say the same thing in different fonts. These twelve questions produce answers that actually differ, and every one of them predicts something that goes wrong later.
Before you commit
What is the price, and what makes it change?
Listen for: a number, and a written list of what would move it.
Worry if: the answer is a daily rate and an estimate of days. That is a budget, not a price, and it is your risk rather than theirs.
What is the date, and what happens if you miss it?
Listen for: a date in the contract, and a willingness to discuss what follows if it slips.
Worry if: the date only exists in the sales conversation.
Who exactly will do the work, and are they in this meeting?
Listen for: names and roles.
Worry if: the senior people present the proposal and the delivery team is described as “allocated after signature”.
Who else have you done this for, and can I call them?
The one everybody asks and almost nobody follows up on, which is why a confident answer here is worth so little on its own: ask for the name, ask for the number, and then actually make the call, because a supplier who has been asked twice in a year and never checked has learned exactly what that question is worth.
Worry if: you get logos with no names behind them. A logo on a slide is not a reference.
Our answer today is that we have none. We are new, registered in July 2026. It is on our About page, so you did not have to ask.
About what you end up owning
Who owns the source code, and when do I get it?
Listen for: you own it, and it is in your repository from the start.
Worry if: ownership transfers “on final payment”, or the code lives in the vendor’s account. That is not a delivery arrangement, it is a lock.
Whose name is on the cloud accounts and the domain?
Listen for: yours, billed to you.
Worry if: they are on the vendor’s account “for convenience”. Convenience for whom becomes clear during a disagreement.
What tests exist, and what happens when they fail?
Listen for: automated tests, a coverage figure in the contract, and a pipeline that blocks a release when they fail.
Worry if: the answer is “our QA team tests everything”. Ask to see it running.
What documentation do I get, in which language?
Listen for: architecture, runbook and handover notes, in Arabic and English if your team needs both.
Worry if: documentation is a line item you can remove to save money. The version without it costs more the moment anybody leaves.
About risk
Where will our data live, and who on your side can see it?
Listen for: a specific answer about location, access and what crosses the border, agreed in writing before work starts.
Worry if: the answer is “the cloud”. PDPL is enforced, and the liability is yours, not theirs.
Do you use AI to write the code? Who reviews it?
Listen for: a clear yes or no, and if yes, a named human review step and a document describing it.
Worry if: the question makes them uncomfortable. Most firms in this market now use these tools, so a denial is either untrue or a sign they are behind. What matters is whether a person is accountable for what ships.
What does it cost to keep this running for a year?
Listen for: a monthly figure, including hosting, support and patching.
Worry if: nobody has raised it. Support is where the real cost of a cheap build appears, usually in month seven.
If we stop working together, what happens?
Save this one for last, and ask it while they still want the contract. It is the last moment you will get a straight reply.
Listen for: you keep everything, and they will brief whoever comes next.
Worry if: the answer is vague. Or long.
Whatever they say here is the closest thing you will get to a description of how the next two years actually go, because a supplier who has thought about their own exit has thought about everything before it.
Ask all twelve of everyone. If a competitor answers better, use them.
Heavy rain in Riyadh, Saudi Arabia — Synaps commons, CC BY-SA 4.0, via Wikimedia Commons
Why we published this
Two reasons, and one of them is self-interested.
The honest one: a company that chooses badly here loses a year and the budget, and the whole market gets a little more reluctant to buy anything. We would rather compete against a well-informed buyer.
The self-interested one: we score well on these twelve questions and we know it. Fixed price, fixed date, your code from week one, your accounts, tests in the contract, documentation in both languages, a named person on every release, and a clean exit. The one question we lose on is number four, and we say so in writing before you ask it.
Ask all twelve of everyone. If a competitor answers better than we do, use them.