Does your side project want to be free?

Your side project should stay free if you built it for yourself or your community and you do not want the job that comes with money. It should start charging if you want a business from it, and it should do that soon, because the longer a project is free, the more its users decide that free is what it is. The honest problem is that most builders never choose. They keep the project free by default, hope it turns into a business by itself, and get neither the clean gift nor the business. This post is about making the choice on purpose, and about what actually changes the day you add a price.

What are you really building, a gift or a business?

When we interview people who vibe coded an app, a surprising share did not build it to sell. One builder we interviewed described the kind of apps they make as "the kind of apps I'd want to use myself: fast, free, with no registration or ads." Another, asked about next steps, said the project was "a free resource for my community that I will update from time to time." A third put the trade plainly: "I do not want to spend money on it, but I still want to help as many students as possible." And one summed up a whole portfolio in a sentence: "obviously it's not a business model. is just stuff I want."

None of these are failures. A free tool that a few hundred people use is a good thing to have made. The failure is only wanting a business and running it like a gift. So the first question is not "how do I monetize" but "do I want the second job", because a paid project is a second job: support, invoices, refunds, a customer who expects the thing to work on a Sunday. If the answer is no, decide it is free, say so on the page, and stop feeling guilty about the missing checkout. If the answer is yes, read on.

Why does "free for now" quietly become "free forever"?

Because users learn. One builder we interviewed, with many users and no revenue, said of the project: "It doesn't make money. I just have a lot of users." Another, who ran a subscription next to a free tier that was barely different, explained the reasoning at the time: "the difference between free and subscription wasn't very much because we wanted to build the audience." The audience came. Then the question did too, in the words they reported hearing: "You have 100,000 users, but where's the money?"

A free project trains its users to value it at zero, and the longer the training, the harder the switch. This is not an argument for charging on day one. It is an argument for deciding on day one which it is, and if it is a business, charging for something within the first few months, even a small thing, so the project never becomes a free service in the minds of the people who use it.

What should the first paid tier be?

Not "the same thing, but you pay". A first paid tier that works is a result some users already ask for: the export, the extra seat, the saved history, the thing you keep getting emailed about. If nobody has asked for anything, that is your answer about demand, and it belongs to our post on when to pause or kill a side project rather than to a pricing page.

The number itself is a separate question, and we have written it up in full in our post on pricing a side project without guessing, so this post will not repeat it. Two things from the interviews are worth adding. The first is that the first price is almost always a guess; one builder we interviewed said of theirs, "It was just the first price I thought of." The second is that a small number of payers is a real signal; the same builder who said monetization was not the goal still listed, as a sign of success, "some willingness to pay, even from just a handful of users." A handful is enough to learn from. It is not enough to live on, and it should not be presented as if it were.

What changes the day you add a price?

More than the checkout button. The moment a stranger pays, three things arrive. The first is admin: the money needs somewhere legal to land, which in most countries means a simple sole-operator registration, an invoice, and income you declare. The second is a promise: a paying user is owed a working product and an answer when it breaks, which we covered in our post on support around a day job. The third is terms: a refund rule, a sentence about their data. Our companion piece on what is still missing between a vibe coded app and a business maps this gap; the money post has the actual small numbers.

None of this is hard. All of it is work that a free project never asked of you, which is exactly why free felt lighter.

What about the users who expect free?

Some will leave. One builder we interviewed described the churn on their paid tool this way: "they know what is free and what is not." That is true and it is fine. The people who leave the moment a price appears were never going to be customers; they were the audience of the gift. The ones who stay and pay are the business. Keep a free tier if it costs you nothing to run and brings the next payers; cut it if it only brings support requests.

What should you do this week?

Write one sentence at the top of your notes: "This is a free tool for X" or "This is a business for X." If it is the first, put the word free on the page and enjoy it. If it is the second, pick the one result people already ask for, put a price on it, and register what your country asks of a sole operator. Then tell ten current users, by name, that it exists. If you have fewer than ten, where a side project's first users come from is the place to start.

The setup is days. Finding out whether anyone pays is weeks to months, and no tool shortens that part, ours included. The four jobs of starting a business still apply to a project that is already live; the only difference is that you have done the second one first.

If you have decided it is a business, describe it in one sentence and baget's agents will build the paid side around what you already have: the offer, the price page, the admin and the first ten asks. It costs nothing to look.