Q.What Should You Ask a Software Vendor Before You Sign?
Ask who owns the code, what "done" means in writing, what happens when the scope changes, when you will first see something running, and who you call in eighteen months. If a vendor cannot answer those five clearly and in writing, the price on the quote is not the number you will pay.
Buying custom software is unlike buying almost anything else a distributor or manufacturer buys. There is no spec sheet, no reference installation you can go look at, no trade body setting a standard. You are being asked to pay for something that does not exist yet, described in a document written by the person selling it.
The questions below are the ones that actually predict how a project goes. Most of them are commercial and organizational rather than technical, because that is where these projects fail.
The Five That Matter Most
1. Who owns the code, the accounts, and the data?
The answer should be: you do, all of it, from the first day.
That means the source code in a repository you own, the hosting and database accounts in your name with your billing, the domain in your name, and an export of your data in a usable format whenever you ask. Not "we'll provide access." Yours.
This one question filters out a large share of bad arrangements, because a vendor who keeps the code has built a switching cost into the relationship instead of earning it. Ask for it in writing in the agreement, not as a verbal reassurance.
2. What does "done" mean, and is it fixed in writing before work starts?
You want a written scope and a fixed price agreed before anyone writes code — not an estimate, not a range with an asterisk, not an hourly rate against a requirements document that will keep growing.
Hourly billing against an open scope puts you and the vendor on opposite sides of every conversation for the whole project. Every question you ask costs you money; every hour they spend earns them money. Nine months in, nobody is happy and nothing is in production.
A fixed scope forces the hard conversation to happen at the start, when it is cheap, instead of at month six, when it is expensive and personal.
3. When will I first see something actually running?
The answer should be measured in weeks, and it should be a live link, not a slideshow or a clickable mockup.
This matters more than it sounds. A system in production gets honest feedback — your people use it and tell you what is wrong. A system in a demo environment gets opinions. Every long project that failed had a long gap at the start where there was nothing to look at, and that gap is where the divergence between what you meant and what they heard quietly grows.
If a vendor's plan has you seeing nothing real for three months, ask them to carve out a first slice that does one thing end to end, and judge them on that.
4. What happens when we want something changed?
There is no correct answer here except "there is a defined process, and it is priced and scheduled."
What you are testing for is whether the vendor will absorb changes silently. That sounds generous. It is the single most reliable predictor of a project that slips, because absorbed changes do not disappear — they come out of the timeline, and then out of the quality, and then out of the relationship.
A vendor who says "small things we just do; anything that moves the date gets written up, priced and scheduled, and you decide" is telling you they have run projects before.
5. Who do I call in eighteen months?
Software is not a thing you buy once. Items change, tax rules change, an integration partner deprecates an endpoint, someone leaves and their access needs reassigning.
Ask specifically: what does support cost, what does it cover, what is the response time, and what happens if you want to stop paying it. And ask what happens if the vendor disappears — which is the honest reason question 1 matters. If you own the code and the accounts, any competent developer can pick it up. If you do not, you are starting over.
Seven More Worth Asking
- "What is explicitly not included?" A good scope document has an exclusions list. If there isn't one, write down the three things you are assuming are included and ask for them to be confirmed in writing.
- "How does our existing data get in?" Data migration is where timelines die. Ask who cleans the item file, who maps the customers, and how many rounds of that are included.
- "What happens to orders if this system is down for a day?" You need an answer that does not stop your business. Usually it is as simple as email and phone still working, but the vendor should have thought about it.
- "Who else can touch our production data, and how?" Ask how many people at the vendor have access, whether access is removed when someone leaves, and whether anything is copied to a laptop.
- "Can we talk to a customer you built something like this for?" Not a logo on a slide — a person on a phone. If confidentiality prevents it, that is a legitimate answer, but then ask what they can show you that is real and live.
- "What will you need from us, and how many hours a week?" Every build needs somebody on your side to answer questions and make decisions. A vendor who says "almost nothing" has not thought about it, and you will find out in week four.
- "What would make you tell us not to build this?" The most useful question on the list. A vendor who cannot name a scenario where buying a product or doing nothing beats hiring them is selling, not advising.
Want this looked at for your operation?
Twenty minutes on a call, and you'll know whether this is worth building, buying, or leaving alone. No deck, no pitch.
Book twenty minutesThe Answers That Should Worry You
| What you hear | What it usually means |
|---|---|
| "We'll scope it as we go" | The price on the quote is an opening number |
| "We host it on our platform" | The code and the switching cost are theirs, not yours |
| "You'll see it when it's ready" | Nothing real for months; divergence is being deferred, not avoided |
| "Changes? We'll take care of it" | Changes will be absorbed into the timeline until the timeline breaks |
| "It'll do everything the big systems do" | Nobody has decided what it will not do, so it will never finish |
| "We do everything — we'll build whatever you need" | No opinion about your industry; you will be paying them to learn it |
The Question to Ask Yourself, Not Them
Before any of the above: what is the specific thing that is costing you money right now, and how would you know it had been fixed?
"We need to modernize" is not a project. "Orders come in by phone and email, two people spend most of their morning typing them into the system, and we ship the wrong thing about once a week" is a project — and it comes with its own success measure, which is the number of orders that arrive without anyone typing and the number of shipping errors per month.
If you cannot state the problem in that shape, the quote you are holding is for a system nobody has defined, and no amount of diligence on the vendor will save it. Go back and write the sentence first. It is also, by some distance, the fastest way to get a useful quote out of anybody.
FAQ
Q: Should custom software be quoted as a fixed price or by the hour? A: Fixed price, agreed in writing before work starts, with changes priced and scheduled separately. Hourly billing against an open scope puts the buyer and the builder on opposite sides of every conversation and is the shape of most projects that end with nothing in production.
Q: Who should own the code for custom software we paid for? A: You should — the source code, the hosting and database accounts, the domain and an export of your data, all in your name from the first day. A vendor who keeps the code has built a switching cost into the relationship instead of earning it, and if they disappear you start over.
Q: How quickly should we expect to see a working version? A: Weeks, as a live link you can use, not a mockup. Long projects fail in the silent gap at the start, where the difference between what you meant and what the builder heard grows unseen. If the plan shows nothing real for three months, ask for a first slice that does one thing end to end.
Q: What is the most useful question to ask a software vendor? A: "What would make you tell us not to build this?" A vendor who cannot describe a situation where buying an off-the-shelf product, or doing nothing, beats hiring them is selling rather than advising.
Read us often? You can add Futurise as a preferred source in your own Google account.