How to Evaluate a Software Development Vendor: The Questions That Cut Through the Smoke

You have three proposals on the table. All three promise agile methodology, a senior team and fluid communication. The prices differ by 40% and the brochures are indistinguishable: same words, same technology logos, same smiling testimonials. How do you choose without knowing how to code?

The short answer: not by comparing brochures, but by asking questions whose answers can't be polished. This guide collects the questions any non-technical decision-maker can ask, the answers that give away the smoke, and the definitive test that costs less than being wrong.

Why Comparing Proposals Is So Hard

Buying software development means buying something that doesn't exist yet and that you can't inspect before paying. It's the market of asymmetric information: the vendor knows exactly what they can deliver; you can only read what they promise. That's why brochures converge — everyone copies the language of the best seller — and why price doesn't sort anything: the most expensive doesn't guarantee quality and the cheapest hides its cost elsewhere (juniors, turnover, trimmed scope).

The right strategy isn't trying to judge the technology — you can't, and you don't need to — but judging how the people applying it work. Processes can be inspected from the outside.

The Questions That Cut Through the Smoke

Nine questions that require no technical knowledge, ordered from least to most revealing:

1. "Who exactly will be programming, and can I meet them?" Smoke shows when the answer is "we'll assign the right resources". No names means a pool of contractors. Ask also how many simultaneous projects each one carries: the honest answer is usually two; the suspicious one, "as many as needed".
2. "How will I see progress week by week?" The only good answer involves working software you can touch: a demo every week or two, an accessible environment. "We'll send you progress reports" means you'll see everything at the end, when correcting is expensive.
3. "What happens if the key person leaves mid-project?" Every serious vendor has lived this and has an answer: documentation, code reviewed by more than one person, shared knowledge. An awkward silence here is a red flag the size of a mainsail.
4. "Who owns the code, and from when?" The right answer: you, from day one, in a repository you can access. If the code "is delivered at the end", what you're buying is a hostage.
5. "How do you handle scope changes?" Scope will change; the question is how it's charged and communicated. A clear change process (estimate, approval, impact on dates) signals craft. "We're flexible, we'll see" means the other party will decide the invoice.
6. "What does the price include and what doesn't it?" Tests, deployment, documentation, training, first-year maintenance. Many cheap proposals are expensive ones with the invisible surcharge of everything they exclude.
7. "Can I speak to two clients whose project went badly?" Nobody shows their failures; how they talk about them says everything. A vendor who can explain what went wrong and what changed afterwards is more reliable than the one who has "never had a problematic project".
8. "What do you need from my team for this to work?" The mature answer includes your time: weekly decisions, someone with authority to prioritise, access to whoever knows the business. The vendor who "needs nothing from you" is signing up to build what they imagine, not what you need.
9. "How do you measure that the project is going well?" If the metric is "hours worked", you're buying effort, not outcome. Good answers talk about delivered functionality, open and closed issues, sustained pace.

Green Flags and Red Flags

The pattern behind it is simple: green flags are all forms of transparency; red flags are all forms of opacity. A good vendor brings you closer to the real work — the code, the demo, the team — because their work withstands scrutiny. A bad one places pretty documents between you and reality because reality doesn't withstand it.

The Price: What the Fixed Quote Hides

A total fixed price feels safe, but it's worth understanding what you're buying: the vendor estimates, adds a risk buffer (legitimate) and, when the scope moves — and it always moves — the buffer runs out and the extras begin, or the silent quality cuts. The professional alternative isn't a blank cheque: it's a fixed price per short phase, where each phase delivers something usable and the next is estimated with what was learned. If you want to understand how an honest figure is built, we cover it in how much custom software costs.

And a note on aggressive discounts: a 30% cut with no change of scope isn't efficiency, it's a confession that the first figure was inflated — or that the project will be paid for with juniors.

The Definitive Test: the Pilot Project

Everything above filters, but only one thing verifies: working together on something small before signing something big. A paid pilot of two to four weeks — a small but real piece of the project, not an artificial exercise — shows you how the team communicates, what quality it delivers, how it reacts to the first change of mind (request one: that's the moment to test it) and whether the demos were representative.

The vendor who refuses the pilot or turns it into a commercial battle is telling you something important: they'd rather you sign without information. The one who accepts gladly knows it's their best selling argument. The cost of the pilot is a fraction of the cost of discovering the mistake six months in.

Common Buyer Mistakes

1. Requesting three quotes from the same one-page document. With a vague brief, each proposal answers a different imagined project and the figures aren't comparable. Invest a week in the brief: it's the highest-return piece of the whole process.
2. Choosing on price when information is symmetric in the bad way. If all three proposals are equally opaque, the cheapest is only the cheapest of the opaque. Filter by transparency first, compare price afterwards.
3. Signing the whole project at once. Without a pilot and without phases, your only lever is the contract — and contracts get litigated, not executed. The real lever is being able not to renew the next phase.
4. Not reserving your own time. The project needs someone on your side with weekly hours and authority. If nobody has that slot, the problem isn't the vendor.
5. Confusing chemistry with capability. The charming salesperson doesn't write code. Ask to speak with whoever will technically lead your project and put the nine questions to them.

In Short

You can't inspect the software before buying it, but you can inspect the process of whoever builds it: who programs, how progress is visible, who owns the code, what happens when something goes sideways. Green flags are transparency and red flags are opacity. And above any brochure, a paid pilot of a few weeks tells you more than all the references combined. The vendor who takes these questions without discomfort is probably the one you're looking for; the one who dodges them has saved you a headache.

If you're comparing proposals and want a conflict-free second reading — or simply a proposal that withstands the nine questions — let's talk →

Keep reading: Custom software vs SaaS: when to build and when to buy.