pricing

Pricing (what to charge, and how)

Price is not a number you pick at the end. It is a positioning decision: it tells the market who you are, what you replace, and how much you believe you are worth. Get it from evidence, not fear.

Use this when: you are guessing at a price, you priced on a gut feeling and now feel stuck with it, you don't know where the free line goes, developers use it and nobody pays, or you believe "developers won't pay for this" so you have never charged at all.

The core idea

Three decisions, in order. Most founders skip to the third and wonder why nothing converts.

1. The value metric (what you charge per). The single most important pricing decision. Get this wrong and no tier structure saves you.
2. The packaging (what is free, what is paid, what is enterprise, and what triggers the upgrade).
3. The number (the actual price on each tier).

One rule sits under all of it: price against the value the customer gets, never against your cost or your fear. Your AWS bill is not a pricing strategy.

First: are you even ready to price?

Do not gate before you have proof people come back. If week-2 retention is weak, a paywall just turns a leaky funnel into a smaller leaky funnel. Prove retention, then monetize (see know-if-its-working). The one exception: if buyers are already emailing "can we pay you for X," that is a green light regardless of stage. Stated willingness to pay is the strongest signal there is.

Framework: the value metric

Charge for the thing that grows as the customer gets more value. A good metric:

• Scales with their success, so the bill grows as they grow (seats, active users, projects, events, API calls, GB, builds, endpoints monitored).
• Stays predictable enough that finance can forecast it. Pure usage that spikes 10x overnight creates bill shock and churn.
• Is legible in one sentence. If a dev cannot predict roughly what they will pay, they will not adopt.

Does the value come mostly from more PEOPLE using it (collaboration, seats)?
├─ YES → per-seat, but watch for seat-sharing and bot accounts deflating it
└─ NO  → value comes from more USAGE (events, calls, compute, data)
         → usage-based, with a floor and caps so the bill stays predictable