Choosing who builds your system is harder than choosing the system. Proposals look alike, they all promise the same things, and you can rarely compare the work until you have already paid. These are the seven questions that separate a serious proposal from one that will cost you twice as much, whether you ask them of us or of anyone else.
1. Is the price fixed, or is it an estimate?
An estimate goes up. A fixed price on a defined scope, in writing, does not. Ask what happens if something unforeseen comes up: the reasonable answer is that it is quoted separately and only goes ahead with your approval, not that it gets added to the invoice.
If a proposal does not detail what it includes, it cannot say what it costs either.
2. When do you pay, and in exchange for what?
Be wary of a large advance followed by months without seeing anything. The healthy way is to pay by milestones: each payment matches a delivery you can already use and that you sign off before moving on. If something is going wrong, you find out in week two rather than in the last one.
3. Do you see the design before it is built?
Fixing a screen in a mock-up takes minutes; fixing it once it is coded takes days. Ask for flows and screens to be designed and validated with you before any code is written. It is the best way to know, before paying for development, whether they understood your operation.
4. Who owns the code when it is finished?
It is the question almost nobody asks and the one that hurts most later. If the code, the database and the documentation are not yours, you cannot change vendor without starting from scratch. It has to be in writing that the intellectual property is transferred to your company.
5. What happens when something fails after delivery?
Every system has bugs that only show up in real use. Ask how long the warranty lasts, what it covers and how fast they respond to a serious incident. "We will support you" is not an answer. A deadline is.
6. Can you see something of theirs running?
Not screenshots or mock-ups: systems in production, with an address you can open. Better still if they are the same kind of thing you need, because a company that makes good websites does not necessarily know how to build an inventory system.
7. Do they say no when they should?
A company that accepts everything you ask for, on the timeline you ask for, either did not understand the project or does not intend to deliver it. The sign that you are being taken seriously is that they argue with your scope: what is better left for a second phase, what is not worth what it costs, and sometimes that you do not need a custom system at all.
How to use this list
Take the seven questions to every meeting and write the answers down side by side. The cheapest proposal rarely wins on all seven, and the price difference usually sits exactly in the ones it does not answer.
At xPlain all seven have an answer in writing: fixed price, payment by milestones, design validated before code, 100% ownership and a 12-month warranty. You can see how we work, look at projects in production or tell us what you need.