Almost nobody buys software development twice a year. So you will evaluate vendors with very little practice, against proposals written to look alike, in a vocabulary that is not yours.
The fastest way out of that is not learning technology. It is asking questions whose answers cannot be dressed up. A vendor who has already put systems into production answers these twelve in two minutes without checking their notes. One who is going to learn on your project hedges, generalises or promises.
Each question comes with why it matters and the answer that should worry you. None of them requires you to write code.
About who does the work
1. Who writes the code: the person I am talking to, or somebody else?
It matters because the person selling and the person building are rarely the same, and everything lost between them you pay for in misunderstandings. Worry if the answer is "we have a team" with no names, no roles, and no clarity about who you talk to when something breaks.
2. Who is my point of contact, and what happens if that person leaves?
It matters because projects slip on communication far more often than on difficulty. A single named contact removes half of those slips. Worry if you are assigned a channel instead of a person, or if the answer is "just message the group".
3. What language do you work in: meetings, documentation, deliverables?
It matters if your operation is bilingual, if you have partners abroad, or if your technical team and your board do not read the same things. Documentation in a language half your people do not use is documentation that does not exist. Worry about a quick "no problem" that later arrives as machine translation.
About what you are left with
4. Do the code and the assets end up in my name at delivery?
This is the most important of the twelve and the most expensive one to discover late. If the repository, the design files and the brand book are not yours, you did not buy a system. You rented access to one. Worry about any answer that talks about a licence to use rather than ownership, and about any answer that is not written into the proposal. Ask about the rest too: domain, hosting accounts, database and admin access. It is common for the code to end up in your name and the infrastructure not to, and the day you want to move is a late day to find out.
5. What documentation do I receive, and in what format?
It matters because a system without documentation is a system with exactly one possible vendor, which leaves you with no negotiating position the day you want to change. Worry about "the code is commented". Comments are not documentation: ask whether you get the data model, the architecture decisions, the credentials and the deployment procedure.
6. What training does delivery include?
It matters because a system your team cannot operate has not been delivered, it has been parked. Training is the first thing cut when somebody wants to lower a price. Worry if it is "we will send you a video", or if it does not appear in the proposal at all.
About what happens after delivery
7. What happens the day after delivery?
It matters because the real fear of buying this is paying and being left alone. An included support window, with defined scope, is the difference between a partner and a seller. Worry if support only exists as a separate contract quoted later.
8. What is your response time commitment?
It matters because "we reply quickly" is an intention, not a commitment. A number of business hours, in writing, is one. Worry if the number does not exist, or if it exists only on the most expensive plan.
9. How many revision rounds are included, and where is that written?
It matters because revisions with no agreed limit are the single most common source of friction at the end of a project, and they end badly for both sides. Worry equally about "as many as you need" and about silence: the first is unsustainable and the second becomes an argument at the worst possible moment.
About what happens when things change
10. What happens if the scope changes mid-project?
It matters because scope always changes. What marks a serious vendor is not denying that, it is having a procedure: how a change is assessed, who approves it, and how it is quoted before anyone starts working. Worry about "we'll figure it out", which is the sentence that precedes the surprise invoice. The opposite also applies: if the procedure is so rigid that any minor adjustment opens a negotiation, the project gets slow for a different reason. What you want is an agreed threshold, not the absence of a procedure.
11. How do you handle migrating my existing data?
It matters because your old data is dirty, and cleaning it is a business conversation rather than a technical task. If the proposal does not mention it, or does not price it, somebody will discover it halfway through. Worry about "we'll just import it" from someone who has not seen your data.
12. Have you put something like this into production, or would mine be the first?
It matters because shipping something and building it are different jobs, and the second is learned by doing the first. You do not need them to have built exactly your thing. You need them to have kept something comparable running. Worry about an answer in the conditional, or a portfolio of pieces that never went live.
Read the set, not each answer on its own
None of the twelve gets answered badly on purpose. What separates one vendor from another is not scoring eleven out of twelve: it is the pattern the answers form together, and there are three worth recognising.
The first is the one who answers everything easily and nothing in writing. The conversation is excellent, the person is likeable and clearly knows the subject, and then the proposal has half a page of scope. The risk there is not capability. It is that nothing they told you is enforceable on the day you need to enforce it.
The second is the one with a document for everything and a decision for nothing. Long proposal, appendices, diagrams, and when you ask who resolves a case nobody anticipated the answer dissolves into process. That usually means the project stops every time something falls outside the plan, and something always falls outside the plan.
The third, the one you want, is boring. Short answers, an explicit list of what is not included, and it is written down. A vendor who tells you no in the first meeting is a vendor who will tell you no when that works in your favour.
One practical note: ask all twelve in writing, even if you already asked them in the meeting. A spoken answer and the same answer in an email resemble each other far less than you would expect, and the gap between the two is exactly the information you are looking for.
The answer no checklist can score
There is something these twelve do not capture, and it is worth saying. A vendor can answer all of them well and still be wrong for your project, because they do not understand your business or because the human fit is not there.
Watch something simpler: how many questions they asked before giving you a number, and whether those questions were about your operation or about your budget. Whoever does not ask is quoting blind, and a blind quote gets corrected later at your expense. That is the same reasoning behind why two quotes for the same project differ so much. If you want to rehearse the twelve with somebody before using them for real, half an hour is enough for that.
And an honest case against everything above: if your problem is a dated regulatory requirement, such as the DTE 2.0 migration in El Salvador, question 12 outweighs the other eleven combined. There you are not buying judgement. You are buying the fact that somebody has already done it.
Before the first meeting
Write the twelve on one page and ask them in the same order to everyone you evaluate. The comparison makes itself: you will not be comparing prices, you will be comparing which vendor was willing to put each answer in writing.
We answer all twelve without preparation and we write them into the proposal, and everything we do is here if you want to see the scope before talking to anyone. If you want to use us as a test run for the questions, the discovery call is thirty minutes, free and no obligation. You can book it here.
Does this apply at your company?
30 minutes, no obligation, to review your case and decide whether there's anything to build.