Pricing is positioning

The number on the price tag is a claim about who the product is for, not a cost-plus calculation — and raising it can fix a demand problem a discount never will.

The target-arithmetic lesson left a price sitting in your ledger, and it arrived there mostly as an input — a number you picked so the division would produce a customer count you could look at. This lesson is about what that number says out loud, to strangers, before anyone reads a word of your landing page.

Because it does say something. A price is not a neutral readout of what a thing cost to make. It is a claim about who the product is for, published in a font large enough that it is often the only claim a visitor actually reads.

Why engineers underprice by default

Neil Davidson opens Don’t Just Roll The Dice with Hewlett and Packard pricing their Model 200A oscilloscope at $54.40 — a number chosen because it echoed the 1844 “54°40′ or Fight” campaign slogan. It was below their own manufacturing cost, against a competitor charging $400. Two of the most capable engineers of the century set a price with a pun. Davidson uses it to open the case that pricing is usually not reasoned at all, and it is worth sitting with before you assume your own number came from somewhere better.

The specific ways a builder’s number goes low are predictable:

The cost-plus instinct. You know exactly what the hosting costs and roughly what the hours were, so that is the anchor you reach for. Davidson devotes a section of chapter 3 to “Should You Take Your Costs Into Account?” and the answer is that costs tell you when to walk away, not what to charge. Your costs are a fact about you. The price is a fact about the buyer.
You price against your own wallet. And you are the single worst sample available, because you could build this yourself — you already did. A person who cannot build it is not paying for the code. They are paying for not having to.
A low price is a way of not asking. $3 rarely gets argued with, which feels like validation and is actually its absence. A number small enough that nobody pushes back has told you nothing.
Developer tooling trained you on free. Most of what you use daily costs nothing, so charging feels like a deviation rather than the default. It is the default. You are just standing in an unusually generous corner of the market.

Davidson’s antidote is not encouragement, it is a rectangle. Chapter 1 takes a fictional time-tracking tool and multiplies price by units sold at five candidate prices: $0 × 1000 = $0; $100 × 500 = $50,000; $200 × 300 = $60,000; $500 × 50 = $25,000; $1,000 × 0 = $0. The recommendation lands at around $200 — which, as he puts it, is “not where you’ll sell the most units, but it’s where you’ll make the most money” (Davidson, Don’t Just Roll The Dice). Revenue is the area of a rectangle, and the widest rectangle is almost never the one with the lowest price on its short side.

Price as a signal about who the product is for

Chapter 2 does the other half of the arithmetic. Davidson defines objective value as a computation: if a customer’s time is worth $50 an hour and your product saves them three hours, they should buy at any price under $150. That is the ceiling, and it is a number about them, not about you.

On top of that sits perceived value, which can run above objective value or below it — the CRM licence nobody logs into, the headphones whose price is carrying a story. Moving perceived value is the job of marketing. Discovering objective value is arithmetic you can do this evening.

The positioning claim falls out of the gap between those two numbers. Consider the same product with two different tags:

$3 a month says: an individual, paying from a personal card, on a whim, for something nice. No procurement, no invoice, no expectation of a reply. It is priced like a tip jar and it will be treated like one.
$90 a month says: an organisation is paying, this replaces something, and someone will notice if it breaks on a Tuesday. It comes with an expectation of a human at the other end.

You do not get to pick both. The who-pays lesson made the buyer and the user separable people with separable incentives; the price is where you commit to one of them. A finished sports-guides site at $3 a month has addressed itself to hobbyists who will churn on a whim. The same site, repositioned at $90 a month for the amateur clubs that would otherwise be paying somebody to assemble the same information by hand, is a different product with the same code.

The trap: a price too low to fund its own support

This is the failure mode that matters most for a portfolio built around low-maintenance earners, and it is the one a spreadsheet hides.

The maintenance lesson made you measure a real number: hours per month, dollars per month, to hold a product exactly as good as it already is. It also established that support is tactical toil that scales linearly with how many customers you have. Put that next to a price and the trap appears immediately.

Take a project earning $300 a month at $3 a month — a hundred customers — and costing six hours a month of support. That is $50 an hour before hosting, before payment fees, before the annual renewals, before any of the categories that only show up in a measured number. Call it $40 an hour after. Fine, maybe.

Now succeed. Two hundred customers is $600 a month and twelve hours of support, because support does not enjoy economies of scale when the entire support department is you on a Sunday. The hourly rate has not improved at all — growth just bought you more of the same deal. At four hundred customers you have a second job you are being paid $40 an hour to do, on the world’s schedule rather than yours.

Where people get burned

The distinctive shape of this failure is that the product succeeds into unsustainability. Nothing breaks, the revenue chart goes up and to the right, and the thing quietly stops being passive in the only sense the mission cares about — low-maintenance and self-owned. The number that caused it was set once, casually, eighteen months earlier, and has never been looked at since.

The fix is a floor. Below the value ceiling Davidson computes, there is a second number underneath your price: the support cost per customer per month. Measured hours, priced at a rate you would actually accept, divided by the customer count. If your price is not comfortably above that floor, you have not built an income stream. You have built a subsidised service, and you are the subsidy.

Raising a price on existing customers

The reason nobody does this is not really the customers. It is that a rise is a testable claim and the current price is not. So do the arithmetic before the feelings arrive.

A rise from $3 to $9 triples revenue per customer, which means you can lose up to two thirds of your customers and be exactly where you started on revenue — while carrying a third of the support load, because the people who left took their support tickets with them. Break-even churn is a number you can compute in ten seconds, and it is almost always far higher than the churn you are afraid of.

The mechanics that keep it uneventful are unglamorous:

New price for new customers first. The new number starts working immediately and nobody is upset, because nobody who has not bought yet knows what the old one was.
Give notice, in plain language, with a date. Say the price is changing, say when, say what happens to their card. A short honest message outperforms a long apologetic one.
Grandfather deliberately, or not at all. Freezing early customers at the old price forever is a real choice with a real cost — you keep the goodwill and a permanent low-margin cohort you will still be supporting in three years. Decide it on purpose rather than by flinching.
Treat the churn as data. Who left tells you which buyer your old price had been recruiting, which is exactly the positioning question in its most honest form.

Retrieval check

A project makes $300 a month at $3 a month, and takes six hours a month of support. You raise the price to $9. What does that change, and — more importantly — what does it not change?

Check your answer

What it changes: whether the support is fundable. At $3 across a hundred customers, six hours of support is being paid about $50 an hour gross — less once hosting, fees and renewals come out, and worse every time the customer count grows, because support scales with customers and the price does not. At $9, the same six hours are funded roughly three times over. And if the rise costs you customers, the support load falls with them: you would have to lose two thirds of the base before revenue is back where it started, and at that point you are earning the same $300 on a third of the hours.

What it does not change: whether anybody wants the product. Those hundred customers are the same hundred customers. No new person arrives because the number went up, the demand evidence in your ledger is exactly as thin or as strong as it was yesterday, and a product nobody wants at $3 is a product nobody wants at $9 — you have just made the not-wanting cheaper to discover. Price is a lever on whether the thing can pay for itself. It is not a lever on desire, and reaching for it as one is how a demand problem gets misfiled as a pricing problem for another year.

What “charge more” actually means — and where it stops being true

“Charge more” is the most repeated advice in this genre and it is mostly right, which is what makes its failure cases worth naming precisely. It is sound advice when your price was set by cost-plus, or by your own wallet, or by nothing at all — which covers most first prices, including the one currently in your ledger.

It stops being true in four places:

At the objective-value ceiling. If the buyer saves three hours of $50-an-hour time, $150 is a wall, not a challenge. No amount of confidence moves it; only changing what the product does moves it.
When the customer count is zero. Any price times zero is zero. A half-built recipe app for kids with no users does not have a pricing problem, and the Demand gate is where that gets settled — before this lesson, not by it.
When the higher price implies a service level you cannot staff. Charging business money invites business expectations: invoices, procurement, a response within a working day, someone to escalate to. For an evening project that is a real constraint, and it is the one most often left out of the advice. Raising the price raises the obligation, and the obligation lands on the same finite evenings.
When the revenue shape is wrong rather than the number. If the product is used once and never again, a subscription at any price churns. That is a shape problem wearing a price problem’s clothes.

The honest version of the advice, then, is not “be braver”. It is: compute the ceiling, compute the floor, and pick a number between them that names a buyer you can actually serve. If the floor is above the ceiling, no price exists, and that is not a failure of nerve — it is the arithmetic telling you something the demand gate and the maintenance gate had already hinted at.

Now set a price you can defend

Hands on

Revise the price in your ledger

Done when: The Target arithmetic field in PORTFOLIO.md holds a revised price for each “pursue” project, sitting between a computed value ceiling and a computed support floor, with one sentence naming who that price is for.

Open learning/monetizing/PORTFOLIO.md and find the Target arithmetic field for a project you marked “pursue”. Read the price already there and write one sentence on where it came from. If the honest answer is “it looked reasonable”, write that — it is the most common answer and it is the whole reason for this exercise.
Compute the ceiling, Davidson’s way. Name the buyer. Name what the product saves or earns them in a month, in hours or in money. Convert the hours at a rate that buyer would recognise as their own. That total is the most this is worth to them, in dollars, before any perception enters the picture.
Compute the floor. Take the measured hours/month from the Maintenance field, price those hours at a rate you would accept for a Sunday, add the $/month, and divide by the customer count the target arithmetic needs. That is the minimum any single customer can pay before growth starts costing you money.
If the floor is above the ceiling, stop and write that down as-is. No price exists at that customer count, and this belongs in your ledger as a verdict input, not as a puzzle to solve tonight.
Otherwise, pick a number between them and write it into Target arithmetic, replacing the old one. Next to it, one sentence: who this price is for. Not what it costs you — who it addresses.
Rerun the division with the new price. The customer count will have moved, usually a long way down. Update the sentence about whether a path to that count exists, because at a higher price it is often a different and much shorter path.
Bring the ceiling, the floor and the revised price into the chat. I’ll push hardest on the ceiling — it is the number people quietly compute from what they would pay rather than from what the buyer saves, which puts a cost-plus answer in a value-based costume.

What this does not cover

That closes the model. You can now say who pays, what shape the money arrives in, how many customers the target needs, and what the price claims about who the product is for — which is everything required before anyone can actually hand you money, and nothing at all about how they would.

That is making the transaction possible: the smallest version of a project somebody can buy, the plumbing a stranger’s payment has to travel through, where the free/paid line falls, and why the first handful of sales get made by hand rather than by funnel. Carry the price you just defended into it, alongside the Demand, Maintenance, Verdict, Buyer and Arithmetic answers the ledger already holds — because it puts the number to work and starts asking what it takes to actually collect it.