You see a demo, it does exactly the thing you need, and you start planning: which work moves to it, who uses it, what it replaces. Weeks later you find out the product is something else, or costs something else, and the plan has to be redone.
Most of that is avoidable with a short check before the planning starts.
A demo shows you what a product can look like. It does not tell you what it is.
What a demo is for
A demo is a sales tool, and a fair one. Its job is to show the best thing the product can produce, quickly, so you can picture it in your own work. That is useful. It is also the least informative view of the product you will ever get.
The demo answers "what can come out of this?" It usually does not answer two questions that decide whether you can use it at all:
- What would you actually be using, day to day?
- What does it cost once it is in real use?
Both answers are normally public. They sit one or two clicks away from the demo, on pages that are less fun to read.
Question one: what would you actually be using?
Very different kinds of product can produce the same impressive demo. The picture on the homepage looks the same whether it came from an app you open or from a set of parts a developer assembled for weeks.
The common kinds, in plain terms:
- An app. You sign up, open it, and use it. What you saw in the demo is roughly what you get.
- A kit for developers. A set of building blocks that someone writes code against to build their own app. The demo shows what a skilled team built with the kit. You get the blocks, not the finished thing.
- A service behind something else. It does its work inside another product or through a connection to your systems. There may be nothing for you to open at all.
- A template or starting point. Something you copy and then maintain yourself from that day on.
The kind matters more than the features, because it decides who does the work. An app needs a person to learn it. A kit needs a developer to build with it and then keep that build running. A business owner who plans around a kit as if it were an app has planned for the wrong person.
How to tell, in a few minutes: open the product's "get started" or documentation page. If the first step is "create an account" or "download", it is probably an app. If the first step is a line of code to install something, it is a kit, whatever the homepage looks like.
Question two: what does it cost in real use?
"Free" on a pricing page often means free for a particular kind of use. The terms worth reading for are the ones that change the price when the tool moves from trying it to relying on it.
- Free to build versus free to use. Some products are free while you develop or test, and need a paid license once the thing you built is in daily use. The free part is real. It just stops at the point you care about.
- Annual terms. A yearly license is a commitment before you know how much you will use it.
- Per person or per use. A price that looks small for one user can look different across a team.
- "Contact us" instead of a price. This is common for commercial licenses. It means you cannot budget for it until you have had a sales conversation, and the number may depend on who you are.
None of these is a red flag on its own. They are normal ways to sell software. The problem is only finding them after the plan is built.
A worked example
This came up this week. A drawing tool with a good demo looked like it might handle diagrams for reports. A closer look at its own pages changed the picture.
| What the demo suggested | What it actually was | What that changes |
|---|---|---|
| A drawing app you open and use | A kit for developers, used by writing code against it | Someone has to build the app first, then maintain it |
| Free to start | Free for development only | The free part ends when real use begins |
| A product you could try and adopt | A paid annual license for production use, with no public price | No way to budget without talking to sales |
Nothing about the product was misleading. It is a good kit for the people it is built for: teams that want to put drawing into their own software. It was just not the thing the plan had assumed. Finding that out before any planning cost a few minutes of reading. Finding it out after would have cost the plan.
A ten-minute check before you plan
Before you write down any work that depends on a new tool, read these four places:
- The getting-started page. Does the first step have you open something or install something? That tells you what kind of product it is.
- The pricing page. What is free, and for which kind of use? Look for the words "development", "production", "commercial", and "per year".
- The license or terms page. If the pricing page is vague, this is where the real answer lives. Search it for "production" and "commercial".
- Who the product says it is for. Product pages usually name their audience somewhere. "For developers" and "for teams" are very different promises.
If the answers are unclear after that, ask the vendor in writing before you commit any work to it.
What to take away
- Treat a demo as a picture of what is possible, not a description of what you would get.
- Before planning, find out what you would actually be using day to day: an app, a kit, a service, or a template.
- Find out what it costs once it is in real use, not while you are trying it, and get a number before you build the plan on it.
New tools are worth trying. The check is cheap and the plan is not. The AI does the busywork, you still make the calls.