Start with your problem, not their pitch
Most bad vendor choices begin with a vague brief. Before you contact anyone, write one page that says what the business problem is, who will use the software, what must be true at launch and what is explicitly out of scope. A partner can only be judged against something concrete, and the exercise often reveals that you are not yet sure what you want. That is useful to learn before spending money.
Add your constraints honestly: budget range, deadline and why it matters, systems you must integrate with and any regulatory requirements. Vendors who see the real constraints can tell you what is feasible. Vendors who only see an open-ended wish list will quote to win the work, not to deliver it.
What evidence to ask for
Claims are cheap; evidence is not. Ask every shortlisted partner for the same things so you can compare them fairly:
- Relevant work you can inspect: live products, demos or code samples, not just logos.
- References you can actually call, ideally from a project similar in size and type to yours.
- The names and roles of the people who would work on your project, not only the sales contact.
- A sample of their documentation, test approach and release process.
- How they handle a project that goes wrong: a specific past example is more useful than a slogan.
A young company will have a shorter track record, and that is fine as long as it says so. What matters is whether the answers are specific. A partner who can explain a past mistake and what they changed afterwards is usually more trustworthy than one who has never had a problem.
Questions about how they work
Process questions reveal more than technology questions. Ask how requirements are captured and changed, how often you will see working software, who you speak to day to day and how progress is reported. Look for short feedback cycles: demonstrations every one to two weeks beat a long silence followed by a big reveal.
Ask how they test. Automated tests, code review and a staging environment are baseline practices; if the answer is that testing happens at the end, expect surprises at the end. Ask what happens to your code, data and credentials during the project, and who has access to them.
Contracts, ownership and exit
Read the contract for the things that hurt later. Intellectual property should transfer to you, ideally on payment, and the source code should live in a repository you control from day one. Check what you receive at handover: documentation, deployment scripts, environment configuration and credentials.
- Who owns the code and any third-party components, and under what licences?
- What is the notice period and what is handed over if either side ends the engagement?
- How are changes to scope priced and approved?
- What warranty or bug-fix period follows launch, and what does ongoing support cost?
- Is there a confidentiality agreement before you share sensitive material?
A good partner makes it easy to leave. If you could not move to another team without a fight, that is a risk worth pricing in.
Comparing quotes fairly
Do not simply pick the lowest number. Two quotes for the same brief can describe very different projects. Compare what is included: design, testing, deployment, documentation, project management and post-launch support. Ask each vendor to list its assumptions; the assumptions are where cost overruns hide.
Be aware of how the pricing model shifts risk. A fixed price puts delivery risk on the vendor but only works when scope is clear; time and materials suits evolving products but needs your attention to control spend; a dedicated team suits long-running work. If a vendor recommends a model, ask why it suits your situation rather than theirs.
Start small, then decide
The safest way to evaluate a partner is to work with them. Propose a short paid discovery phase or a small, well-bounded first deliverable. You will learn how they communicate, how they handle disagreement and how good their work really is, at a fraction of the cost of a full project.
Pay attention to behaviour during that phase. Do they ask hard questions? Do they tell you when something is a bad idea? Do they deliver what they said when they said it? Those habits predict the rest of the engagement better than any sales presentation.
Warning signs
- Guaranteed outcomes or timelines without having asked detailed questions.
- Reluctance to let you speak with the people who will do the work.
- No written scope, or a scope that changes whenever it suits them.
- Pressure to sign quickly or discounts that expire in days.
- Vague answers about code ownership, security or data handling.
None of these alone is conclusive, but several together are a reason to walk away. Trust your own questions: if you cannot get a clear answer, assume the answer is not one you want.