The free-plan limits nobody reads

A free plan almost never breaks because of the big number on the pricing page. It breaks on the limit two lines below it: how many days your data is kept, how many projects you get, how many people can join you, or whether you may use it for anything that makes money. That is the one that stops you on a Monday morning, and it is the one nobody reads.

Going through the services in the directory one by one, the same surprises repeat with suspicious regularity. These are the seven limits worth checking before you write the first line of code against a service.

1. Retention, not volume

The most expensive one to discover late. A logging or metrics service may accept plenty of volume and keep it for only a few days. That lets you debug what happened last night, but not answer “this started failing three weeks ago” — which is exactly when you need it.

The precise question: how many days is what I send kept? If the answer is short, the plan is for developing, not for operating. In monitoring that distinction separates almost cleanly what can go to production from what cannot.

2. How many projects, not how much usage

Many free plans are generous on usage and stingy on projects: one or two, and that’s it. If you do client work, or simply have three ideas at once, you hit that limit in the first month and no amount of optimising avoids it.

Check whether a staging environment counts as a project too. Sometimes it does, and then the real limit is half the advertised one.

3. Collaborators

The moment a second person joins, many free plans end. It is the most widespread pattern: individual use is free forever, and teamwork is paid from the first invitation. It isn’t a trap — it makes complete commercial sense — but it changes the decision if you are choosing a tool for something that will grow.

It applies particularly in team and productivity and in design.

4. Whether you can use it commercially

Some free plans explicitly exclude commercial use. The best-known case is Vercel’s Hobby tier, which is meant for personal projects and not for a site that invoices. It isn’t hidden fine print: it is written down, people just don’t read it until a notice arrives.

If the project will produce revenue, however little, this is the first thing to check.

5. What exactly happens when you go over

Three possible behaviours, and they are very different from each other:

• They rate-limit you. Everything keeps working, slower. Best case.
• They suspend the service until the next cycle. Your project goes down. Bad if people are using it.
• They charge the overage automatically. Worse still if you weren’t expecting it, because the surprise arrives on the invoice.

Before launching anything with real traffic, find out which of the three it is and set up a usage alert. A service that warns you at 80% is worth more than one with a slightly larger quota that tells you once it’s too late.

6. Inactivity

The silent one. Plenty of free plans sleep or delete what has gone unused for weeks: databases that pause, environments that shut down, projects that get archived. For a demo you show occasionally, this means the first visit after a month sees an error or waits twenty seconds.

It usually lives in the documentation and almost never on the pricing page.

7. How you get out

The last one, and the one that really determines how much risk you are taking. Can you export your data in a standard format, without asking permission? Does the API resemble something open — Postgres, S3, OpenTelemetry — or is it proprietary top to bottom?

Three rules that make leaving cheaper before you need to:

1. Prefer open standards over proprietary APIs when the difference is small.
2. Keep your data exportable, and test the export once — not on the day you need it.
3. Don’t couple business logic to the provider’s SDK: put a thin layer in between.

With that, switching providers is a matter of hours. Without it, it is an entire project.

How to use this without going mad

You don’t need to audit every service you touch. It is enough to ask these seven questions of the service the project rests on: the database, the hosting, the email. For peripheral tools, retention and exit are plenty.

In the directory every entry lists its known limits in concrete units instead of “generous free tier”, precisely because the headline is never the problem. And even so: plans change without notice, so the official pricing page always wins over anything you read anywhere, this page included.

Frequently asked questions

Is a free plan reliable enough for production? Some are and some aren’t, and the difference is almost never the quota. Look at retention, what happens when you exceed the limit, and whether there is any availability commitment. A free plan that suspends the project when you go over is not suitable for something customers use, however generous the quota.

Why do they sometimes ask for a card when nothing is charged? Almost always anti-fraud verification: free tiers attract automated abuse and a card filters a lot of it out. Even so, check whether moving to paid is automatic or requires you to opt in, which is what actually changes the risk.

How often do free-plan limits change? More often than you’d think. In any given year some providers raise the quota, others cut it, and one or two remove the free tier entirely. Which is why it is unwise to build anything critical on an exact limit without a plan B.

What is the difference between a free plan and a free trial? A free plan can be used continuously; a trial expires. It is the most important distinction and the one marketing language blurs the most. If a service only offers a trial, that should be stated explicitly before you invest time integrating it.

Is stitching together several free services better than paying for one? Sometimes, but there is a hidden cost: each service is another account, another integration and another place something can break. To get started and validate an idea it is an excellent strategy; once the project works, consolidating is usually cheaper.