Pricing software when you have no comparables to look at

3 days ago
3 min read

Introduction

Founders building something genuinely new have no reference point. There is no competitor list to average, no established market rate, and no convention to follow. So most of them guess, guess low, and then discover that a low price attracts customers who churn and makes every acquisition channel unaffordable.

The absence of comparables is not actually the problem. What matters is what the customer is spending now to achieve the same outcome — in staff time, in spreadsheets, in a worse tool, or in the cost of the problem going unsolved. That figure exists and the customer can usually tell you.

Pricing against that is more defensible than pricing against nothing. It also gives you something to say when asked why.

1. Pricing software when you have no comparables starts with the customer's current cost

Find the number they already spend.

Ask what they do today

Whose time it takes, how long, how often, and what goes wrong. Write the four answers down. Then put a cost on it. Use their own salary figures rather than yours.

Ask what the problem costs when it fails

Missed orders, rework, a compliance exposure, a customer lost. That is the value of avoiding it. Ask for a real example from the last year.

2. Price against the value, not the build

What it cost you to make is irrelevant to the buyer.

Ignore your development cost entirely

Buyers do not care and it tells you nothing about willingness to pay. Nobody asks what a product cost to build. Sunk cost is not a pricing input.

Anchor to the saving

If the product saves a day a week of somebody's time, the price is a fraction of that. Say the arithmetic aloud. Let them do the multiplication themselves.

3. Test willingness to pay directly

Guessing can be replaced with asking.

Quote a number in early conversations

The reaction tells you more than any survey. Hesitation, immediate agreement and outright refusal are all useful. Quote it as a fact rather than a question.

Charge the first customers something

Free users teach you nothing about price. A paying customer is the only evidence the problem is real. Ask for money in the first conversation.

4. Start higher than feels comfortable

Raising a price later is much harder than lowering it.

A low price is difficult to reverse

Existing customers anchor to it permanently, and the market position it creates is hard to move. Doubling a price later loses customers.

Discount deliberately if you must

A stated early-adopter discount off a real list price preserves the list price. A low list price does not. State when the discount ends.

5. Choose a metric that grows with the customer

Flat pricing caps you at your smallest buyer.

Pick something that tracks value received

Seats, locations, transactions, volume processed. Not something that penalises them for using it more. Storage and API calls are usually wrong.

Build three tiers and expect the middle

Clear functional differences rather than arbitrary limits, with the requirements larger buyers must have in the top one. Permissions, audit and support commitments belong there.

Conclusion

The absence of comparables matters less than it feels, because the relevant number is what the customer spends today — in staff time, in a worse tool, or in what the problem costs when it goes wrong. Ask them and they will usually tell you.

Ignore your own development cost, which is irrelevant to the buyer, and anchor instead to the saving. Quote numbers in early conversations and watch the reaction, and charge your first customers something, because free users teach you nothing about price. Start higher than feels comfortable and use a stated early-adopter discount rather than a low list price. Then choose a metric that grows with the customer and build three tiers with real functional differences.