How to price a side project without guessing

Price it on what it does for one specific person, not on what it cost you to build, and pick one number you can say out loud without discounting it in the same breath. For most side projects that means a single plan, monthly or one-off, set by looking at what that person pays today to get the same result some other way. Then treat the number as a test: it is right when a few people have actually paid it, and wrong when nobody does, and either way you will change it. What you should not do is spend another month on features because deciding a price feels presumptuous. The price is the first real question you ask the market, and the market cannot answer a question you have not asked.

Why does cost-plus pricing fail for a side project?

Because your costs say nothing about the customer. A vibe coded app built in Lovable or Base44 over a few weekends might cost you a hosting bill and a domain. Pricing it at cost plus a margin gives you a number so small it signals "hobby" to the very people you want to pay, and so small that ten customers do not cover an hour of support a week. The opposite trap is pricing on your hours. You spent four hundred evenings on it; the customer did not, and they will not pay for them.

The number that matters is the one on the customer's side of the table: what they currently spend, in money or time, to get the result your project produces. A tool that saves a freelancer an afternoon a month is worth some fraction of an afternoon of their rate. A service that replaces a spreadsheet nobody enjoys is worth more than the spreadsheet and less than the assistant they would hire instead. You need the right order of magnitude, not a precise figure, and cost-plus puts you in the wrong one.

Who are you pricing for?

One person, named. This is where most pricing advice goes abstract and most side builders get stuck, so be concrete: write down the one customer you most want, what they do, and what the result is worth in their week. If your project exists and has free users, that person is probably among them already, and the next step is to ask them. If you have no users yet, you are a step earlier, and the place to start is finding the first ten, because a price with no one to show it to is just a number on a page.

Pricing for one person also solves the tiers question. You do not need a Free, Pro and Team column on day one. Three plans are three decisions you are making with no data, and they let the customer avoid the only question that matters by picking the middle one. One plan, one price, and the word "yes" or "no" is the cleanest signal you will get this year.

Should the first price be monthly, one-off, or usage based?

Whatever matches how the value arrives. If the result is ongoing, the project does something every week, a monthly price is honest and keeps you accountable to keep it working. If the result is a one-time outcome, a converted file, a generated document, a booking, charge once and do not invent a subscription around it. Usage pricing is rarely the right first answer for a side project, because it makes the number unpredictable for the customer and the revenue unpredictable for you, and you have enough unpredictability already.

One practical note, since the question comes up with vibe coded apps: taking payment is no longer the hard part. Both Lovable and Base44 document a Stripe path, and most comparable builders do too, so the checkout is a settled problem you can finish in an evening. The hard part is still deciding the number and saying it to someone.

How do you know the price is wrong?

By what happens after you say it, not by how it feels before. Three outcomes, three readings.

Everyone says yes immediately, without a question. The price is probably low. That is not a disaster for a first customer, but note it, because raising prices later is a conversation you will have to have.

Some say yes after a question or two about what is included. This is the healthy zone. The price is making them think about value, which is what a price is for.

Everyone says no, or goes quiet. This usually means one of three things, in order of likelihood: the wrong person, the wrong moment, or the value is not there yet. Price is often the last of those, not the first. Before you cut the number in half, check whether you asked the right customer.

One builder we interviewed, with a live app and a few dozen mostly free users, told us the price on his page "was just the first price I thought of". He now wants to change it. That is the normal path, not a failure: the first number exists so that a real person can react to it. Another builder we interviewed put the goal for his project at "some willingness to pay, even from just a handful of users", and said he would "rather validate that it solves a problem people care about before focusing on monetization." Both are describing the same thing from two sides: the price is a question, and the handful of people who answer it are the data.

What about discounts, lifetime deals and "founder pricing"?

Use them rarely and name them when you do. A lifetime deal trades a small amount of money now for a customer you will support for years; for a side project run around a job that trade is usually bad. A discount for a first customer in exchange for a specific thing (a testimonial, a weekly call for a month, or a public logo) is a reasonable deal, as long as the full price is written down somewhere so both of you know what the discount is from. "Founder pricing" with no end date is just a low price.

The honest part: a low first price is not the sin people think it is. The sin is never raising it. Decide now that the price moves after the first handful of customers, and tell those customers so. Most people respect it.

What does this look like in a week?

Monday, write the one-sentence customer and the result they get. Tuesday, write down what that result costs them today, roughly. Wednesday, pick one price and one plan. Thursday, put it on the page and connect the checkout. Friday, say the number to one real person. None of these take an evening, and the last one is the only one that produces information.

None of this makes the next part fast. The setup is days. Finding the price that holds, with the people who will pay it, takes weeks to months, and no tool does that part for you, including ours. What a tool can do is make sure the page, the number and the checkout stop being the reason you have not asked. Our own first season of doing exactly this is public, including the slow parts: we built a real business in 7 days with baget. The broader map of what sits between a side project and a business is in how to turn a side project into a real business, and the four jobs that frame all of it are in how to start a business with no experience.

baget gives your side project the business side: the offer, the pricing page, the checkout and the follow-up, built by a team while you keep building. One line is enough to start, and it costs nothing to look.