Pricing a side project

The first thing I ever sold, I priced at $5 a month. I picked that number because it felt like the largest amount I could ask for without feeling embarrassed.

That is not a pricing method. That is a feeling about myself, converted into a monthly figure and then charged to strangers.

The mistake underneath every bad price

We price from the cost side. Two weekends to build, cheap to host, so it should be cheap. It feels like the honest thing to do.

But nobody buying software is thinking about your weekends. They are thinking about the problem it removes. A tool that saves a small agency four hours a month is worth several hundred dollars to that agency, and it is worth exactly that whether it took you two weekends or two years.

The question is not “what is this worth to me to have built”. It is “what is not having this costing them”.

Ask three questions before you pick a number

Who is this actually for? “Developers” is not an answer. “Developers at small agencies who build client sites and do not want to run a form backend” is an answer, and it tells you they have a budget, they bill their own time, and they compare your price against an hour of that time rather than against a coffee.

What do they do today instead? Every product competes with an alternative, and the alternative is usually a spreadsheet, a manual process, or a junior’s afternoon. That is your real benchmark. If the current solution costs them six hours a month, your price has enormous room.

Who signs off? Something a developer expenses without asking anyone has a ceiling somewhere around $50 a month at most companies. Something requiring a manager’s approval needs a different price and a different sales page, and there is not much useful territory in between.

Prices I have watched work

Free is not a price, it is a funnel. A free tier makes sense when free users make the product better for paying ones, or when they become paying ones on a predictable schedule. Otherwise it is a support obligation you took on voluntarily. My rule now: free tiers get documentation, not email support.

Charge more than feels right, then raise it. Every honest indie pricing post says the same thing, and it is right. The signal is your conversion rate against your support load: if almost everyone who tries it buys, and your inbox is full, you are too cheap. Cheap customers are also, reliably, the most demanding — the person paying $5 a month writes longer emails than the one paying $80.

One axis, and make it obvious. Price on a number the customer can predict and already tracks. Seats, sites, submissions, projects. Pricing on something they cannot forecast — compute minutes, API units, “credits” — creates anxiety at the moment of purchase, and anxiety is the thing you are trying to remove.

Annual at roughly two months free. Not for the discount. For the cash and for the churn: someone who has paid for the year stays for the year, and gets far enough in to actually form a habit.

Grandfather early customers, permanently, and say so. It costs you very little revenue and it buys the thing you cannot buy, which is a group of people who will tell others about you.

Three tiers, and what each is for

The standard shape works and it is worth understanding why rather than copying it.

The cheap tier exists to make the middle one look reasonable. It should be real and usable, and most people should not pick it.

The middle tier is the product. This is where you expect the majority of revenue. Everything about the page — the highlighting, the default selection, the feature list — should point here.

The top tier is for people whose constraint is not money. Higher limits, priority support, an invoice with their company details on it. Some fraction of your customers will pick the most expensive option because it is the most expensive option, and pricing without a top tier leaves that money on the table.

Do not build four. Do not build seven. A pricing page that takes more than twenty seconds to understand loses people who were going to buy.

The mistakes I made so you can skip them

Pricing against a competitor’s number instead of my customers’ problem. Their costs, funding and customers are not yours. You are copying the output of someone else’s spreadsheet.

Adding features to justify a price. The price is justified by the outcome, not by the feature count. Every feature you add to defend a number is a feature you now support forever.

Not charging from day one. The single most useful signal in a product is somebody entering card details. A hundred free users tells you nothing. Three paying ones tells you the problem is real, and tells you which three people to listen to.

Discounting to close. A discount to get a customer over the line teaches them the price is negotiable, and they will remember that at renewal. Say no. The ones who walk were not going to be good customers.

What I would do differently

I would launch at three times the price that felt comfortable, with one clear tier, and put a line on the page inviting people to email me if it was too expensive for their situation.

Two or three people email. You learn something specific about a segment you had not thought about. Everyone else either buys or does not, and either way you find out in a fortnight instead of a year.

The number is not a judgement about your work. It is a hypothesis, and like every other hypothesis in a product, the only way to test it is to put it in front of people and watch.