How to spot a good IT vendor proposal
Every year I help clients review dozens of proposals from IT vendors — software development, ERP implementations, cloud migrations. The same patterns repeat. Here are the signals I look at on first read. Some are in the proposal text itself; others only show up in the conversation around it.
1. The proposal answers your problem, not a generic category
A good vendor read your brief and responds to it specifically. A bad one sends you their services brochure with minimal edits. If you see your name and company in the header but the rest of the text could apply to anyone — that is a warning sign.
Ask yourself: Where in this proposal can I see that the vendor understood our specific business situation?
2. A partner does not flatter you, they educate and push back
A good vendor aiming for a partnership does not just tell you what you want to hear. They do not nod automatically; they try to educate and explain. If they sense you are heading down a path that will hurt you later, they will say so before signing the contract.
A vendor who agrees with everything quickly and without pushback is typically trying to avoid clear contractual obligations. From the start they suspect that meeting the stated requirements will not be easy, or even possible, but they hope to deal with it somehow, or to convince you of an easier (and cheaper for them) path later, when it would be hard for you to back out of anything.
If a vendor instead points out that something is problematic and that the long-term sustainable solution should look different (for example, they want to build a separate integration layer rather than have applications fight over one database), they typically speak from experience. They do not want the deal at any cost; they want to leave behind something they will not be ashamed of and that delivers real value to the customer. That is how a partner behaves.
This is also reflected in how a vendor handles uncertainty. An experienced vendor can identify problematic engagements and adjust accordingly. They might refuse to fix the price before a proper analysis, propose analytical phases, PoCs and MVP stages. When they do this, they know why. It is a sign of experience and natural agility.
When, on the other hand, a vendor asks no questions and finds everything perfectly clear, that is a warning sign. Let vendors ask, give them space and above all give them time. If you want them to assign their best people to analysing your request, expect that they cannot allocate them from one day to the next.
3. The scope of work is described concretely, not just by category
“Analysis and solution design” is a category, not a scope. “Three workshops with key users, output as a functional specification of approximately 30–50 pages” — that is a concrete scope.
Vague scope is usually deliberate. It leaves room for future change orders. With a specific scope, comparing proposals becomes easier and enforcing what was promised becomes possible.
A related signal: a good vendor will refuse to build an application by reverse-engineering an old one. They know it never ends well. They will push you to write down your know-how and to provide capacity and users for formulating a functional specification. Without that, you would sooner or later fail in the project, regardless of which vendor you pick.
4. The price is broken down by line item
A single summary figure is not a proposal — it is a bet. You want to see: how much for analysis, how much for implementation, how much for testing, how much for project management. Not to negotiate every line item, but so it is clear where the reserves are and what happens if scope changes.
If a vendor refuses to break down the price with the explanation that “our process doesn’t work that way” — understand that this makes comparing proposals across vendors effectively impossible.
5. The timeline has clear milestones and concrete deliverables
A start date and an end date are not enough. You want to know: when do you get the first functional output, when does user testing happen, what are the acceptance criteria for each milestone.
And not only that. The vendor’s milestones in the proposal also include concrete deliverables — what is actually being delivered at each milestone. Not just “milestone X completed”, but for example “API documentation v1.0, integration tests with coverage above 70 %, deploy to staging environment”. Without this detail you have no leverage at handover. The vendor can claim it is done; you will have nothing to argue with.
6. It is clear what the vendor needs from you
A good proposal has a section “What we need from you” and that section is concrete. It is not a few generic sentences about “co-operation”, but a specific list:
- Site access, system access, infrastructure such as servers
- Data, documents, approval processes
- Capacity of your people, ideally broken down as who is needed in which phase and for how long
Concreteness in this point is itself a signal. A vendor who states precisely which people from your company they need and when shows you how experienced they are. A rough breakdown is enough, but its presence distinguishes a partner from a vendor who only starts thinking about co-operation when it is already too late.
And one important piece of context: lack of co-operation is the single most common cause of trouble on IT engagements — subjectively even more common than vendor failure. If the proposal does not reflect this, the project will collide with this reality at runtime, usually as slippage and mutual finger-pointing.
7. References are verifiable
“We have experience in banking and retail” means nothing. A verifiable reference is a contact at a real customer who is willing to confirm the project went as planned and the result works. If a vendor refuses to provide references or offers only logos without contacts, ask yourself why.
8. Contract terms are readable and balanced
If the vendor sends you a contract where you commit to whatever “the client deems appropriate” on their side, or where penalties are asymmetric (you pay for every delay, they pay for none), the contract was written for one party only.
You also do not want a contract full of “best effort” language instead of concrete commitments. A good vendor stands behind their proposal and is willing to confirm that contractually.
And when you are the one supplying the contract, watch how the vendor reacts. It is no bad thing if they discuss your contract, propose edits, ask about details. If they sign anything automatically, they probably did not read it — and they are indifferent to it, including the parts about their own obligations. Active discussion in this case is a good sign, not a complication.
9. Prototyping in the AI era
A great vendor builds prototypes for the critical parts. In the age of AI this really is not a problem. Using AI in prototype development lets you verify key assumptions quickly and cheaply. Where building a prototype used to mean a multi-week investment, today a few days are often enough.
If a vendor proposes a small prototype for a risky part of the engagement instead of just fixing the price and hoping for the best, that is a good sign. It shows they do not want to sell certainty they do not have, and that they know how to work with modern tooling. I have written more on this elsewhere — a deeper look at the pitfalls of AI in companies → and how I work with AI in my practice →.
A practical note
The most reliable test of a proposal’s quality is: Could I enforce what was promised based on this document? If the answer is “probably not” — you have a problem before you even sign.
Comparing proposals and evaluating vendors is exactly the kind of work where I can help as an independent advisor. I have no interest in any particular vendor winning — I have an interest in you getting what you ordered.