In this article (21 sections)
Choosing a software vendor has a structural problem: the information asymmetry is total. You can't evaluate the technical quality of what you're being offered, and they know it. Every portfolio looks good, the technologies everyone names are the same, and the quotes can't be compared against each other because each vendor understood something different.
The way out isn't learning to code. It's asking questions whose answers reveal how the vendor works, without you needing to understand the technology. Here are twelve, in the order worth asking them, with what you need to hear in each case.
On the project and the scope
1. How do you get to a number? What do you do before quoting?
What you're looking for: some discovery process beforehand, even a short one. Some form of finding out before the price.
Red flag: a formal quote after a thirty-minute call. That isn't speed, it's guessing. That number either has an enormous cushion in it or it's going to grow in month two.
2. What is explicitly out of scope?
What you're looking for: that they have an answer ready. Teams that have worked seriously at a fixed price know the exclusions document matters as much as the inclusions one.
Red flag: "everything you need is included." It's impossible, and it guarantees an argument in month three.
3. How do you handle scope changes?
What you're looking for: a concrete mechanism. How a change is requested, how it's priced, who approves it, what happens with small ones.
Red flag: the question making them uncomfortable, or "we'll figure that out as we go." Changes are going to show up no matter what. The difference between a healthy project and a contentious one is whether the mechanism existed before the first change.
On the team
4. Who is going to work on my project? Name and role.
What you're looking for: specific names and real availability. Ideally, meeting the person who'll be on it every day.
Red flag: "a team of seniors" with no names. Selling with the strong profiles and staffing with whoever is free is common, and hard to detect after the fact.
5. How many projects is that person on at the same time?
What you're looking for: an honest answer and a reasonable number. Someone on two projects isn't a problem; someone on five is on none of them.
Red flag: them not knowing.
6. Who is my contact, and how often do we talk?
What you're looking for: a named person and a fixed cadence. A short weekly call beats "write to us whenever you need something."
Red flag: the only contact being a salesperson with no technical access to the project. You'll spend months playing telephone.
On how they work
7. How often will I see something working?
This is the most important question on the list.
What you're looking for: verifiable deliveries every one or two weeks. Not presentations or progress reports: the system running, in an environment you can log into and try.
Red flag: "we'll show you when it's ready." Four months without seeing anything is four months without being able to detect that something different from what you asked for is being built. Projects that fail almost never fail all at once: they fail gradually, with nobody looking.
8. How do I check that what you delivered is right?
What you're looking for: written acceptance criteria per feature. Something as simple as "when the user does X, the system has to do Y."
Red flag: acceptance resting on a general impression. Without criteria, arguing about whether something is finished becomes a matter of opinion.
9. What happens if a bug shows up after delivery?
What you're looking for: an explicit warranty period —thirty, sixty or ninety days are the usual numbers— with a clear line between a bug and a new feature. And a committed response time.
Red flag: no warranty at all, or every bug being quoted as additional work.
On what's left when it's over
10. Is the code mine? Where does it live?
What you're looking for: a repository in your company's name from day one, with you as the owner and them as collaborators. Not the other way around.
Red flag: any version of "we hand it over at the end." The code has to be in your hands while it's being written, not when the relationship ends.
11. Whose name are the infrastructure and the accounts in?
This question gets forgotten and it's the one that ties you down the most. Server, database, domain, Google Play and Apple accounts, third-party services, payment gateways.
What you're looking for: all of it in your company's name, with you as the administrator, and them holding access you can revoke.
Red flag: everything in the vendor's name "for convenience." It's convenient right up until the day you want to leave.
12. What documentation do I get?
What you're looking for: at minimum, how to stand the system up from scratch, which external services it uses and with which credentials, and a usage manual for your team. It doesn't need to be a treatise; it needs to be enough for another team to pick the project up.
Red flag: "the code documents itself."
Two checks worth more than the twelve questions
Ask to talk to a client whose project finished more than a year ago
Not the star client from last quarter. An old one. And ask them three specific things:
- Did the final budget match the original one? If not, why?
- How late was it against what was promised?
- What happened when you needed a change after it was finished?
The answers to those three say more than any portfolio.
Ask to see a real scope document from another project
With the client's details blacked out. The project itself doesn't matter: the level of detail does. You'll see immediately whether their documents define verifiable things or whether they're wish lists.
A vendor that works seriously will show you one without hesitating. One that has no documents like that will stall.
How to compare quotes that aren't comparable
If you asked for three quotes and got three different things back, it's because each vendor understood a different project. The fix isn't asking for clarifications: it's giving all of them the same document.
Write it yourself —or pay for a short discovery phase— covering: what the system has to be able to do on its first day in production, who uses it, what it integrates with, and what's explicitly deferred to a second phase. Send it to all three.
The quotes that come back will be comparable. And the process has a bonus: how they react to that document is valuable information. The one who reads it and comes back with uncomfortable questions and observations about things you hadn't thought of is probably the one you want to work with. The one who reads it and only puts a number on it isn't.
What not to weigh so heavily
To close, three things that get more weight than they deserve:
- The list of technologies. Almost everyone uses the same ones. What makes the difference isn't the tool, it's how they use it.
- The size of the company. A focused team of five can outperform a team of fifty that assigns you whoever is free. What matters is who works on yours.
- The visual portfolio. Screens looking nice says nothing about whether the system worked, whether it shipped on time, or whether the client still uses it.
What does matter: how often you'll see something working, what happens when something changes, and whose code it is when this is over.