How to Price Software When You Have Never Sold Anything

You have shipped something that works. Someone asks what it costs. You have no idea, so you look at your hosting bill, add a bit, and say a number you immediately regret.

The short answer is that price comes from what the problem costs the person who has it, not from what the software costs you to run. Your infrastructure bill is the one input with almost no bearing on the answer, and it is the one every technical founder reaches for first.

Why cost-plus pricing is the wrong instinct here

Cost-plus pricing means taking what a unit costs you to produce and adding a margin. It works for physical goods, where the marginal cost of the next unit is real and knowable. For software the marginal cost of the next customer is close to zero, so cost-plus anchors you to a number that describes your server bill rather than the thing you built.

The result is the same every time. A founder who spent nine months building something charges eleven dollars a month for it, because eleven dollars comfortably covers the infrastructure. The price is not just low, it is actively confusing: it tells the buyer this is a small thing, and small things do not get budget, attention, or a second look when something breaks.

Price is a signal before it is a transaction. It tells the buyer what category you are in and how seriously to take you, and it does that before they have used anything.

Start from what the problem already costs them

Every problem worth solving is already being paid for. Not always in money, but always in something. Your job is to find out what, because that number is the ceiling you are pricing under.

There are four places to look, and they are worth checking in this order:

1. The tool they use now. If they pay for something that does part of the job, that price is public and is the easiest anchor you will ever get.
2. The person who does it now. If a human does this task, their salary divided by the fraction of their week it consumes is the real cost, and it is usually an order of magnitude above any software price.
3. The hours the founder spends. If the answer is "I do it myself on Sundays", the cost is the thing they are not doing instead, which is generally the product.
4. The cost of it not happening. Some problems are not solved at all. The cost is the revenue that never arrives, which is harder to quantify and is often the largest number of the four.

Once you have that number, you are no longer inventing a price. You are choosing what fraction of a cost you already know to ask for, which is a much easier question to answer honestly.

A worked example

Say you built a tool that turns support tickets into documentation. The founder instinct is to price it against your OpenAI bill, which might be forty dollars a month, so you charge ninety-nine and feel bold.

Run the anchors instead. The person with this problem currently writes docs themselves, badly, on Fridays. Call it three hours a week. If they are a founder, those three hours are the most expensive hours in the company, and they are not being spent on the product. Alternatively they employ someone part-time to do it, in which case there is a real salary line you can ask about.

Three founder hours a week is more than a hundred and fifty hours a year. You do not need to convert that into a precise figure to see that ninety-nine dollars a month is not an aggressive price against it, and that the forty-dollar bill was never the relevant number.

Pick the unit before you pick the number

What you charge per matters more than what you charge, and it is much harder to change later. The unit is a claim about where your value comes from, so it should track the thing the customer gets more of when they get more value.

A common mistake is charging per seat for something a single person runs. The buyer has no reason to add seats, so your revenue cannot grow with the account, and you have accidentally capped yourself at one seat per company.

One more consideration on units: whichever you pick, the buyer has to be able to predict their bill. Usage pricing is the most honest reflection of value and the most frightening to sign up for, because a spiky month produces a spiky invoice and nobody wants to explain that internally.

The usual fix is a floor and a ceiling. A monthly minimum so your revenue is predictable, and either a cap or a clear alert so theirs is. Pure usage pricing with no ceiling is the model most likely to be loved in a demo and rejected in procurement.

Your first number is a hypothesis

Founders agonise over the first price as though it were permanent. It is not. It is a hypothesis, and ten conversations will tell you more than ten weeks of thinking.

What to watch in those conversations, in rough order of how much it tells you:

• Nobody hesitates and everybody buys. The price is too low. This feels like success and is the most expensive mistake on this list.
• They hesitate, ask what is included, and buy. This is roughly right. Some friction is the point.
• They say it is expensive and buy anyway. Also fine. That sentence is often a negotiating reflex rather than a verdict.
• They say it is expensive and do not buy, but keep talking. Usually a positioning problem, not a price problem: they have not understood what they are getting.
• They stop replying. Least informative of all, and the most common. It tells you nothing about price specifically.

The thing to avoid is treating a single loud objection as data. One person telling you it is too expensive is an anecdote. Five people telling you the same thing, while nobody buys, is a pattern.

Charge from the first customer

The strongest argument for charging early has nothing to do with revenue, which at this stage is not going to change your life. It is that free users and paying users answer different questions.

A free user tells you whether your product is pleasant. A paying user tells you whether it is necessary. Only the second question matters, because only the second one predicts whether this becomes a business. Money is the cheapest signal you can buy, and you can buy it immediately.

There is also a practical asymmetry. Going from free to paid is one of the hardest transitions in software, and it costs you goodwill with exactly the people who supported you earliest. Going from a low price to a higher one is comparatively easy, and existing customers are usually grandfathered anyway.

We took our own version of this decision: beta access to Operater costs nine dollars rather than nothing, and it changed who signed up more than it changed how many. The reasoning is written up in why we charge for the beta.

Where this advice is wrong

Three situations where the above does not apply, and following it will cost you.

You are building something with strong network effects

If the product is worth more to each user as more people join, early free usage is not a failure to charge, it is the product working. Charging before the network exists can kill the thing that makes it valuable. This is genuinely rare and is claimed far more often than it is true, so be honest about whether you actually have this or just want to.

You are selling to developers as infrastructure

A free tier that lets an engineer try something without a purchase order is a distribution channel, not a pricing mistake. The rule still holds one level up: the free tier exists to reach the paid one, and if there is no credible path between them you have a hobby with a billing page.

Your buyer has no budget and no authority

If the person who loves your product cannot spend money without asking someone else, your pricing problem is a positioning problem wearing a disguise. No price works. You need either a smaller number that fits on a personal card, or a different buyer.

How to raise a price without losing anyone

Most founders undercharge for longer than they should because raising a price feels like a confrontation. In practice it is mostly logistics.

1. Change the price for new customers only. Nothing happens to anyone who already bought.
2. Watch the conversion rate on new sales for a few weeks. If it does not move, the old price was leaving money on the table and you now know it.
3. Tell existing customers before they hear it elsewhere, and tell them they are staying where they are. This converts a potential grievance into a reason to like you.
4. Move existing customers only when you have added something they asked for, and only once. Repeated increases erode trust faster than a single larger one.

The step people skip is the second. Changing a price without watching what happens next is not a test, it is a guess with extra steps.

What to do this week

Find the number the problem already costs. Ask three people who have the problem what they currently do about it and what that costs them, in money or hours. Do not mention your product or your price in that conversation; you are collecting the anchor, not selling.

Then pick a unit that tracks value, pick a fraction of the anchor, and put it on the page. A price that is visible and slightly wrong beats "contact us" every time, because "contact us" filters out exactly the self-serve buyer a small company can actually serve.

And if the honest answer is that nobody has this problem badly enough to pay anything, that is not a pricing failure. That is the most useful thing you will learn all quarter, and it is worth more than the revenue you were hoping for.