SaaS pricing strategy for founders. How to set your first price without guessing

Your cost to serve one customer sets the floor. What buyers say they would pay sets the ceiling. Your first price is a deliberate point between them, not a guess. Companies that combine a base subscription with a usage component report the highest median growth rate at 21 percent.

That is the short version of a guide to SaaS pricing for someone who has never done this before. Most founders arrive at their first price by looking at a competitor and shaving a bit off, which produces a number nobody can defend and nobody can move. This article gives you the two boundaries, the four questions that find them, and the decision rules for choosing what to charge for.

What is a SaaS pricing strategy, and how is it different from a pricing model?

A SaaS pricing strategy is the decision about what your price is based on and what you optimise for. A pricing model is the mechanic that calculates the charge. Strategy answers why that number. The model answers how the number is counted.

The distinction sounds academic until you notice what it does to your reading. Every major guide on this topic separates strategy from model, and it is the one framing all of them agree on. Treat the two as the same thing and you go looking for advice about pricing strategy, then come back with a list of billing mechanics. That is how so many founders finish their research knowing exactly what tiered pricing is and still having no idea what to charge.

Strategy comes first because it constrains the model. If your strategy is to price against the value a buyer gets, you need a unit of value to charge for. If your strategy is to buy market share fast, you need a model that makes the entry price small. One pricing model can serve completely different strategies, which is why copying a competitor's pricing page copies their mechanics and none of their reasoning.

There is also a reason this decision feels heavier in software than elsewhere. Traditional software asked a customer for one large payment up front, and the vendor lived with that number for years. A subscription turns that into a recurring relationship. You get predictable revenue, and you get the option to correct the price as you learn. Plans based on usage and on outcomes now grow at the same pace as straight subscriptions, which used to dominate, so the default is no longer obvious.

Why do first-time founders underprice a new SaaS product?

Underpricing feels safer because a low price is easier to defend in a first sales conversation. It is not safer. Raising a price later is harder than lowering one, and every month spent at the wrong price is a month of data you cannot use.

There are three ways founders talk themselves into a number that is too low. The first is anchoring on competitor pricing, where you find the cheapest thing in your category and go under it. The second is pricing from your own wallet, where you pick a number you would be comfortable paying yourself. That tells you about your budget and nothing about your buyer's. The third is pricing from cost, adding a profit margin to what the product costs you to run, and it is the most rational-looking mistake of the three.

Undercharging does specific damage. You end up funding development and delivery out of a price that never accounted for either. You attract the buyers who care most about cost and least about outcome, so the customers hardest to serve arrive first and set the tone for your roadmap. A price set too low does not lose you a sale. It loses you the margin that was going to pay for the next twelve months of building.

Overpricing is a real risk too, and it fails differently. A price that is too high produces silence, and silence is ambiguous. You cannot tell whether the problem is the price, the product, or the way you described it. Founders working out how to start a SaaS company treat price as the last decision, when it is one of the first that constrains everything else. The asymmetry is what matters. A price that is too high gives you an objection you can hear, and a price that is too low gives you a business that quietly does not work.

Try our developers.
Free for 2 weeks.

No risk. Just results. Get a feel for our process, speed, and quality — work with our developers for a trial sprint and see why global companies choose Selleo.

Test our team

Share this offer

How do you find your price floor and ceiling before you have a customer base?

Work out two numbers before you pick a price. What it costs you to serve one customer for one month is your floor. What buyers tell you they would pay is your ceiling. Your first price is a deliberate choice between the two.

This is the part almost nobody writes down. The guides that dominate this topic answer which model to use, and they answer it well. Not one of them tells you what number to put on the page on the day you launch, which is the only question a founder without customers actually has. The single piece of arithmetic that produces a concrete price in those guides is cost plus margin. The same guides that show it then advise against it for software, because the cost of serving one more customer says nothing about the value that customer receives.

So treat cost as a boundary, not a method. Cost plus pricing tells you the lowest price you can survive. It never tells you the price you should charge. If you plan to build an MVP with an experienced team, the price you land on decides how small that first version can be, which makes this a scoping decision as much as a commercial one.

Here is the sequence that gets you to a defensible number.

1. Calculate your cost to serve one customer for one month. That is your floor, and it is not negotiable.
2. Run price sensitivity questions in your customer conversations to find the range buyers accept. The top of that range is your ceiling.
3. Choose a point between the two, closer to the ceiling than the floor, and write down the reason you chose it.
4. Say the number out loud to the next five prospects and watch what happens before you publish it anywhere.

Write down the reasoning, because a price you can explain is a price you can change, and a price you guessed is a price you will defend long past the point of usefulness. Companies that price on value have to do real research into what buyers will pay. The price they land on reflects the outcome the customer experiences, not the effort the vendor spent.

How do you calculate what it costs to serve one customer?

Add up what one customer costs you in one month. Infrastructure, support time, payment processing fees, and any per-seat licences you pay for on their behalf. Below that number, every new customer makes your situation worse.

Software has almost no cost per copy, which fools people into thinking it has almost no cost per customer. It does. Servers scale with load, support scales with confusion, payment processors take a percentage of everything, and the tools you resell inside your product bill you per user. These are your operational costs, and they exist whether or not anybody is tracking them. The stack behind your product shapes your cost to serve, which is why teams offering Node.js development services can estimate your infrastructure cost per customer faster than you can.

Two things to get right here. Estimate on the high side, because an underestimated floor is worse than no floor at all. And leave customer acquisition cost out of this particular calculation. Acquisition decides whether the business works. Cost to serve decides whether each individual customer works. Those are two different questions, and mixing them is how founders end up with a price that covers marketing and not delivery.

How do you research willingness to pay with no customers?

Ask four price sensitivity questions in the conversations you are already having. At what price is this too expensive to consider. At what price does it feel expensive but still worth thinking about. At what price does it feel like a bargain. At what price would it be so cheap that you would doubt the quality.

The method is called the Van Westendorp price sensitivity meter, and it has been standard market research for decades. It appears nowhere in the guides that currently rank for this topic, all of which recommend researching willingness to pay and none of which say how. The four answers give you four points. Where the too-expensive and too-cheap curves meet is the outer edge of what your market tolerates, and the band between them is where your price belongs.

You do not need three hundred survey responses for this to be useful. Fifteen conversations with people who have the problem will show you a pattern, and the pattern is what you need. Willingness to pay moves with the stakes involved. Buyers of custom fintech solutions price risk into their budgets in a way that buyers of internal tools never do. The same goes for custom healthcare software, where compliance turns a nice-to-have into a line item somebody has already budgeted for.

There is a second method worth knowing once you have a candidate price. You name a price and ask whether they would buy at it, then repeat with a higher one, then higher again, until they stop saying yes. That approach is called Gabor-Granger, and it gives you a demand curve instead of a range. Asking someone what they would pay without any structure produces a number that is polite, low and useless, which is why the question needs a shape.

One warning about segments. The same feature carries different value for different customer segments, so a single willingness to pay figure across a mixed group averages away the information you were looking for. Ask who they are before you ask what they would pay.

What are the most popular SaaS pricing models, and which one fits a new product?

Six models cover almost every SaaS product. Flat rate, per user, tiered, usage based, freemium and hybrid. For a product with no customers, the right choice is the simplest one you can price honestly, which comes down to one plan or two.

Companies combining a base subscription with a usage component report the highest median growth rate at 21 percent, and that model needs usage data a pre-launch product does not have. A full breakdown of SaaS pricing models sits in a separate guide, so this section stays with the decision and skips the taxonomy.

Three numbers put that table in context. Hybrid models report the highest median growth rate at 21 percent, which is the clearest link between pricing and revenue growth in the available data. Seventy-three percent of companies running usage based pricing actively forecast variable revenue, which tells you how much operational work that model adds. And 44 percent of SaaS companies now charge for features powered by artificial intelligence, because compute costs money every time somebody uses it.

Two of these deserve a plain description before you go further. Flat rate pricing means one price for everything, which gives a buyer predictable costs and is the easiest structure to explain and the easiest to outgrow. Per active user pricing charges only for the people who actually log in during a billing period, which protects a buyer from paying for dormant accounts and makes your own revenue harder to predict.

The right pricing model at this stage is the one you can explain in a sentence and change in an afternoon.

That last point is changing the default. Per user pricing assumes the value a customer gets scales with how many people log in. When the expensive part of your product runs on every request instead of every seat, charging per seat means your best customers cost you the most and pay you the same. The mechanics of billing, plan changes and metering are where SaaS development services earn their keep, because a pricing model you cannot implement is a pricing model you do not have.

So which one, and when. With zero customers and no usage data, start with one plan or two instead of a full tier structure. If your cost to serve is variable and high, which is now normal for anything with a model call inside it, put a usage component in from the start. If you want predictable revenue plus expansion as your customer grows, the hybrid of a base fee and usage has the strongest growth numbers behind it. If you are reaching for cost plus margin, use it to find your floor and then put it down. If freemium is tempting before you have revenue, wait, and the next section explains why. If you have had fewer than ten conversations with real buyers, you are not ready to set a price at all. And if you sell to enterprise buyers, do not publish a number, because that segment expects a conversation and reads a public price as a ceiling.

How does the tiered pricing model work, and how many pricing tiers should you launch with?

Tiered pricing offers several packages at different price points for different customer segments. For a first launch, one or two tiers beat three or more, because every extra package splits traffic you do not have yet.

The tiered pricing model bundles capability, capacity or support into named plans, so a buyer self-selects into the one that matches their situation. It is the most common structure in business software for a good reason. One product can serve a small team and a large one without two separate sales motions. There is a catch. The boundaries between tiers are the hardest part to get right, and they are normally set from usage data a pre-launch product has never collected.

The advice available on how many tiers to launch with is a mess. Four of the most visible guides on this topic recommend one to two, two to four, two to five, and an observed average of three and a half. Not one of them cites a study, which is worth knowing before you treat any of those numbers as a benchmark. The evidence that does exist is about choice, not pricing. In a well-known field experiment, a display of twenty-four options produced purchases from 3 percent of shoppers while a display of three options produced purchases from 30 percent.

That finding is twenty-five years old and it still holds, because it describes how people behave when comparison turns into work. Nothing about it was specific to a market or a decade. Applied here it gives you a simple rule. Every tier you add divides the visitors you have, and before launch that number is zero. Start with the smallest pricing structure that can express your pricing plan honestly, then add a tier once you have evidence that a segment is being badly served by the ones you already have.

One more thing about boundaries. A tier only works when the buyer recognises themselves in it, so the line between two packages has to match customer expectations about who they are, not your internal view of small and large accounts.

When does a freemium pricing model hurt customer acquisition for a new SaaS product?

A freemium pricing model gives basic features away and charges for advanced features. Before you have revenue, free users are a cost you fund yourself, and no credible published figure tells you what share of them will convert.

The freemium model uses the free tier as the top of the funnel, which makes customer acquisition cheaper in exchange for carrying people who pay nothing. That trade is reasonable when you have money to carry them with. At pre-seed, the money carrying your free users is the money that was supposed to build the product. Every free account still costs you infrastructure, support and payment overhead, and none of those bills are optional.

The conversion numbers that circulate on this topic do not survive checking. The figure quoted most for what share of free users become paying customers appears without a source, without a year and without a method, in guides that cite carefully everywhere else. A model whose entire business case rests on a conversion rate nobody has documented is a model to approach with your eyes open.

Two conditions make free worth it early. The first is a genuine network effect, where a free user makes the product better for the paying ones. The second is a product where the free tier is the distribution, because people share it as part of using it. If neither applies to you, a time-limited free trial gives you the same signal about intent without an open-ended obligation to strangers.

How do you pick a value metric that grows with customer value?

A value metric is the unit your customer pays for, and it should grow as the value they get grows. Pick the unit your customer would name if you asked what they are actually buying.

This is the most useful idea in the whole topic and the easiest one for a non-technical founder to act on, because it is a business question and not a technical one. Value based pricing lines your price up with the value a buyer perceives, and it can raise revenue without adding a single feature. The test for a good value metric is whether your customer's bill goes up in the same month their results do.

The right unit also tells you something about customer needs that a feature list never will. Every step up in the metric should deliver incremental value the buyer can point at, which is what stops an increase in their bill from feeling like a penalty for growing.

Some examples of units and the value they track.

• Seats, when the product's value comes from people collaborating inside it
• Transactions processed, when the product sits on a flow of money or orders
• Records or contacts stored, when the value is the asset the customer accumulates
• Messages, requests or generations, when each use costs you and delivers something
• Locations, sites or entities managed, when the customer's world is structured that way

In custom e-commerce solutions the value metric is transaction volume, because that is the number the buyer already watches every day. Products built as custom software development services tend to have a clearer value metric than off-the-shelf tools, since the unit of value was defined with a specific buyer in mind and not averaged across a market.

The wrong metric does not fail immediately. It fails when you scale. A unit that stops tracking value will eventually punish your best customers, and pricing built on value has to be revisited as your product and your market move.

How do you price your first customers and design partners?

Give your first customers a discount on price, never a discount on the pricing plan itself. Write the standard price into the contract, then apply a named early adopter reduction with an end date.

Almost nothing has been written about this, and it is where founders lose the most ground. The guides that rank for pricing address companies with a price list already in place, so the first commercial conversation a founder ever has is the one with no guidance behind it. A price you never charged is a price you cannot defend later, which is why the discount has to sit on top of a real number and not replace it.

Be clear with yourself about what the discount buys. An early customer paying half price should be giving you something specific back. Structured customer feedback on a schedule, a reference conversation with your next prospect, permission to describe the work, or a commitment to actually use the product instead of signing up and disappearing. A discount granted for nothing teaches your first customer that your price is soft, and that lesson travels to everyone they talk to.

You will also be doing this yourself, without a sales rep between you and the buyer. That is an advantage at this stage, because the person hearing the objection is the person who can act on it.

Three things belong in that first agreement. The standard price, stated plainly. The size and the reason for the reduction. And the date or the condition on which it ends. Telling somebody about a price change early and transparently keeps their trust intact, and doing it from the start is far easier than negotiating it after the fact.

How do SaaS businesses test and change a pricing plan in the first 90 days?

Treat your first price as a dated decision, not a permanent one. Set a review date 90 days out, decide in advance which signals mean the price is wrong, and change it on new customers first.

Most founders set a price once and never come back to it, which turns an experiment into an assumption. Regular reviews let you adjust as the market moves, and one advantage of selling software is that you can correct pricing on real customer data without waiting for a product cycle. Deciding what a wrong price looks like before you launch is the difference between reading a signal and rationalising it. Pricing decisions get easier every time you make one with evidence in front of you.

Three signals are worth naming in advance. No resistance at all in sales conversations means you are under your ceiling, possibly far under. Total resistance from everybody means you are over it, or your value story has not landed. Customers who churn inside the first two billing cycles are the clearest sign of a mismatch between price and value, because they bought and then decided it was not worth it.

Churn is the metric that matters most once money is moving, because subscription businesses live on customer lifetime value and not on the first payment. Average revenue per account will tell you the same story more slowly. Before you have enough history for either number to mean anything, watch the conversations. Count how many prospects ask for a discount, how many go quiet after seeing the price, and how many say yes without blinking. Pricing is one decision inside a longer sequence, and how to build a SaaS product from validation through to billing covers the steps on either side of it.

How do you raise prices without losing existing customers?

Raise the price for new customers first and leave existing ones on the old rate. Tell them what is changing, why, and what it means for them before they find out from an invoice.

You have three routes. Change the price for new customers only and hold your existing base indefinitely, which costs you revenue and buys you goodwill. Give existing customers a transition period with a stated end date, the middle path most companies take. Or move everybody on a fixed date, the fastest option and the one that needs the strongest value story. Keeping early customers on their original rate is a deliberate cost, and it comes in cheaper than the churn and the reputation damage of surprising them.

Silence is the worst option available. A customer who discovers a change in their subscription prices on a bill experiences it as something done to them, and that reaction is about the process and not the money. Handled well, a price increase costs you very little in customer retention. Handled quietly, it costs you the customer loyalty you spent a year building.

Write the conditions for change into your first contract. Multi-year agreements now account for 40 percent of SaaS contracts, up from 14 percent in 2022, so the commitments you sign early increasingly outlast the price you signed them at. A clause covering how and when the price can move is a five-minute conversation before signature and a much harder one three years in.

How does your pricing decision change what you should build first?

Your price tells you what to build first. The feature your value metric is attached to is the feature that has to work at launch, and everything a customer would not pay for can wait.

This is the part that surprises founders. Working out what you charge for is also working out what you have to deliver, because a value metric is a promise with a number on it. Charge per transaction processed and the transaction path has to be solid before anything else looks good. A pricing decision made early turns an open-ended feature list into a ranked one, and that is the cheapest scope reduction available to you.

Teams that run a structured product discovery phase before writing code cut the build down to what the price can actually justify. At Selleo that stage typically reduces the build budget by 50 percent, because most of what a founder plans to build in version one turns out to be something no buyer was going to pay for. Developers who ask why a feature exists before they build it catch that mismatch earlier than any specification will.