Pricing is the most-googled, least-understood founder decision. Most posts on the topic are either marketing fluff ("charge what you're worth") or framework dumps that assume you already know your buyer. Both miss the founder's real problem: you have to ship a number to a landing page before you have the data to defend it.
What follows is a practical protocol. It will not tell you the right price for your product — no article can. It will get you to a defensible first price in seven days, with two more revisions baked in at day thirty, sixty, and ninety.
The mistake that locks in bad pricing
Most founders pick their first price by triangulating from competitors. They look at three tools in the same category, average the prices, shave 20% to undercut, and ship. This is a fast way to underprice the value and commit to a long, painful repricing exercise twelve months later.
The deeper mistake is that "competitive pricing" optimizes for the wrong question. It answers "what do similar tools charge?" when the actual question is "what does this specific buyer pay today to solve this problem?" Those rarely match.
The four-question pricing diagnostic
Before you pick a number, you need four answers. If you can't answer all four in one paragraph each, you don't have enough information to price — you have enough to go interview five buyers first.
1. Who specifically buys this?
Not "small businesses." Not "founders." The named role at a named company size, with the budget authority. "Founders building B2B SaaS who do all the marketing themselves." "Engineering managers at 50–200 person companies." The more specific, the cleaner your pricing math.
2. What's the current alternative?
Every buyer already solves this problem somehow — a competitor, a spreadsheet, a contractor, an unpaid intern, or just gritting their teeth. The current alternative is your real pricing anchor. If they're paying $300/month for a contractor doing it badly, you can charge $99/month and feel like a steal. If they're using a free spreadsheet, you're competing with zero plus their time, which is a different math problem.
3. What's the painful unit they pay for?
Every product has a billing unit — per user, per project, per usage, per month, per document. The unit should map to the thing that causes pain. For a project management tool, "per project" makes no sense (you'd rather have ten projects). "Per team member" makes sense if adding teammates is the moment value compounds. The painful unit is the one the buyer would happily expand on as they grow.
4. What's your scarce input?
Pricing isn't only about what the buyer will pay. It's also about what protects you. Every founder has a scarce input — your time, your expertise, your data, your support capacity. If you sell support-heavy software at €9/month, you'll be priced into a death loop. The price you can hold is shaped by the scarcest input in your system, not by what the market "supports."
The three pricing structures that actually work for first-product founders
There are a hundred pricing structures in the wild. For a first product, almost all of them collapse into three workable shapes:
Flat-rate per user
One price, paid monthly or yearly, per active user. Predictable for the buyer, predictable for you. Best when your value is "this person uses it daily" — productivity tools, design software, founder-education apps.
Tiered by usage or features
Three tiers (Starter / Pro / Team) with one price per tier. Best when usage genuinely differs between buyers — small teams need less than large teams. Risky if you can't actually differentiate the tiers; visitors stare at the table and bounce.
Lifetime with limited supply
A one-time payment for permanent access, capped at a defensible number (often 100, 500, or 1,000). Best for pre-launch and very early product, when you need to fund the runway without VC and the buyer base is small enough that lifetime math works. We use this for the MoatKit Founders' Charter.
How to pick your starting number — the three-buyers test
Once you've answered the four diagnostic questions and picked a structure, you have to pick a number. The cleanest test is also the simplest:
Would three people in your target persona pay this price today, knowing what you know about your product?
Not "would they like it?" Not "would they consider it?" Would they take out a credit card. If the honest answer is yes, you've underpriced. Go higher. If the honest answer is "maybe one of them," you've found a defensible starting number. If the honest answer is "no," go lower or go fix the value first.
The reason this works: founders are notoriously bad at pricing in the abstract, but quite good at simulating specific people's reactions. Naming three buyers forces specificity. Imagining their actual response gets past the abstract "what should we charge."
The 90-day pricing review cycle
Your first price is a hypothesis, not a commitment. Build in a review cadence before you ship it, so changing the price doesn't feel like an admission of failure later.
Day 1–30: launch at the provisional price
Ship the number, watch what happens. Don't change anything for thirty days. Track two metrics only: conversion rate (visitor → trial → paid) and refund / cancellation rate within seven days. Everything else is noise in the first month.
Day 30–60: read the signal
Conversion under 1% and refunds under 5%? Price might be too high — but also might be that the message, audience, or product is off. Don't reprice yet. Run five customer interviews and ask the people who didn't buy why. Often the answer is "I didn't get what it does," not "it's too expensive."
Conversion above 5% and refunds under 5%? You probably underpriced. Plan a 20–30% increase at day 60.
Day 60–90: revise based on data, not opinion
Make one pricing change at day sixty, then leave it alone for thirty days. If you change pricing every two weeks, you'll never know which change moved which number. Day 90 is the next decision point.
What pricing looks like inside MoatKit
Pricing is one of the cross-cutting tracks inside the MoatKit app — not a single pathway, but a thread that runs through validation, launch, and traction. The structure is the same one above: a four-question diagnostic, the structure choices, the three-buyers test, the review cadence. You also get a pricing-pressure-test playbook that takes your current price, your alternative, and your scarce input as inputs and generates a one-page memo you can run by a peer.
The point isn't that pricing is hard — it's that pricing without a method is exhausting, and most founders waste six months relitigating their number when the real problem is they never had one. Pick one. Defend it for ninety days. Then revise based on what the buyer actually did.