What to ask a software vendor before you sign

When you buy a machine, you know what to ask: what it produces, what it consumes, what warranty it has, who repairs it. When you buy custom-built software, you don't really have a reference — and the lack of these reference points can cause problems later in the working relationship.

The list below is written from your perspective, the one signing. These aren't technical questions. They're the questions that show what the relationship will look like a year from now, once the initial enthusiasm has worn off.

1. Who owns the data, and how do I get it out of the system

One of the first questions. The data in the system — clients, quotes, prices, orders, history — belongs to your company. You need a clear answer to:

• can I export the data any time, on my own, without asking anyone?
• what format does it come out in — one that another program can read, or just a file of theirs?
• if I end the collaboration tomorrow, what do I take with me?

A serious vendor answers immediately and without hedging. If the answer is vague or conditional, you've learned something important.

2. What happens with the code

Software built for you doesn't automatically mean it's yours. There are several possible arrangements, all legitimate, but you need to know which one you're in:

• the code belongs to you and you receive it;
• the code belongs to the vendor, and you have a right to use it;
• an intermediate arrangement — exclusive licence, with access to the code under certain conditions.

What matters isn't so much which arrangement it is, but that it's written into the contract before you sign, not discussed afterwards.

3. Who else, besides you, can work on the system

A simple question with big implications: if in two years I want someone else to continue, can they?

What the answer shows: if the system is built on well-known, documented technologies, any competent team can take over. If it's built on something only they use, you have one possible vendor forever — and they know it.

4. What counts as a "change" and how is it charged

Misunderstandings often arise here. After launch, requests for changes are very likely to appear, because that's when your people actually understand what they want.

Ask beforehand:

• how is a change estimated, and who confirms the estimate;
• what's included in maintenance and what's billed separately;
• what happens with bugs — is a bug in an already-paid-for feature fixed under warranty, or billed?

The difference between "fix" and "change" needs to be defined in the contract, not negotiated in the middle of a problem.

5. What does handover look like

A project isn't finished when the system works, but when your people use it without having to ask anyone.

Ask what you receive at the end: usage instructions for each role in the company, a training session, a document explaining where the data lives and how to make a catalogue change without help. Without these, you stay dependent for routine operations.

6. What happens if you want to stop

This isn't a hostile question, it's an administrator's question. How is the collaboration ended, with what notice, what do you receive on the way out, how long do you still have access to the system afterwards.

A vendor who has built the relationship properly has nothing to hide here. One who relies on the fact that you can't leave will avoid the subject.

7. Who's the person I'll be talking to in six months

Often you talk to someone who sells well and then work with someone else. Ask who the contact person is after launch, how a problem is reported, and what response time is usual. You don't need spectacular promises — you need a concrete, consistent answer.

8. How do you work if the scope changes along the way

It's quite possible that the project's requirements will change along the way. The useful question isn't "can it change?" but "how do we decide together what's in scope and what isn't."

A vendor who says "yes" to everything, without ever discussing what comes out of scope in return, will deliver either later or less than you thought. A vendor who refuses any change in scope will deliver exactly what you asked for at the start, even if it's since proven wrong.

9. Can I see it working on my own case before I sign

The simplest check. Not a generic demo, but something built on your data — even a partial example, on a single product.

If the vendor can build a relevant example for your case, it's a sign they've started to understand the process, not just the technical requirement. If they can't show anything until you sign, you're buying a description.

10. What I shouldn't do with you

A good vendor knows where they're not the right fit. Maybe you need standard software, not something custom-built. Maybe your problem is in the process, not the software, and any system would just lock in the same chaos, faster.

Whoever says this from the start saves you money. Whoever accepts any project sells you what you asked for, not what you need.

---

If you're at the point of comparing several offers, it's useful to start from a map of your process, not from a list of features. In the free audit we take apart your current quoting flow, and you keep it regardless of who you work with afterwards. And how we work is described step by step, so you know what you're looking at when comparing.