How to tell if a software vendor is selling you smoke

You spot the smoke with five questions, and none of them is technical: what happens to my data if I leave, what exactly does this price cover, who has done something like my case, what does your solution not do, and what will I see running in two weeks. A solid vendor answers all five without getting nervous. The one selling smoke tangles on at least two.

The fourth is the most revealing. Someone who knows their product recites its limits, because they know that's not where they compete. Someone who answers that it does everything, adapts to any process and that AI handles the rest either doesn't know it or is selling. In a one-hour meeting, that question ranks the candidates better than any comparison table.

What questions should you ask before signing?

Six steps, and they all fit in two meetings:

1. Ask what happens to your data if you leave. In what format it comes back, how fast and at what cost. In writing. Evasion here is worth more than any brochure.
2. Make them break the price down by item. Licence, implementation, migration, training, support, future changes. A global number can't be compared with anything.
3. Ask for two references your size and sector. Not logos: companies you can phone. And ask what went wrong, not whether they're happy.
4. Ask what the solution does NOT do. The answer tells you whether they know their product and what you'll have to solve elsewhere.
5. Insist on seeing something running early, with your data. A useful delivery in two or three weeks, however small. Without it, the problems surface in month six.
6. Check ownership, lock-in and exit. Who owns the code, who can maintain it, where the data lives and how the contract ends. An hour of review prevents most of the grief.

None of these questions requires knowing how to code. They're business questions, which is exactly why they work: they can't be answered with jargon.

Which answers are warning signs?

Translated into what they usually mean:

A single one of these answers condemns nobody. Three do.

How do you compare software quotes?

Item by item, never by the total. Two quotes with the same final figure can be very different things: one includes migrating your historical data and the other invoices it separately three months in, when you can no longer back out.

Always ask for these separated: development or licence, implementation, data migration, training, annual support, and the price of a small change once you're live. That last one carries the most information and almost nobody asks for it. If half a day's change gets billed like a new project, you'll know what the relationship looks like from month two.

And watch the per-user price that looks low. Multiply it by your real users, by twelve months and by three years, then compare it with a build. Sometimes the subscription wins and sometimes it doesn't, but the sum has to be done beforehand.

How do I check there's real work behind the demo?

With a small paid trial. Instead of signing the whole project, commission a short first phase with a concrete result: read your real file, show your case, solve one piece of the process. Two or three weeks and a small figure.

That phase tells you nearly everything: whether they understand your business, how they communicate when something goes wrong, whether they meet the deadlines they set themselves, and whether the result resembles what they showed in the demo. It costs considerably less than finding out in month six with half the budget spent.

A vendor who refuses a short, scoped first phase, with a client in front of them willing to pay for it, is telling you something. Not always the worst thing, but something.

Which clauses must you read?

• Ownership of the code and the data. For custom development, get it in writing that the code is yours or at least that someone else could maintain it. The data is always yours; make the contract say so.
• Exit terms. Export format, timeframe and cost. Without this, changing vendor stops being a decision and becomes a construction project.
• What support covers. The difference between fixing a defect (should be included) and adding a new feature (isn't). And the response times.
• Where the data is hosted. With personal data it matters who the hosting provider is and in which country. The data processing agreement isn't optional.
• What happens if the project stops. Who keeps what has been built and in what state. It's the clause nobody reads and the one that gets consulted when it's needed.

When is it NOT smoke, even if it looks like it?

Worth saying, because suspicion can also overshoot.

• When the quote is high but broken down. An expensive, detailed project is usually more honest than a cheap, vague one. Smoke tends to be cheap at the start.
• When they say no. A vendor who admits your case doesn't fit their product is saving you months. Smoke almost always comes wrapped in yeses.
• When they have no identical reference. Nobody has done exactly your case. What matters is that they've solved problems of the same kind and can explain how.
• When they warn that data is missing. If they tell you no result can be promised until they see your real data, they're describing reality, not dodging.

Frequently asked questions

What is the clearest sign that a vendor is selling smoke?

Not knowing, or not wanting to tell you, what their solution does NOT do. Someone who knows their product lists the limits without blinking, because they know that's not where they compete. Someone who answers that it does everything, adapts to any process and that AI takes care of the rest either doesn't know it or is selling. The second sign is a price with no breakdown.

How do I know whether a software quote is reasonable?

Compare it item by item, not by the total. Ask them to separate licence or development, implementation, data migration, training, annual support and the cost of changes. Two quotes with the same total can be very different if one includes migration and the other invoices it separately three months in. And always ask what a small change costs once you're live.

What should I get in writing before signing?

Four things: the scope with what's in and what's out, the schedule with visible partial deliveries, ownership of the code and the data, and the exit terms (in what format your data comes back, how fast and at what cost). If any of that can't be put in writing, it was never agreed.

Is it a bad sign if a vendor tells me they can't do something?

Quite the opposite, it's usually the best sign in the process. A vendor who tells you your case doesn't fit their product, or that a part would cost more than you're willing to pay, is saving you from finding out in month five. Smoke almost always comes wrapped in yeses.