Free plans and pay-per-use

Inès, an intern in your customer service team, has built a tool that the team now relies on. She'd like it to become an official company tool. "And it's all on free plans," she says, "so it costs nothing."

Free plans are free within limits. Every free plan has three kinds of limit:

• On how much you use it: visitors, contacts, storage, or requests (each time the site asks the service for something). A limit for a given time, such as a day or a month, is a quota.
• On what you can do with it: fewer features, no support, and sometimes the provider's logo on your emails or pages.
• On who may use it, and how: many free plans are for personal projects only, and forbid commercial use. Others pause a project that nobody has used for a while.

These rules are in the terms of service, and the provider can change them. Heroku, a popular host, ended its free plan in 2022, and gave its users a few months to move or pay.

Your portfolio fits a free plan well. Vercel's free plan, for example, is for personal projects that earn no money, which is what a portfolio is. A site for a client, or a tool for a company's customers, isn't.

What matters is what happens at the limit. Some services stop working until the next day or month. Some pause your project. Some start to charge you, sometimes with no ceiling. So for each tool, compare the limits with how much you'll really use it, and decide now whether you'll pay.

• A page where clients track their orders, hosted on Vercel, with its data on Supabase: a page for the company's clients is business use, which many free plans forbid. Vercel's does. Supabase, a ready-made back end, pauses free projects after a period without activity. Approve the tool, with the paid plans in the budget: roughly tens of euros a month in all, small next to the time the tool saves.
• A newsletter, on an email service that is free up to 500 contacts: it goes to 450 customers today, and the next step is all 4,000. That's eight times the free limit. Above it, these services charge by the size of the list, usually tens of euros a month at this size.
• An app where 25 employees book the company cars, on Firebase: 25 people is far below the free limits, so free is fine here. On Firebase's free plan, a service that reaches its limit stops instead of sending a bill. Check the limits once a year.

Whatever the tool, move the accounts into the company's name before it becomes official. Set an alert on usage or spending, sent to a shared mailbox rather than to Inès, who leaves at the end of her internship. And remember that a free plan comes with no support and no guarantee.

Many services are paid per use: each AI answer, each map shown, each text message sent. You're the digital project manager at a home furnishings retailer. Marketing wants to launch an AI feature next week. In a month of testing, the team used it about 300 times, for €3 in all. "The cost will stay small," says the developer.

A pay-per-use cost isn't small or large in itself. It's the cost of one use multiplied by the number of uses. The test gives you the cost of one use: €3 for 300 uses is about 1 cent. It doesn't give you the cost of the launch, because a dozen colleagues are nothing like thousands of customers. So do the sum, for the launch you expect and for the one you hope for.

• An AI assistant on every page, for a site with 50,000 visits a month: if one visitor in ten chats for a few exchanges, that's about 15,000 uses, roughly €150 a month.
• A personal paragraph for each of 200,000 newsletter subscribers: 200,000 uses at 1 cent is about €2,000, every month.
• A free game that redecorates a photo of the visitor's living room, for a campaign that the agency hopes will go viral: if 100,000 people try it three times in a week, that's 300,000 images, about €3,000 at the test's price. If it spreads further, or if the agency chooses a better and more expensive AI model, it can cost ten times more.

Success multiplies the uses, and so does misuse. Anyone can use a free assistant as a general chatbot, and a bot can call it thousands of times an hour. The cost of one use also varies with the AI model, and with how much text it reads, counted in tokens. Check with the developer that the test was typical.

Put the limits in place before launch, not after the first bill. On most pay-per-use services, nothing stops the spending unless you set a cap. Some budget alerts only send an email while the bill keeps growing. And the provider won't stop you before the bill gets big.

Three limits protect you:

• A cap per visitor or per day, such as 20 questions per visitor per day. This is a rate limit.
• A spending limit, with an alert sent to a shared address before the limit is reached.
• A decision about what happens at the limit, such as the game showing "Come back tomorrow", or the assistant offering the contact form instead. This is the fallback.

Then make a decision that fits each case. Launch the assistant, with a limit per visitor and a monthly cap. For the newsletter, first test the paragraphs on a few thousand subscribers, measure the real cost, and check whether those emails bring more sales than they cost. Launch the game only with a hard daily budget.

Compare the cost of one use with what it brings: a sale, a question answered without a phone call, a customer who stays. And ask whether a smaller, cheaper AI model would do the job. For many tasks it's good enough, for a fraction of the price.

The same applies to your portfolio. If you add an AI assistant that answers recruiters' questions about your CV, set a daily limit and a spending limit first.

Ask these questions before a tool on free plans becomes official, and before any feature that is paid per use goes public.

For each service, ask which plan it's on, what its limits are, and whether its terms allow business use. Ask what happens when a limit is reached: does the service stop, pause, or start to charge? Ask what the paid plan costs, and put it in the budget if you'll need it.

For a cost per use, ask what one use costs, measured in the test, and how many uses to expect at launch and if the feature succeeds. Multiply the two. Then ask which limits are in place before launch: per visitor, per day and in total. Ask who receives the alerts, and whether that person will still be here next year. Then decide: launch, launch with limits, or test on a sample first.