Free tiers are not marketing generosity, they are a distribution mechanism with the boundary placed deliberately. Understanding where the boundary sits, and why it sits there, changes how you should evaluate one.
A free tier is a distribution strategy
Selling software to small teams through a sales process costs more than those teams are worth. A free tier removes the sales cost entirely.
The product acquires users who would never have taken a call, and a fraction of them grow into paying accounts.
This is a rational model for both sides. The vendor gets distribution and the user gets working software at no cost.
It also means the free tier is designed with the conversion in mind rather than as a reduced version of the paid one.
Which features are withheld is the most informative thing about any free tier, and it is knowable before you commit.
The limit sits where leaving is hardest
A well-designed free tier is generous in everything that creates dependency and strict in everything that indicates value received.
Storage of your data is usually generous, because stored data is what makes leaving painful. Collaboration seats are often generous for the same reason.
The limits appear on export, on automation, on integrations, and on the reporting that proves the tool is working.
By the time those limits bind, the tool holds history, is embedded in a workflow, and is known by several people.
The upgrade decision is therefore never a comparison against alternatives. It is a comparison against the cost of unwinding.
Data gravity accumulates quietly
Every week of use adds records, configuration and institutional habit. None of that is visible as a cost and all of it raises the exit price.
Historical data is the heaviest component, because it cannot be recreated. A year of records is a year of records regardless of budget.
Configuration is lighter and still substantial, since it encodes decisions that were made once and never documented.
Habit is the least tangible and often the most binding, because retraining a team costs weeks of reduced output.
The practical implication is that the decision about whether to depend on a tool should be made early, while these are all small.
Seats and events are the two common meters
Most pricing is metered on either the number of people using the tool or the volume of things it processes.
Seat-based pricing is predictable and creates a bad incentive, because teams share logins to avoid paying, which breaks audit trails and permissions.
Volume-based pricing scales with success, which sounds fair and produces bills that jump when a campaign performs well.
Volume meters also count things you may not control, such as inbound traffic or events fired by a third party.
Reading exactly what the meter counts, including what happens when it is exceeded mid-month, is the single most useful ten minutes in any evaluation.
The upgrade is priced against your rebuild cost
Paid tiers are frequently priced with a large step rather than a smooth ramp, which reflects what the vendor knows about switching costs.
The step is set below the estimated cost of migrating away and above what the features alone would fetch in a competitive comparison.
This is why the jump often feels disproportionate to what is gained. It is not priced against the features, it is priced against the alternative.
Negotiation is possible more often than people assume, particularly at renewal and particularly if you can show a credible alternative.
Credibility requires having actually checked that an alternative exists and that your data can leave, which most teams have not done.
Why this is not a trick
Nothing here is deceptive. The limits are published, the pricing is available, and the free tier delivers genuine working software indefinitely.
Many teams use free tiers for years and never pay, which is a fine outcome for them and an acceptable cost for the vendor.
The vendor needs the paying minority to cover the free majority, so the conversion mechanism has to be effective or the free tier disappears.
Free tiers that convert badly get restricted over time, which is why the terms of one you rely on can tighten at renewal.
Treating a free tier as a permanent guarantee is the actual error, because its terms are a business decision that can be revisited.
How to evaluate one before depending on it
Start by finding the limit you will hit first, and estimate when. Most teams can predict this within a quarter if they look at their growth rate.
Then look up what the tier above costs, in full, including any minimum contract term or seat count.
Test the export before you have anything worth exporting. Confirm that it produces a usable file containing the fields that matter, not a summary.
Check whether the integrations you will need are in the free tier or above it, since integrations are the most common paywall and the most binding.
If the answers are acceptable, adopt with confidence. If the upgrade price is unacceptable, the time to know that is now rather than in a year.
Keeping the exit open
Dependency is not avoidable and it is manageable. The practical measure is a periodic export kept outside the tool.
A quarterly export costs almost nothing and converts an unbounded exit cost into a bounded one.
It also gives leverage at renewal, because a vendor conversation goes differently when you already hold your own data.
The second measure is keeping definitions documented outside the platform, so the reasoning survives even when the configuration does not.
Neither of those prevents lock-in. They reduce it to something you can price, which is all that is realistically available.