Choose the software company that asks the sharpest questions about your business, not the one with the glossiest portfolio. The quality of a vendor's discovery process predicts project success better than any reel, because software projects fail on misunderstood requirements far more often than on weak code.

Start with your non-negotiables, then work the 10-point checklist, learn to read a proposal like a reviewer, take sharp questions to the discovery call, and watch for the red flags at the end.

Start with your non-negotiables, not their portfolio

Before you contact any company, write down five things: your budget band, your deadline and why it matters, the three features the project cannot ship without, who on your side will answer questions during the build, and what happens after launch - who fixes bugs, who makes small changes, and what that costs. Put them on one page and send that page with every enquiry; vendors who respond to your actual constraints are already filtering themselves. Vendors scope to constraints; a vendor who never learns your constraints gives you a generic quote. Portfolios are still worth a look, but read them for process evidence - did they ship, maintain and iterate - not for visual polish alone. A company whose past work is all in one industry may also bring useful domain shortcuts, or dangerous assumptions; ask which one it is.

The 10-point evaluation checklist

Score each shortlisted company on these ten points. You do not need perfect tens; you need to know where each vendor is weak before you sign.

  1. Relevant experience. Have they shipped something with similar complexity - similar integrations, similar user roles, similar data - not just a similar industry label.
  2. Discovery process. Do they run a structured discovery before quoting, or quote from your first email? No discovery usually means no understanding.
  3. Technical fit. Can they explain, in plain language, why they recommend their stack for your project - and what they would not use it for.
  4. Proposal quality. Specific scope, named assumptions, listed exclusions, milestones tied to payments. Vague proposals become vague projects.
  5. References you can call. Not logos on a slide - two people who will take a 15-minute call about working with them.
  6. The actual team. Who will do the work day to day, and what happens if that person leaves mid-project.
  7. Communication cadence. How often you see progress - weekly demos beat monthly status reports - and which channel decisions happen in.
  8. Testing approach. Who tests, what "done" means for a feature, and how bugs found after launch are handled.
  9. Post-launch support. A named support arrangement with response times, not a vague promise to "be available".
  10. Contract terms. Who owns the code and when, how change requests are priced, and how either side can exit cleanly.

How to read a proposal like a reviewer

A good proposal reads like a plan, not a brochure. Check that the scope section names concrete deliverables - "admin panel with role-based login, 6 report types, CSV export" - instead of "robust backend system". Compare two scope lines and feel the difference: "payment gateway integration" could mean anything, while "Razorpay integration for UPI and cards, with success/failure webhooks, refund flow in the admin panel, and reconciliation report" is a scope you can hold someone to. Look for an assumptions list: every assumption they state is a misunderstanding you just avoided. Read the exclusions with equal care; "content, third-party fees and app-store accounts excluded" is honest, while no exclusions section means those costs will surprise you later. Milestones should tie payments to demonstrable progress - a working staging link, not a document. And the change-request clause matters more than the price: it tells you what happens the day you realise you need something different, which, on most projects, is inevitable. Our guide to fixed-price versus time-and-materials contracts explains which pricing model fits which situation.

Questions to ask on the discovery call

These six questions reveal more than any capability deck:

  1. What did you not understand about our requirement yet - what do you need from us before you can quote accurately?
  2. Show us something similar you shipped, and tell us what went wrong on it.
  3. Who exactly will work on our project, and how much of their week is ours?
  4. How do you handle a change request mid-project - walk us through the process and the pricing.
  5. What does your testing look like before you call a feature done?
  6. What does handover look like - code access, documentation, credentials, and training - on the day we part ways?

Listen for specifics. "We follow agile with weekly demos and a shared backlog you can reorder" is an answer. "We are very flexible and client-focused" is a slogan. If they cannot describe their process concretely on a call, they will not follow one on your project.

Red flags that predict a painful project

Walk away - or at least slow down - when you see these. A fixed quote issued within a day of your first email, with no discovery, means the vendor priced a guess and will recover the difference through change requests. A team that asks nothing about your business, customers or success metrics will build what you asked for instead of what you need. Beware the single-developer shop with no backup for illness or departure, and the vendor who cannot show you anything they still maintain - shipping is easy, living with software is the skill. Finally, anyone unwilling to put scope, ownership and exit terms in writing is telling you exactly how the dispute will go. Also listen to how they talk about failure: vendors who claim nothing has ever gone wrong are either inexperienced or dishonest. The good ones tell you what broke on a past project and what they changed afterwards. For a structured way to compare what vendors send you, use our vendor proposal evaluation checklist. It also helps to understand the software discovery phase - the step serious vendors never skip.

FAQ

Should we hire a freelancer, a small studio or a large agency?

Choose a freelancer for small, well-defined tasks where you can manage the work yourself. Choose a small studio when you need a team - design, development and testing - with direct access to the people doing the work. Choose a large agency when you need formal process, compliance or the capacity to scale a team quickly. Most SME projects land best with a small studio.

How many companies should we evaluate?

Three serious evaluations is the practical number. One gives you no comparison, five burns weeks of your time. Shortlist on the checklist above, then go deep with three discovery calls.

Is the cheapest quote ever the right choice?

Only when the scopes are genuinely identical - same pages, same features, same exclusions, same support. When scopes differ, the cheapest quote is usually the least complete one, and the missing pieces arrive later as extra bills.

What should the contract definitely include?

Code and IP ownership transferring to you on payment, a written change-request process with pricing, acceptance criteria with a testing window, a bug-fix warranty period after launch, and termination terms that give you the code, credentials and documentation whatever happens.

If you are evaluating vendors now, contact us with your one-page brief.