Pricing Guide 101: For Early-Stage Startups
+ Free Roasting of your pricing page
Hey - it’s Alex,
Most founders treat pricing like a math problem. They argue over whether the number should be €79 or €99, pick one, and move on.
Working with founders on their GTM foundation, pricing comes up in almost every engagement. And the issue is almost never the number. It's the structure.
That’s why I invited pricing expert Serge Herkül, Founder of Potio (a boutique pricing consultancy for startups), to MRR Unlocked.
He'll walk you through a step-by-step process to find your value metric, pick the right model, and package it, specifically for founders on the road from €0 to €1M ARR.
I'll hand it over to Serge from here.
P.S. At the end of the episode, we offer to roast your pricing for free.
In case you missed the last 3 episodes:
✅ The 8 GTM Infographics for SaaS/AI founders
✅ The GTM Foundation behind great Sales Demos
A quick word from our sponsor: I include only sponsors I would personally recommend.
📢 “When I think of revenue, I think of Attio.”
Granola runs their entire revenue motion on Attio. Agents score and enrich leads, product signals sync to every record, and workflows route each prospect straight to the right rep. Nothing slips.
Here’s what that adds up to:
Zero missed leads and 10X faster access to customer context
Lead triage 83% faster
5 hours saved per week with automated updates
Fast-growing teams like Granola scale on Attio. Are you one of them?
📢 Pitch — Finally, presentations the way AI always promised
Pitch Agent doesn’t just generate slides. It builds on Pitch’s existing workspace and editor to handle the entire presentation lifecycle.
Prompt Pitch Agent to create decks from your brand templates, chat to refine and restructure your narrative, ask it to write follow-up emails, and share final decks via live links that track audience engagement in real time. No exports, no separate sales portals, no off-brand output. Just one agent, doing the whole job.
I’ve seen pricing from both chairs: the CEO sweating his own pricing, and the professional companies now hire to fix theirs.
❌ Pricing isn’t a pure math problem.
✅ It’s a design problem with math applied at every step.
And it’s the highest-leverage part of your whole company. With the same product and the same team, the gap between mediocre pricing and great pricing can be a 10x difference in growth.
This guide is how I think about building a pricing model, written specifically for founders on the road from €0 to €1M ARR.
Use it as a step-by-step process, and by the end, you’ll land on pricing you can trust and share with your customers. Let’s start with the mindset, because if you get this part wrong, nothing else lands.
The core philosophy
Pricing is central to your company, not an afterthought you pass to finance.
Pricing defines how you align the customer’s wallet with the way they get value from what you built, which means it touches your core product metrics as much as any feature does.
There’s no single right way to price, but there are several great ones.
The best companies shift pricing as the product evolves, ICP changes, and the market moves. The best companies treat pricing as something they tune continuously, dozens of small changes a year rather than one big overhaul they bet the company on.
Pricing is closer to conversion rate optimization than to accounting. You don’t solve it once; you keep tuning it.
Your goal on day one IS NOT to be right.
It’s to ship something defensible fast and improve it on a loop.
And good pricing does more than set revenue per customer.
It quietly shapes retention, activation, and expansion.
✅ The right model pulls customers up as they grow.
❌ The wrong one caps them, or nudges them to ration their own usage, and it’s almost never the dollar amount that causes that. It’s the structure.
So start simple.
Since your pricing will change anyway, your first model should be quick to take to market.
Flat fee or per-seat is often enough to prove the one thing that matters pre-revenue: that someone will actually pay you.
Pricing by stage
How much effort pricing deserves depends on where you are. Alex splits the climb from €0 to €1M ARR into three stages, and pricing plays a different role in each.
Stage 1: Hustle mode.
You’re chasing your first 10 to 100 customers.
Pricing’s only job here is to stay out of the way.
Keep it dead simple, a flat fee or per seat, and prove people will actually pay.
Don’t optimize, don’t agonize over packaging.
→ The question is binary: will someone hand you money?
Stage 2: Focus mode.
You’ve niched down to one segment, one use case, one channel, and you’re pushing past those first customers toward €1M.
Now pricing earns real attention.
This is where you run the full exercise in this guide once and ship a real pricing V1:
→ find your value metric
→ pick your model
→ package it.
Timebox the thinking to a day or two, put it live, and let real conversions tune it.
Get this roughly right and pricing starts pushing your growth.
P.S. Make sure to plan a quarterly ‘pricing review meeting’.
Stage 3: Expansion mode.
Past €1M, pricing stops being a project you revisit annually and becomes an ongoing function, as permanent as marketing or product.
As you expand into new use cases, your pricing has to flex with it. You’re probably not here yet, but it’s where all of this leads.
Price structure vs. price points
Here’s the distinction that reframes everything.
Pricing has two layers, and founders spend their time on the wrong one.
1️⃣ Price structure is how you charge
→ your value metric plus your packaging. It decides who pays and how their bill scales.
2️⃣ Price points are how much you charge
→ the actual numbers on the page.
Spend 80% of your time on structure and 20% on the points.
If your structure is wrong, no price point can save it.
Charge a flat rate to an enterprise account that’s getting massive value and it makes no difference whether you set it at €99 or €199.
You’re leaving most of the money on the table either way, because the model doesn’t scale with the value they’re getting.
The good news is that price points are the easiest thing to change later.
→ Get the structure right and the number becomes a tuning knob.
→ Get the structure wrong and the number is a band-aid.
So that’s where we’ll spend the rest of this guide: structure first, numbers last.
Step 1: Get clear on who you’re selling to
Before you can charge anyone, you need to know who “anyone” is.
Some products get bought by structurally different types of customers.
Think of an airline selling the same plane’s hold to cargo shippers and its seats to passengers: different buyers, different logic, and you’d never price one like the other.
In SaaS, this split is usually less obvious, and pricing people call it “fencing.”
At your stage, you don’t need the jargon, and you definitely don’t need more than one of these.
This isn’t about tiers or packaging. It’s just about picking one type of customer and aiming your entire pricing architecture at them.
If you’re below €1M and already trying to serve structurally different buyers, that’s a sign you’re spread too thin.
Step 2: Your value metric
This is the single most important decision in your pricing, and if you get it right, most of the early-stage work takes care of itself.
Your value metric is the unit you charge by, and the whole point of it is to make your pricing scale alongside your customer’s success.
Land on the right one, and the rest of your pricing clicks into place.
→ Pricing feels fair, because buyers pay more only when they’re getting more.
→ Upsells happen on their own as customers grow into the metric.
→ And those painful discount fights in negotiation mostly evaporate.
Picking one can feel daunting, so I use three strict filters.
A candidate metric has to pass all three:
1️⃣ can you measure it,
2️⃣ do customers like it,
3️⃣ and does it grow as they grow.
Filter 1: Operational fit. Can you track and bill on it?
A clever metric is useless if you can’t build billing around it. Yours has to be:
Measurable. Can you point to an actual number in your product’s database and charge against it?
Attributable. Can you confidently say your product was the reason that number moved?
Execution feasibility. Can finance and engineering meter and invoice this without making it a mess?
Filter 2: Customer perception. Do buyers like paying this way?
If a customer feels punished for using your product, they’ll stop growing. A good metric matches the buyer’s psychology:
Understandable. Can everyone, your team and theirs, grasp it in seconds?
Fairness. Does it feel like a reasonable way to pay for the software?
Expectation to Pay. Does the market already pay for this kind of product this way?
Willingness to Pay. Does their willingness to pay actually rise as they consume more of the metric?
Filter 3: Economic logic. Does it scale with success?
The metric has to make mathematical sense for your margins too:
Cost aligned. Does it move in step with your cost to serve? Critical for AI companies carrying real compute costs per unit.
Consistent. Is one unit roughly worth the same as another, whoever’s buying? (For an OKR software a CEO seat and a junior designer seat differ wildly in value, which is a strike against seats as a metric).
Scalable. Does it reliably grow as the customer’s business grows, or as the value they pull from you grows?
Your best metric lands dead-center in all three circles.
In practice, almost nobody finds one that scores 10/10 on every criterion, and that’s fine. Index your candidates against each filter, judge which performs best overall, and commit.
The exercise to find it
This works on a whiteboard with your team in under an hour.
Step 1: First, list every possible value metric.
Don’t pre-filter, don’t be precious, get them all down. Push past the obvious ones.
If you write “# of users,” also write “# of active users,” and so on.
Creativity is the whole game here.
Step 2: Second, run a fast pass on measurability.
For each candidate, can you literally point to a number in your database you could bill against? If it’s hard or impossible to measure, kill it now.
Step 3: Third, score what survives on how well it correlates with perceived value.
If the customer is happy to pay more as the metric grows and the economics hold up, it’s a strong candidate. If they understand why you’d charge on it but don’t love it, keep it as a backup. Anything else, discard.
By the end you’ll be down to a handful. Rate those finalists against the three filters above, and your winner usually becomes obvious.
Can you have more than one value metric?
Yes, and plenty of strong companies do.
But there’s a right and a wrong reason to.
A second metric earns its place when it captures a genuinely different axis of value, the way Stripe charges on payment volume and also per active connected account, two real dimensions of how customers grow.
The wrong reason is hedging, bolting on a second metric because you’re not confident in your first.
That just confuses the buyer and muddies your billing. Early on, run one primary metric that carries the model, and add a second only if it tracks a distinct, real source of value.
Your model falls out of your metric
Once you have the metric, your pricing model is mostly decided. Don’t choose a model first and reverse-engineer a metric to fit it.
That’s backwards, and it’s one of the most common early mistakes I see. Pricing models go through fashions, and whatever is trendy right now might not fit your product.
A few questions to connect the two:
Do individual users get standalone value? Per-seat.
Does usage volume equal value? Usage-based.
Does value scale with the customer’s revenue? Percentage of GMV.
Do free users drive adoption and network effects? Freemium.
Does each action directly save time or money? Per-action.
The warning: don’t price on a metric that punishes success
The most common version of this mistake is charging by seats for a product whose value comes from usage, not access.
Picture a product that lets agencies build custom client proposals. What used to take three hours now takes ten minutes. It’s tempting to charge on “# of proposals” and tack on “# of seats” too, because seats are familiar and surely more users means more value.
But proposals are your real value metric.
They sit right next to the outcome the customer is buying.
Seats sit far from it. A seat on its own does nothing. It’s just a door to the thing that actually matters, which is proposals going out.
Charge by seats and you hand customers a reason to ration access: they funnel everything through one person to keep the seat count down, the product never spreads through the org, and they create fewer proposals.
You’ve priced in a way that throttles the exact behavior you want.
Charge on the outcome and that ceiling disappears.
Value-based pricing and the value chain
“Value-based pricing” gets talked about like it’s mystical.
It isn’t.
Strip away the jargon and it just means choosing a value metric that sits close to the end outcome your customer actually cares about.
A value chain makes this concrete. It’s the full sequence of steps a customer moves through to get value from your product.
Take the proposals company again.
To get value, the customer signs up, sets up their account (invites teammates, uploads brand assets and tone of voice), creates a proposal, and sends it to their client, who accepts, rejects, or asks for changes.
Lay the candidate metrics along that chain and it reads:
account setup → create proposal → send proposal → proposal accepted.
The further right your metric sits, the closer you are to real value, and to true value-based pricing.
When you’ve got several decent candidates, the chain is a clean way to choose: prefer the one furthest right that you can still measure and bill cleanly.
One important caveat. Most companies can’t price right at the point of value, and true value-based pricing is rarer than the theory suggests.
Plenty of the biggest companies, Anthropic and AWS among them, price on the left of the chain, on tokens and compute rather than business outcomes.
The rule of thumb:
✅ The narrower your niche, the further right you can price, and the more you can charge for that proximity to value.
✅ The broader and more horizontal your product, the further left you’ll sit.
From metric to model: 3 examples
The move is always the same. Work out what actually creates value for the customer, and the model picks itself.
A few examples you’ll recognize:
Figma (per-seat)
The people holding editor seats are the ones creating the work, so a seat is a clean proxy for the value a team gets.
And one creator seat is worth about as much as the next, since they’re all creating. When each user gets a standalone value and that value is spread evenly across them, per-seat is the obvious fit.
Stripe (percentage of revenue)
Stripe gets more valuable the more money you move, and, rare for any software, it can see your revenue exactly because it’s the one processing it.
When value tracks a number you can measure directly, and that number is the customer’s own growth, taking a small cut of it is the natural model.
Most companies can’t price this way because they never have that visibility.
Intercom Fin (per-action)
Each Fin resolution has a concrete, calculable value: you know what it costs to close a ticket with a human, and Fin does it cheaper.
When every action your product takes maps to a clear dollar saved, charging per action is the cleanest way to price.
📌 Quick reminder: Serge and I are offering to roast your pricing page for free.
A 5-min Loom video with our honest take. No strings attached.
Just reply to this email with your pricing page URL and we'll record one for you.
Step 3: Packaging
Depending on how mature your product is, you may be able to have more than one package.
In fact, if possible, you should always aim for more than one, ideally at least three.
Early on, a single offer is fine. But once you’ve been building for a while, there’s real money in having a few.
Here’s why.
Different customers value your product differently and have different willingness to pay.
Offer one package at one price, and you’re forced onto a single point on that demand curve.
❌ Price high and you lose the lighter buyers.
❌ Price low and you leave money on the table with the heavy ones.
Multiple packages let you capture more of the area under that curve:
✅ an entry tier that converts the price-sensitive,
✅ a premium tier that captures the high willingness-to-pay buyers,
✅ and something in between.
The image shows the price curve across your customers. Maximise the area under the curve and you maximise your revenue.
So packaging is building offers, each a deliberate combination of features, services, and price, aimed at a segment, so you capture the most value possible from it.
There are three primary ways to package, and I prefer them in this order:
1️⃣ Jobs-to-be-done (JTBD)
Each package serves a different job your product does. Use this when your product does several distinct jobs and different buyers show up for different (or multiple) ones.
Stripe is a great example of JTBD packaging: Payments, Billing, Connect and Radar are separate packages because accepting a payment, running subscriptions, paying out a marketplace and fighting fraud are genuinely different jobs.
Importantly, one buyer often “hires” Stripe for multiple jobs.
2️⃣ Personas
Each package targets a distinct persona. Use this when your product does one job for several audiences with different willingness to pay.
LinkedIn does this with its premium plans: Career, Business, Sales Navigator and Recruiter are the same platform packaged for four very different people who pay very different amounts.
3️⃣ Good-better-best (GBB)
Each package is a bigger version of the one below it. Use this when your product does one thing and value scales with how much of it someone needs.
Slack’s Free, Pro and Business+ are the same product with more history, more controls and more scale as you climb.
Startups drift toward GBB by default, usually by accident.
The story goes: company has one paid plan, grows, and gets told more tiers mean more revenue.
So they take whatever feature they just shipped, drop it into a new “Premium” plan next to priority support and a CSV export they scraped together, and keep stuffing Premium until it feels full enough to justify a third tier.
That’s how most early GBB pricing gets built. It’s also inefficient and the wrong way to package.
Every package needs a clear purpose and a clear audience, and that purpose decides which features go where.
How hard a feature was to build has zero bearing on which tier it belongs in. None.
So if it isn’t obvious yet: use GBB only when you have no better option.
Otherwise, reach for job-based packaging first. It’ll serve you far better, because it maps your pricing to how customers actually think about what they’re buying.
Which features actually matter
Once you have your packages, you need to sort your features into them. Which features carry weight, and which don’t?
The value matrix gives you a clean way to decide.
It’s a four-quadrant grid.
→ The vertical axis is willingness to pay, low to high.
→ The horizontal axis is customer preference, low to high, how much people actually want the feature.
Every feature you’ve built drops into one of four buckets.
Value drivers (high preference, high WTP)
Your standout features, the ones that make a customer go “ah, that’s why I upgrade.”
These are what your packaging revolves around. Every tier should have at least one, and you use them to structurally pull customers up the ladder. Put them in your higher tiers.
Core features (high preference, low WTP)
Everyone expects these features. Put them in every package and never gate them. If you find yourself having no value drivers (and only core features), you only have one tier.
Add-ons (low preference, high WTP)
A small, specific slice of users wants these, and that slice will happily pay a premium.
Not enough demand to justify a whole tier. Keep them out of the standard packages and sell them à la carte.
Forgettables (low preference, low WTP). No one asked for them, and no one will miss them. Question why they exist, and at minimum, stop talking about them.
When companies go through this exercise, they often get stuck on what is a Value driver vs Core feature.
Ask yourself:
Would a customer pay more for this, or do they just expect it to be there?
✅ Pay more means value driver
✅ Expect it means core.
The truth about “Enterprise” plans
Enterprise is a way of buying, not a wallet size, and not a bundle of fancy features.
The two classic mistakes are setting an arbitrary revenue or headcount cutoff, and stuffing the enterprise plan with your coolest features.
Both misunderstand what an enterprise buyer is.
❌ They aren’t defined by size (though they correlate with size)
✅ They’re defined by how they operate, what processes they run, and how they see themselves.
I’ve seen 200-person companies behave like full enterprises, and I’ve worked with companies like Booking.com, well past 10,000 employees, that still operate like startups.
❌ Enterprise mistake 1: Setting an arbitrary revenue or headcount cutoff
Force a self-serve company to “contact sales” because they crossed 1,000 actions or some ARR line, and you’ll not just annoy them, but by forcing them into an Enterprise contract, you’re going to be giving them a discount, and you’re going to pay your sales rep commission, lose-lose.
❌ Enterprise mistake 2: Stuffing the enterprise plan with your coolest features
An enterprise buyer doesn’t buy software because it has better features. They buy it because it clears their internal legal, security, and IT requirements.
So your enterprise plan shouldn’t gate your core product value behind a sales call. It should hold the plumbing that lets corporate procurement hit “approve”:
What enterprise is
✅ SSO and SAML,
✅ advanced audit logs,
✅ custom roles and permissions,
✅ data residency,
✅ dedicated SLAs,
✅ procurement-friendly invoicing.
What enterprise is not:
❌ access to the “best AI models,”
❌ advanced analytics,
❌ or faster performance.
Keep your actual product value in the standard tiers. Let enterprise be the operational toll bridge that corporate IT is required to pay.
Avoid the survey trap
When founders finally decide to fix their pricing, many of them turn to academic market research.
They send out elaborate surveys, run a conjoint analysis, or build a Van Westendorp price sensitivity meter.
Don’t.
For almost every situation, and always for early-stage startups, traditional pricing surveys are a counterproductive waste of time, for two reasons.
❌ You can’t survey a structure
A survey can only ask what someone would pay for one isolated thing.
It can’t capture the interaction between your value metric, your feature gating, and your tiers, and structure is exactly where the leverage lives.
You’d be researching the 20% and ignoring the 80%.
❌ Opinions are cheap, credit cards are not.
There’s a wide psychological gap between a person typing a hypothetical number into a text box and a buyer actually pulling out a company card to kill a painful bottleneck.
The first costs nothing and predicts almost nothing.
Market-testing beats market-research
Stop trying to predict the future with data that doesn’t exist yet. Replace academic research with conversation and real deployment.
Talk about value, not numbers.
In discovery calls, never ask
“what would you pay for this?”
Ask questions that surface their economic reality instead:
“How much time does this bottleneck cost your team each week?”
or
“What happens if this breaks for a day?”
Quantify the pain first, then design the structure around it.
Then ship the pricing page.
Your single most accurate data point is a conversion.
Get a high-conviction Pricing V1 live, fast.
If nobody pushes back on the price, it’s too low.
If everyone walks, you’ve got a packaging or value-metric problem, not a number problem.
Real users paying real money will teach you more in a month than any survey will in a quarter.
The short list of don’ts
To close, here are a few additional pricing mistakes we often see startups making:
❌ Don’t blindly copy competitors
At best, their structure was built for their value metric, their ICP, and their stage.
At worst (much more likely), they have bad pricing, which holds them back. Use pricing as your competitive advantage.
❌ Don’t use cost-plus to land on your price
In software, what it costs you to build has nothing to do with what it’s worth to your customer.
❌ Don’t undercharge
Near-universal among early founders. If no one ever flinches at your price, you’re too cheap. Some pushback is good!
❌ Don’t throw features into tiers at random
Every feature placement should follow from a deliberate packaging strategy, never from how much effort the feature took.
That’s the whole loop:
Get the mindset right → fix the structure before the number → find the value metric → let the model fall out of it → package around jobs → sort features with the matrix → and ship a V1 you can tune with real data.
None of it is one-and-done.
The founders who win at pricing aren’t the ones who got it perfect on the first try. They’re the ones who started simple and kept iterating.
We roast your pricing page for free 🔥🔥🔥
Serge and I are offering to roast your pricing page for free.
A 5-min Loom video with our honest take. No strings attached.
Just reply to this email with your pricing page URL and we’ll record one for you
Happy growth.
Alex + Serge
3 ways I help founders build a strong GTM foundation 👇
If you’re somewhere between €0 → €1M ARR, I can help you with your GTM.
1️⃣ Free GTM Foundation Library
→ 50+ resources (guides, templates, frameworks)
2️⃣ GTM Audit
→ 360° assessment + 6-month action plan: Your GTM Blindspots revealed
3️⃣ 1:1 GTM Advisory
→ Work directly with me to build your GTM
 | A guest post by
|
Make sure you submit your pricing page for a review. Info at the bottom of the article.