Should we ask for references or case studies?

Ask, but weigh them lightly. References are selected by the vendor and case studies are written by them. A reference call is most useful when you skip the success story and ask what went wrong and how it was handled, which is the part that predicts your own experience.

Does it matter which technologies a vendor uses?

Less than most procurement processes assume, as long as the choices are mainstream, maintained and something other developers could pick up. The right question is not which framework, but whether you could hire someone else to work on it in three years.

Is a bigger company a safer choice?

It changes the risk rather than removing it. Larger firms offer continuity and process; smaller ones offer the people who sold the work actually doing it. Either can go badly. The five questions above discriminate better than headcount does.

How many vendors should we approach?

Three is usually enough if you have a written scope, and too few if you do not. Without a scope you are not comparing quotes, you are comparing interpretations, and more of those does not help.

Should the first phase be paid discovery?

Usually yes, and treat free discovery with some caution. Work that is genuinely valuable takes real time, and if it is unpaid it is being recovered somewhere else in the price, or it is not very deep.

Questions to Ask a Software Vendor

By the time you are comparing quotes, the proposals all look similar. They describe outcomes, they list technologies, and they are priced within range of each other because everyone is pricing against the same vague brief.

These five questions are the ones that separate them. Ask all of them, in a call rather than in writing, and pay attention to how quickly the answers come.

1. Who is responsible for this system twelve months after launch, by name?

Not which company. Which person, in which role, with what response commitment. Ownership after launch defaults to nobody unless it is assigned in writing, and this is the question that flushes that out before it matters.

A good answer names a role and describes what happens when that person leaves. A weak answer is a support email address and a reassuring tone.

2. What will you be monitoring, and where do I see it?

Most vendors monitor something. Far fewer can tell you what, and fewer still will give you access to it.

Listen for whether they are measuring the server responding or a customer completing a purchase. Those are very different things, and only one of them is what your business cares about. If the dashboard is something you can log into rather than something described to you quarterly, better again. The distinction matters enough that we wrote a whole piece on it.

3. When a dependency ships a security patch, what actually happens?

Every system is built on libraries that get updated, and some of those updates are security fixes with a clock on them. The question is whether anyone is watching, and who pays.

A clear answer covers three things: how they find out, how quickly routine and urgent patches get applied, and whether that work is inside the support agreement or billed. Hesitation here usually means patching happens when something breaks.

This is the question most likely to produce an honest pause. A pause is fine. A confident non-answer is the warning sign.

4. If we part ways, what do I own?

Three separate things, and they are often answered as if they were one: the source code, the data, and the deployment.

The code. Who holds copyright, and is it assigned on payment or licensed to you? Where does the repository live, and do you have access today rather than on request?
The data. Can you get a complete export in a documented format, without asking, at any time?
The deployment. Are the hosting accounts, domains and certificates in your name, or in theirs? This is the one that quietly traps people.

A vendor who is comfortable with all three is a vendor who expects to keep the work by being useful rather than by being difficult to leave.

5. Show me the written scope. Not the proposal. The scope.

A proposal describes outcomes. A scope describes decisions: the workflows step by step including exceptions, who can see and do what by role, the data model at entity level, every integration named with its direction, and what is explicitly out.

If the document you are being asked to sign against is a feature list with checkmarks, the project has no agreed definition of done, and every disagreement later is a negotiation. How to write a software scope sets out what a real one contains — and writing your own first is the single best thing you can do for the quality of the quotes you get back.

How to read the answers

You are not grading on polish. You are listening for whether the answers are specific and whether they have obviously been given before.

Specific and quick means they have lived with the consequences of getting it wrong.
Specific and slow is fine, often better. It means they are thinking about your case rather than reciting.
Vague but confident is the pattern to worry about, particularly on patching and ownership.
Redirecting to timeline or price is itself an answer. It tells you which parts of the engagement they have thought hardest about.

One last thing worth doing: ask what they would refuse to build. Everyone has something, and a vendor who cannot name one has either not been doing this long or will agree to anything on the call and renegotiate it later.

If you would like to put these to us, that is a reasonable way to start a conversation — get in touch, or read how we work first, where most of the answers are already written down.

Questions we get asked

Frequently asked

Should we ask for references or case studies?: Ask, but weigh them lightly. References are selected by the vendor and case studies are written by them. A reference call is most useful when you skip the success story and ask what went wrong and how it was handled, which is the part that predicts your own experience.
Does it matter which technologies a vendor uses?: Less than most procurement processes assume, as long as the choices are mainstream, maintained and something other developers could pick up. The right question is not which framework, but whether you could hire someone else to work on it in three years.
Is a bigger company a safer choice?: It changes the risk rather than removing it. Larger firms offer continuity and process; smaller ones offer the people who sold the work actually doing it. Either can go badly. The five questions above discriminate better than headcount does.
How many vendors should we approach?: Three is usually enough if you have a written scope, and too few if you do not. Without a scope you are not comparing quotes, you are comparing interpretations, and more of those does not help.
Should the first phase be paid discovery?: Usually yes, and treat free discovery with some caution. Work that is genuinely valuable takes real time, and if it is unpaid it is being recovered somewhere else in the price, or it is not very deep.

Tell us what you are planning.

A new platform, a replacement for something that no longer fits, or a product that needs someone keeping watch over it. Start with a conversation.

Start a conversation hello@agrivisionai.org