Summary:
- A fixed price without discovery means the number came from a template.
- The team that sells and the team that builds are often not the same; ask.
- Refusing to discuss ownership is disqualifying, not a negotiation position.
- Ask references what went wrong, not whether they were satisfied.
Choosing a development vendor is difficult because the thing being evaluated is invisible until it exists. What follows is a list of signals that correlate with bad outcomes, drawn from projects we inherited after someone else's engagement ended badly.
Before the proposal
One: nobody asked you anything difficult. A vendor who takes a brief and returns a quote without asking about your existing systems, your users or your constraints has priced a generic project. Yours will differ, and the difference will arrive as change orders.
Two: the estimate arrived immediately. A rough range in a day is reasonable. A fixed price in a day, for a system nobody has examined, is a number produced by a template.
Three: no one mentioned risk. Every project has unknowns. A proposal that presents a clean path with no dependencies or assumptions is either hiding them or has not looked.
In the proposal
Four: the team is unnamed. "A senior developer and a designer" is not a team. Named people, with relevant experience you can verify, and a commitment to notify you of changes.
Five: no assumptions section. A good proposal states what it assumes: that you will provide X, that system Y has a documented interface, that content will be ready by a date. Without that section, every assumption becomes a surprise later.
Six: the timeline has no dependencies. Real timelines include things the client must deliver. A schedule that depends on nothing from you is a schedule that will slip and blame the slip on you.
In the contract
Seven: ownership is vague or the topic is deflected. Ask directly who owns the code. The answer should be immediate and clear. Hesitation here is the strongest single signal on this list.
Eight: no acceptance criteria. Without a testable definition of done, "done" becomes an opinion, and opinions cannot be resolved.
Nine: no defined change process. Changes will happen. If there is no written path for requesting and pricing them, they will be absorbed informally until they are not, and that transition is always unpleasant.
During the first weeks
Ten: you cannot see anything running. If four weeks in there is no environment you can open, something is wrong. It may be that work is happening in a way you cannot verify, or it may be that less is happening than reported. Both are problems and both are visible early.
| Red flag | What it predicts |
|---|---|
| No discovery questions | Change orders within the first month |
| Instant fixed price | A budget that grows or a scope that shrinks |
| Unnamed team | Different people than the ones who sold the work |
| Ownership deflected | Difficulty leaving later |
| Nothing running by week four | Progress that cannot be verified |
Frequently asked questions
Is a fast estimate always a bad sign?
A fast rough range is fine and often helpful. A fast fixed price with no discovery is the warning sign, because it means the number came from a template rather than from your requirements, and templates get corrected later through change orders.
How many questions should a vendor ask before quoting?
Enough to understand who uses the system, what it connects to and what happens when things go wrong. If nobody asked about your existing systems or your users, the estimate is describing a generic project rather than yours.
Should I insist on knowing who will do the work?
Yes. Named people with relevant experience, and a clause that says you will be told if they change. The gap between the team that sells and the team that builds is one of the most common sources of disappointment.
What if a vendor refuses to discuss code ownership?
Treat it as disqualifying. Ownership is a normal commercial term with a normal answer. Discomfort discussing it usually means the answer is one the vendor does not want to say out loud.
Are references from the vendor worth anything?
Curated references have limited value, but the questions you ask them do not. Ask what went wrong and how it was handled. A reference who cannot recall a single problem either did not have a real project or is not being candid.
The signals that mean the opposite
For balance, the things that correlate with good outcomes.
A vendor who tells you not to build something. Advising against work they could bill is the clearest evidence that the advice is about your problem rather than their pipeline.
A vendor who asks about failure. What happens when this integration is down? What does the business do if the system is unavailable for an hour? These questions come from people who have operated software, not just delivered it.
A vendor who gives you a range and explains the spread. "Between X and Y depending on whether your legacy system has a documented interface" is more useful and more honest than a single confident number.
How to test a vendor cheaply
The best evaluation is not a longer proposal process. It is a small piece of paid work before the main engagement.
Something real but contained: an integration, a module, a technical assessment of an existing system. Two to three weeks, paid at normal rates.
What it reveals is everything a proposal cannot.
| What you observe | What it tells you |
|---|---|
| How they ask questions | Whether they are thinking about your problem or executing a template |
| How they report progress | Whether you will have visibility later |
| How they handle a surprise | The single most predictive signal of the whole engagement |
| What the code looks like | Whether another team could pick it up |
| Whether the estimate held | How to read their future estimates |
A vendor confident in their work will welcome this. One who insists on committing to the full engagement up front is telling you something, and it is worth listening to.
The question to ask last
At the end of the evaluation, ask: what would make this project fail?
A vendor with real experience answers immediately and specifically, and usually names something on the client's side: unavailable stakeholders, data quality, an undocumented legacy system. A vendor who says nothing comes to mind has either not done many projects or is not being straight with you.