How to Price a SaaS Product When You Have No Investors

If you are working out how to price a SaaS product with no investors behind you, start with the unit your customer already counts, such as projects, users, messages or minutes, and charge on that. Set a first price that still leaves you money after payment fees, tax handling and running costs, then test it with real buyers and change one thing at a time. Revenue is your runway, so the price has to work from the first sale.

Disclosure: ZeroRaised publishes this guide and appears in the final section. The fee and tax notes are editorial guidance, not legal, tax or financial advice, and nothing here promises traffic, sales or revenue results. Prices and fees were checked on the linked pages on 18 Oct 2026 and can change.

TL;DR#

Pricing a bootstrapped product comes down to four decisions: what the customer pays for, how much, through whom, and on what terms. A funded company may choose to price low for a while and let investor money cover the gap. You can't. Every plan you sell has to pay its share of hosting, payment fees and your time from the day it goes on sale, which is why the order of decisions matters more than the exact number you start with.

Work through it in this order:

1. Name the value metric: the thing your customer already counts and would expect the bill to follow.
2. Pick the model that charges on that metric. The usual options are flat, per seat, tiered by usage, prepaid credits, metered, or a one-time licence.
3. Set a first number from the value of the job and your own costs, then check what the payment fee takes on that ticket size with the payment fee calculator.
4. Choose a merchant of record or a payment processor before launch, because it decides who deals with VAT, refunds and chargebacks.
5. Decide how buyers reduce their risk: a free trial, a refund window or a free allowance.
6. Test prices and raise them one variable at a time. Treat a small sample as a signal and nothing more.
7. Publish an honest pricing page that states the renewal terms, the cancel route and any spend cap.

If you only read one part, read the model comparison table further down. It sets the six common models against live pricing pages and shows where each one tends to go wrong. The fee table after it explains why a very cheap plan can lose a surprising share of every sale before you see a penny.

This week's price test: a Mac app that dropped its trial and doubled its price#

On 18 Oct 2026, Otabek published "How I Made My First $500 Selling Mac Apps in 23 Days" on DEV (checked 18 Oct 2026). It covers two apps. Halo turns the MacBook notch into something like a Dynamic Island, and Shedi is a disk cleaner for developers. Both are sold through Lemon Squeezy.

The pricing story is in two sentences about Halo. First the launch: "It launched October 2 at $4.99 with a three-day trial and finished #31 for the day with 70 upvotes, which is nowhere near the top and still enough to start selling." Then the change nine days later: "With version 2.0 on October 11 I dropped the trial, made it paid-only and doubled the price to $9.99. Sales didn't stop."

And the totals, reported gross and net side by side: "On October 16 the sales bot in my Telegram posted a line I'd been waiting for: all time, 69 orders, $530.85. After Lemon Squeezy's cut, about $470 of that is mine. One refund in the whole run."

Before you copy any of this, be clear about what it is. Halo and Shedi are one-time-purchase Mac apps, not SaaS subscriptions: the Halo site lists it at "$9.99 One-time, no subscription" (checked 18 Oct 2026). Otabek's 18 Oct 2026 post lists Shedi at "$19.99, one-time, or $27.99 for two Macs." On the same day, the Shedi site showed an early price of $9.99 for the first 50 buyers, so check the site for the current price. There are no renewals here, no hosting bill per customer and no monthly churn. Sixty-nine orders across two apps from one maker is a small sample. On 11 October three things also changed at once: a new major version, no trial and a higher price. So nobody, including the maker, can say how much of the result came from the price alone. It is one data point, not a pattern.

It is still worth studying, because it is a clean, dated price test with the numbers attached. You can even check the fee. If you assume Lemon Squeezy's base listed fee of 5% + 50¢ applied to every order (the post does not say which fees applied), the arithmetic runs like this:

5% of $530.85      = $26.54
50¢ x 69 orders    = $34.50
Total fees         = $26.54 + $34.50 = $61.04
Net                = $530.85 - $61.04 = $469.81

That lands close to the "about $470" in the post. Treat it as a best case: Lemon Squeezy's fee docs add "+1.5% for international (outside of the US) transactions" and calculate the fee on the total order value, and the post names buyers in Germany and Sweden. Under the base-fee assumption, the fixed 50¢ took more than the percentage did on these small tickets. We will come back to that.

Halo also went on Product Hunt, and that is a reminder that launch day is a pricing moment as well as a traffic one. Launch codes, early prices and trial terms are all on show at once, so decide them before you pick from the options in where to launch a SaaS.

Two other launches the same week priced on a usage unit rather than a licence. Forwarder.cc and Vitko Runners appear in the model section below.

How to price a SaaS product: start with what the customer counts#

The value metric is the unit your price scales with. It matters more than the first number, because a wrong number is easy to change next month while a wrong metric is baked into your billing code, your pricing page and every customer's expectations.

A good metric has three properties. The customer already counts it without your help. It grows roughly in line with the value they get. And it is predictable enough that they can guess next month's bill. To make that concrete, here are some illustrative cases rather than rules:

• A form backend might count messages delivered, because that is what the customer sees arrive in their inbox.
• A CI service might count build minutes, since that is what it costs to run and what the buyer's team watches.
• A project tool might count active projects, or nothing at all, if a team of three and a team of thirty get much the same out of it.
• A collaboration tool might count users, because each extra person is another seat that gets value.

If you are deciding how to price your SaaS, write the metric down before any number. Then test it against four questions:

1. Who signs off the purchase, and what do they already measure?
2. Does usage swing a lot from month to month, or is it steady?
3. Can you measure the unit reliably in your own code, including refunds and failed jobs?
4. Could a customer predict their bill before it arrives?

A "no" to the last question doesn't kill a metric, but it means you need a cap, a prepaid pack or a clear alert. More on that below.

For a business buyer the answer often maps to seats or workspaces, since that is how their finance team budgets for software. That is the usual starting point when working out how to price a B2B SaaS product, but check it against how the product is actually used. If one admin does all the work for a whole company, per seat charges for people who never log in.

The number itself should come from the buyer's side of the table: what they pay today for the same job, whether that's another tool, a contractor or a few hours of spreadsheet work each week. Ask people who would actually pay. The interview method is in the guide on how to validate the idea before building, so it isn't repeated here. It also helps to have one clear customer in mind before you price for everyone, which is the point of the first step for new SaaS growth.

Pick a pricing model that matches the value metric#

Once the metric is fixed, the model mostly follows from it. Stripe's documentation on recurring pricing models gives a tidy set of definitions (checked 18 Oct 2026). With flat rate pricing, customers choose a service tier "and pay a flat rate for it". With per seat pricing, "Each pricing unit represents one user." With tiered pricing, "The unit cost changes with quantity (volume-based pricing) or usage (graduated pricing)." And for usage-based pricing, "The models for this kind of pricing include fixed fee and overage, pay as you go, and credit burndown."

Here is how those models look on live pricing pages, plus the one-time licence from the hook for contrast.

A few notes on reading that table. GitHub's $4 is the list price shown on the page, which also carries a note about the first 12 months, so treat it as an example of shape rather than a settled figure. Basecamp's top tier, Unlimited, is "$299 /mo, billed annually". Plausible's docs say "All plans start at the same pageview tiers. The difference is features and team size." That is a neat way to keep the usage band and the feature set separate.

The flat versus per seat trade-off is easy to see with simple arithmetic, and both examples are in dollars, so it is like for like. Ten users on GitHub Team at the listed price is 10 x $4 = $40 a month. Basecamp Pro is $99 a month whatever the headcount. At 25 users, per seat reaches 25 x $4 = $100, which passes $99. That doesn't make either product better. It shows where each model starts to favour a different size of customer, and that is a decision you make on purpose when you pick your own model.

For credits, Forwarder.cc spells out the unit price itself: 5 € / 500 = 0.01 € a message on the small pack and 12 € / 1,500 = 0.008 € on the larger one. A bulk discount is built into the pack sizes without any discount codes.

This week's usage pricing: Forwarder.cc and Vitko Runners#

Forwarder.cc launched as a Show HN on 15 Oct 2026, posted by calyhre (checked 18 Oct 2026). It forwards static-site form submissions to an inbox, and the post describes the pricing in one line: "It runs on credits, 1 credit = 1 message, no subscription." The maker says they wanted something cheaper than existing tools "and without a subscription", which is a pricing position as much as a feature.

Vitko Runners is from Vitko, Inc., a company rather than an indie maker, and it opened a private beta of managed GitHub Actions runners on 15 Oct 2026. Its announcement prices by the minute: "$0.002 a minute, billed per second, which is a third of GitHub's list price." It also says "No seats and no machine sizes to pick." The free allowance is 2,000 minutes a month, which at the listed rate is 2,000 x $0.002 = $4 of usage.

Both picked a unit the buyer already counts. Someone running a contact form thinks in messages. Someone paying a CI bill thinks in minutes. Neither asks the customer to learn a new concept before they can work out the cost.

Usage pricing needs a ceiling#

The risk with any usage model is the bill nobody expected. Vitko addresses it directly: "There's also a hard monthly spend limit, so new jobs wait instead of running up your bill." Prepaid credits have a ceiling built in, since you buy a pack and spend it. Metered billing has no natural limit, so if you meter, add a cap or at least an alert, and put it on the pricing page rather than in the settings.

Set the first number from value and costs, then check the fees#

The honest answer to how much to charge for a SaaS is a range you then test. Build it from three things, in this order: what the buyer pays today for the alternative, your floor (hosting, tools, domains and payment fees per customer), and a price you can explain in one sentence. Competitors' launch discounts make a poor anchor, because you can't see their margins. Keeping your own running costs low lets a modest price still cover them, and free startup perks without VC can help there. To see how many customers a given price needs to cover your monthly costs after payment fees, try the ramen profitability calculator.

Then check the fee on your actual ticket size. Lemon Squeezy's pricing page lists transaction fees of 5% + 50¢ and says "There is no monthly fee to use Lemon Squeezy for payment processing." Paddle's pricing page lists "5% + 50¢ per Checkout transaction". Stripe's UK pricing lists "1.5% + 20p for standard UK cards" and 2.5% + 20p for European Economic Area cards (all checked 18 Oct 2026). For the US rates of Stripe, Paddle, Lemon Squeezy, Polar and five other vendors side by side, see our payment processor fee comparison.

The rows are in different currencies, so this is not a like-for-like price comparison, and no conversion is implied. The merchant of record fee also buys tax handling and liability that the Stripe row does not include; with Stripe you pay for your own VAT work on top, and no Stripe Tax price is given here because it wasn't checked. The point is the shape. On both schedules the fixed part dominates small tickets. A $4.99 plan gives away nearly three times the share that a $99 plan does (about 15.0% against 5.5%), which is a quiet argument for fewer, higher tiers or annual billing.

Merchant of record or payment processor is a pricing decision#

This looks like back-office plumbing, but it changes your margin and your workload, so decide it before launch. Lemon Squeezy's merchant of record docs put it plainly: "When a customer makes a purchase, they are buying from the merchant of record." The merchant of record handles everything relating to the purchase, "including collecting sales tax, processing refunds and chargebacks, and ensuring PCI compliance." Paddle's own explainer on merchants of record describes the same role: the MoR manages all payments and takes on liabilities "such as collecting sales tax, ensuring Payment Card Industry (PCI) compliance, and honoring refunds and chargebacks". A processor only moves the money. Stripe Tax promises to "Automate sales tax, VAT, and GST compliance on all your transactions", but with Stripe as your processor you remain the seller (both checked 18 Oct 2026).

UK and EU VAT in plain terms#

HMRC's guidance on digital services to consumers says: "If you make supplies of digital services to consumers outside the UK these are not liable to UK VAT. They may be liable to VAT in the country where the consumer is based." It adds that if you sell "via a third party platform or marketplace, the digital platform is responsible for accounting for VAT on the supply instead of you." For EU consumers, the European Commission runs the VAT One Stop Shop, a single registration and return point for cross-border sales under the rules in force since 1 July 2021 (both checked 18 Oct 2026).

The pricing consequence: decide whether your consumer prices include VAT, and whether you sell to businesses, consumers or both. A higher MoR fee can be cheaper than your own hours on returns. This is not tax advice, so ask an accountant about your own case.

Free trial, refund window or free allowance#

Each way of lowering the buyer's risk changes who signs up. Basecamp offers a 30-day free trial on paid tiers and 45 days on Unlimited, and Plausible's plan docs state "30-day free trial, no credit card required". Otabek went the other way with Halo: "Halo's first week had one; version 2.0 removed it and raised the price, and the sales rate held. A 14-day refund policy does the same job with less code, and in 69 orders one person has used it." Again, that is one maker selling a one-time licence. Forwarder.cc uses a free allowance: "Start now with 50 free credits" and "We won’t ask for your credit card". Vitko gives 2,000 free minutes a month.

A trial suits a SaaS that needs data or set-up before it shows value. Whatever you pick, measure paid conversion and refunds, not sign-ups, and remember that the early buyers in your first 100 users are also the ones whose renewals you will lean on later.

Test and raise prices without breaking trust#

Change one variable at a time: the price, the trial or the packaging. Halo changed three on one date, which is why its result is a signal only. Read results as counts with denominators: pricing page visits, checkouts started, paid orders, refunds. The same applies when you are testing how to price SaaS software after launch.

When you raise prices, tell existing customers before their renewal, decide whether current subscribers keep the old price, and publish the date. If you charge more per device or seat, say so on the pricing page before checkout, as Otabek's post does for Shedi's two-Mac licence. Otabek's line is worth keeping in mind: "Halo got better after people paid for it, not before."

Write an honest pricing page#

A pricing page should state:

• the metric, in plain words;
• what happens at a tier edge or usage cap;
• whether prices include VAT, and the currency;
• the renewal date and any reminder;
• how to cancel online, and the refund terms.

In the UK, the Department for Business and Trade's consultation on the subscription contracts regime (outcome added 2 April 2026, checked 18 Oct 2026) sets out "clearer pre-contract information", "reminders before renewals" and "straightforward ways to cancel". Build to that now. Vitko's spend limit, Forwarder's no-card credits and Otabek's refund window are good examples, not rules.

Price for runway when nobody is funding the gap#

Without investors, your price is part of how you fund the product, alongside the options in ways to fund a product without venture capital. As Otabek puts it, the first sales prove something thinking can't: "It's finding out that strangers in Minnesota, Germany and Sweden will pay for something you made, which is the one question you can't answer by thinking about it."

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. If your pricing page is public and honest, you can submit the product for review. The maker perks page and our free maker tools are separate resources, and neither replaces pricing work.

So, how to price a SaaS product in one line: charge on a metric the customer already counts, at a number that survives fees and tax, on terms you would be happy to read yourself, and test one change at a time.