Contents
Choose a software development vendor by how they work, not by portfolio and price: how they estimate, show progress, who owns the code and accounts, and what happens when plans slip. All of this can be checked before signing — with questions, a paid pilot and calls with past clients. Below are the questions to ask and the signs of a weak vendor.
What matters most when choosing a vendor?
What matters most is process transparency and how much control you keep over your product. A strong portfolio shows the agency can deliver good projects, but it says nothing about how yours will go — with its deadlines, changing requirements and surprises.
What to look at first:
- how they estimate — by scenario with a breakdown, or one turnkey number;
- how they show progress — regular demos of working software, or monthly reports;
- who owns the code and infrastructure — from day one, or "we'll hand it over at the end";
- who exactly will work on it — named people and roles, or abstract "specialists";
- how changes are handled — whether there is a clear procedure to estimate and approve them.
If you have not yet decided whether you need a vendor at all, start with our comparison of outsourcing and an in-house team.
What should you ask a vendor before signing?
Before signing, ask questions a weak vendor has no concrete answers to. A good vendor answers them easily because this is their everyday work, and often covers them before you ask.
About process and team
- Who will be on the project team and in what roles? Can we talk to the tech lead before we start?
- How often will we see working results rather than reports?
- Which task tracker do you use, and will we have access?
- What happens if a key developer leaves the project?
About code, quality and handover
- Whose accounts will hold the repository, hosting, domains and third-party services?
- How do testing and code review work? What counts as a finished task?
- What documentation will we receive at the end?
- If we decide to continue with another team, what will the handover look like?
Also ask for a sample estimate or report from another project — it shows how the vendor really works.
How do you compare proposals from different vendors?
Compare proposals by scope, not by the total. Two quotes that differ by a factor of two often describe different products: one includes testing, launch and a change buffer, the other only coding against a list of screens.
Put the proposals into one table and check that each covers the essentials:
| What to check | Good sign | Warning sign |
|---|---|---|
| Discovery and design | A separate stage with deliverables: scenarios, prototypes | "We'll clarify as we go" |
| Development estimate | Broken down by scenario or module | One number, no breakdown |
| Testing | Explicitly included with an approach | Not mentioned |
| Launch and infrastructure | Server setup, monitoring, backups | Just "deploy to hosting" |
| Buffer for unknowns | Named and explained | Missing; "fixed" price on vague requirements |
| Post-launch support | Terms and cost described | "We'll discuss later" |
If a proposal is missing a part, ask why. Sometimes it is a deliberate decision, but more often it is work you will need anyway — just billed later as "extra".
Photo: Unsplash
What are the signs of an unreliable vendor?
An unreliable vendor usually shows itself during negotiations: it promises everything fast and cheap, avoids specifics and asks nothing about your business. A good team does the opposite — asks plenty of awkward questions and says honestly what can wait.
Signs that should make you cautious:
- they agree to any deadline and scope without a single clarifying question;
- they quote an exact price for a complex product after a five-minute call;
- they will not set up the repository and infrastructure on your accounts;
- they will not introduce the team until the contract is signed;
- their portfolio is screenshots only, with no live projects or client contacts;
- they propose starting development without scenarios "so as not to waste time".
How do you reduce risk before a large project?
Reduce risk with a small paid stage before the main work — discovery, a prototype or the first user scenario. Within a few weeks you see how the vendor communicates, keeps deadlines and writes code, and the cost of a mistake is capped at that stage.
What else helps:
- Talk to one or two of the vendor's past clients, ideally ones whose projects are now in support.
- Ask an independent developer to review the pilot's code.
- Put code ownership, regular demos and the handover procedure in the contract.
- Pay in stages for accepted results rather than upfront for the whole project.
The pilot's output — for example, scenarios written following the structure of a good specification — stays with you even if you continue with another team.
In short
- Choose by process and transparency, not just portfolio and price.
- Ask about the team, demos, account ownership, testing and handover before signing.
- Compare quotes by scope: testing, launch and a buffer for unknowns belong in every one.
- Warning signs: promises without questions, prices without breakdowns, refusing to hand over access.
- Start with a small paid stage — the cheapest way to test a vendor.
FAQ
Where do you find a development vendor?
Referrals from companies with a similar product already running are the most reliable source. Agency rankings and directories help build a shortlist, but make the final choice after talking to the team and running a pilot.
How many vendors should we consider?
Three to five is usually enough. More are hard to compare meaningfully, and in-depth conversations take time better spent on a pilot with one or two finalists.
Should we sign an NDA before discussing the project?
If you are sharing trade secrets or customer data, yes. A first conversation about a product idea usually does not need one: the value is in execution, and vendors rarely copy client ideas.
What should we do if the vendor keeps missing deadlines?
First find the cause: waiting on client decisions, underestimation or team problems. If the cause is on the vendor's side and does not go away, start preparing a handover while the code and access are in your hands.
