Skip to main content

Pricing playbook · Operator diary · 2026

Per-decision pricing for B2B SaaS

Most pricing advice for first-time SaaS founders tells you to pick three tiers, anchor the high end, and call it done. That works once you have customer data. It does not work when you have zero customers and need to price the first ten. This is the framework I used for StackScan — and why I landed on per-decision pricing instead of flat $99 or a 3-tier subscription ladder.

The problem with picking your first SaaS price

Every standard pricing framework assumes you have data. Value-based pricing assumes you know what your customers value (you do not — you have not had any yet). Competitive pricing assumes you have a competitor selling the exact thing you sell (you do not — if you did, you would not be building it). The 3-tier ladder assumes you have three buyer personas with three willingness-to-pay levels (you do not — you have a hypothesis). Most SaaS pricing advice is written for companies past product-market fit and quietly fails for companies at the beginning.

What you actually need at pre-PMF is a pricing structure that self-corrects — one where a small customer pays a small amount and a big customer pays a bigger amount without you needing to know in advance who is which. Subscription tiers do not self-correct (a 5-decision customer and a 50-decision customer both pay the same Tier 2 price). Flat pricing does not self-correct (same issue, more extreme). Per-decision pricing self-corrects by design: the price scales with the work, capped at a number you already decided was the maximum you would charge anyone.

What per-decision pricing is

Per-decision pricing is a hybrid of usage-based and flat pricing. You charge a unit price (per decision, per report, per recommendation) but you bound it at both ends with a floor and a cap. The customer scopes their work, sees the math, and pays once. There is no monthly invoice, no overage bill, no usage anxiety — and the price the customer sees at checkout is the price they pay.

It works when three conditions hold:

  • Discrete unit of value. The customer can point at one output and say "I bought one of those." A recommendation, a brief, a swap suggestion, a contract review. Not "access to the platform."
  • Irregular repeat usage. The customer might buy once and never come back, or buy three more times in six months. If they buy every week, you have a subscription product wearing the wrong pricing.
  • Variable scope per transaction. One customer's 3-decision audit and another customer's 30-decision audit are different amounts of value delivered. Flat pricing across that range overcharges the small one and undercharges the big one.

The 5-step framework for setting per-decision pricing

Step 1 — Identify the discrete unit of value

Per-decision pricing only works when there is one. Look for the smallest output your product produces that a customer would describe as "I got something useful." For an audit tool, that is one recommendation. For a research tool, one report. For a deliverable tool, one document. If you cannot finish the sentence "the customer paid us and we gave them [one thing]," you do not have a discrete unit yet — you have a service or a subscription. Stop and re-scope before pricing.

Operator tip: A discrete unit is not a feature. It is an output the customer can point at and say "that one." If you cannot count it, you cannot price-per-it.

Step 2 — Anchor against perceived ROI per decision

For each unit, estimate the dollar value the customer captures. For a SaaS audit recommending a tool to cut, the ROI is the annual cost of that tool — typically $5K to $50K. For a one-shot research brief, it is the analyst day rate it replaces — $1K to $5K. Set your per-decision price at 0.5%-5% of the captured value. Below 0.5% feels free and undercaptures. Above 5% triggers a "this should cost more, what is wrong with it" reaction. The sweet spot for self-serve, single-decision SaaS is 1-3% of unit ROI.

Operator tip: The per-decision price is not a list price — it is a unit price. Customers do not compare $25 against your competitor's $99/month subscription. They compare $25 against the $5,000 you are about to save them. Frame the math that way on the pricing page itself.

Step 3 — Set your floor (the 1-action minimum)

Per-decision pricing collapses when the customer can pay $0.10 and walk away with the answer. Set a minimum — typically 1x the unit price as a floor. This protects two things: (1) revenue per transaction, which keeps payment processor fees from eating margin, and (2) the customer's perceived seriousness — a free or near-free price signals "this is a toy," not "this is a tool." When StackScan was a paid product, its floor was $25 (1 decision minimum) — below that, a single-action audit would not have paid for its own Stripe processing fee plus the LLM cost.

Operator tip: The floor is also your psychological anchor for the cheapest possible customer. Make it high enough that you are not unhappy to deliver at that price. If the floor feels punishing to serve, raise it.

Step 4 — Set your cap (avoid sticker shock at the high end)

Pure per-unit pricing breaks at the high end. A customer with 100 decisions worth of work does not want to see "$25 × 100 = $2,500" — they want to see "the most you will ever pay is $249." Caps create comfort at the high end and remove the math anxiety that kills checkout. Set your cap at 8-12x your floor. Below 8x and you are leaving high-volume revenue on the table. Above 12x and the cap stops feeling like a cap. StackScan's ladder ran $25 floor → $249 cap — 10x. Most customers landed between 4 and 10 decisions, which kept the per-unit math visible and fair.

Operator tip: The cap is also a positioning tool. "Capped at $249" reads as "we will not let this run away from you" — which builds trust at exactly the moment the customer is deciding whether to click pay. Put the cap on the pricing page, not in the FAQ.

Step 5 — Communicate the math on the pricing page itself

Per-decision pricing only works if the customer can see the math at checkout. Show the unit price, the count, the running total, and the cap — live, on the same page. Hide any of those and the customer assumes you are hiding the bill. Two specific patterns that work: (a) show "$25 × N decisions = $X" as the customer scopes the work, before checkout, and (b) show "capped at $249, no surprises" in the same visual block. Do not bury the math in a tooltip or a separate pricing FAQ.

Operator tip: If the customer cannot see the math before they pay, they will assume you will charge the maximum. Surfacing the math is a conversion lever, not a transparency tax. Run a before-after test if you doubt it — the version that shows the math wins almost every time.

The three options I considered (and why per-decision won)

Before landing on $25 × decisions, capped at $249, I built and discarded two other pricing structures for StackScan. Both are defensible. Both are wrong for a pre-PMF audit tool. Here is what I considered and what each one optimized for:

OptionStructurePro caseWhy it loses at pre-PMF
Per-decision pricing
Chose this
$25 × decisions, $25 floor (1-action minimum), $249 capAligns price with actual value delivered. Tiny customers pay tiny amounts; high-value customers pay materially more — but never enough to shock. Self-discounting structure that does not require negotiation.Requires live math on the pricing page. Requires a clear discrete unit. Does not work for ongoing services or dashboards.
Flat $99Single price, single SKU, every customer pays the sameSimplest possible pricing. No checkout math, no per-unit anxiety, easiest to communicate. Easiest to A/B test against other flat numbers.Leaves money on the table for high-value customers (a 50-decision audit at $99 is structurally underpriced) and feels expensive for low-value customers (a 1-decision audit at $99 is structurally overpriced). Flat pricing optimizes for the median customer, which means it is wrong for both ends.
3-tier subscription ladder$79 / $149 / $249 with feature gatesStandard B2B SaaS pattern. Familiar to buyers. Allows feature differentiation, anchoring, and decoy logic. Easy to scale into Enterprise with "Contact us" Tier 4.Premature. Subscription pricing assumes recurring usage. For a one-shot audit tool, recurring billing creates churn risk on customers who only need the product once. Also: at pre-PMF, the feature gating that justifies tier separation does not exist yet — you have one product, not three.

Why these specific numbers — $25, $249, 1-action floor

The math behind StackScan’s original paid ladder wasn’t arbitrary. Each number did a specific job:

  • $25 per decision. Each StackScan decision is a recommendation to swap, cancel, or consolidate a tool — typically worth $3,000-$15,000 per year in saved spend if the customer acts on it. $25 is roughly 0.5-1% of unit ROI, which sits in the "feels fair, not free" psychological zone. Below $25, the price reads as a sample. Above $50, the per-unit math starts dragging at the mid-volume customer (10 decisions × $50 = $500 is steep at self-serve).
  • $249 cap. 9.96x the floor. Picks up the high end (40+ decision audits) at a price an operator can swipe on a card without a procurement cycle, but high enough that the cap does not collapse on the typical mid-volume audit (10-15 decisions). A $99 cap would have collapsed the structure — every customer above 4 decisions would have paid the cap. A $499 cap would have made the high end feel uncapped.
  • 1-action minimum. Floor of $25. Protects two things: (a) Stripe processing + LLM inference cost on a 1-decision audit are non-trivial — below $25 the unit economics start inverting; and (b) the floor is also a signal — "this is a real tool, not a free toy." Tools with $0 entry points get treated like toys. Tools with $25 floors get treated like tools.

Postscript: why StackScan is free now

Everything above is how I priced StackScan when it was a paid one-shot audit — and I stand by the framework. But StackScan itself is no longer paid: it’s now free, email-gated, and sits at the top of the funnel as a lead magnet. That isn’t a contradiction of per-decision pricing — it’s a different job. Per-decision pricing is the right call when the product is the business and each transaction has to carry its own margin. A lead magnet has a different mandate: maximize qualified reach into a larger paid product, where the “price” is an email and the monetization happens downstream. Same audit, same engine, different strategic role. If you’re pricing a product that has to stand on its own revenue, the five steps above are how I’d still do it. If it’s the front door to something bigger, free can beat any price.

When NOT to use per-decision pricing

Per-decision pricing is the wrong choice for at least four common product shapes. If you are building any of these, do not force per-decision math onto a product it does not fit:

  • Dashboards or continuous monitoring tools. The customer is not buying a decision — they are buying ongoing visibility. Subscribe, do not transact.
  • Communication or collaboration platforms. Slack, Linear, CRMs. The value is in the persistent shared state. Per-seat or flat monthly is the right shape.
  • Infrastructure / API products. If the customer is consuming inputs (calls, GB, transactions), usage-based pricing aligns better. Per-decision implies a discrete output; infrastructure does not have one.
  • Products where customers buy weekly or more often. Per-decision pricing creates friction on every transaction (form, checkout, card). For high-frequency products that friction kills retention. Move to a subscription with a usage allowance.

Common mistakes when designing per-decision pricing

  • Picking the price before identifying the unit. If you cannot point at one thing the customer pays for, the per-decision math is fake. You will end up charging for "access" disguised as decisions — which is a subscription pretending to be a transaction. Identify the unit first, then price it.
  • Setting the floor on competitor prices instead of unit economics. Your floor is the price below which you lose money to deliver. It is not "what feels cheap." If your competitor charges $9 and your unit cost is $30, charging $9 is wrong. Either raise the price or fix the unit cost.
  • Hiding the cap. A cap that lives in the FAQ is a cap the customer does not trust. Surface the cap on the pricing page, in the same visual block as the per-unit math. "Capped at $249" should appear before checkout, not after.
  • Stacking per-decision pricing with a subscription gate. If the customer has to subscribe before they can run a decision, you have invented the worst of both worlds — friction at the top of the funnel and ambiguity at the price. Pick one. Per-decision is a self-serve transaction; subscriptions require commitment. Mixing them confuses everyone.
  • Confusing per-decision pricing with pay-what-you-want. Pay-what-you-want has no floor, no cap, and no math. Per-decision pricing has all three. They are not the same pattern. Pay-what-you-want is a marketing experiment; per-decision is a pricing structure.

Related operator reading

FAQ

When the customer's usage is irregular and each output has clear standalone value. A SaaS audit, a research brief, a one-shot evaluation, a single deliverable — these are per-decision products. A daily dashboard, an ongoing workflow tool, or a continuous data feed is not. The test is whether a customer would say "I bought one of these" or "I subscribe to this." If it is the first, per-decision can work. If it is the second, you need a subscription.

Anchor against the dollar value the customer captures per decision, then take 1-3% of that. If a recommendation saves the customer $5,000/year in tool spend, the recommendation is worth $50-150 of decision value. Charging $25 captures a healthy slice without triggering "this should cost more" reactions. Below 0.5% feels free; above 5% feels like the price is hiding something.

Yes, deliberately. A cap exchanges high-end revenue for high-end conversion. Without a cap, a customer with 50 decisions worth of work sees "$1,250 at checkout" and bounces — not because the price is wrong, but because the math triggers anxiety. With a cap, the same customer sees "$249, no surprises" and converts. The lost revenue at the very high end is a fair trade for the conversion lift in the middle. If your unit economics demand uncapped pricing, you are probably not selling decisions — you are selling consumption.

Lower prices stop being better below a psychological floor. At $5, customers assume the product is a toy. At $0.99, they assume it is a scam. The floor signals "this is a real tool" and protects you from negative-margin transactions after Stripe fees, infrastructure, and any LLM/API cost. StackScan's floor was $25 — the price below which a single-action audit would not have been profitable to deliver. Pick your floor on real unit economics, not vibes.

Usage-based prices the inputs (API calls, seats, GB stored). Per-decision prices the outputs (recommendations, reports, deliverables). The customer's mental model is different: with usage-based, they monitor their consumption and worry about bill shock; with per-decision, they scope the work upfront and know the cost before they pay. Per-decision is better for one-shot tools; usage-based is better for infrastructure and ongoing platforms.

When the same customer starts coming back monthly. At that point, you have a recurring-usage product wearing per-decision pricing clothes — and you are leaving subscription revenue on the table. The trigger is usually somewhere around 40% of paying customers buying a second time within 60 days. At that volume of repeat purchase, you should offer a monthly subscription as an upsell alongside the per-decision flow, not as a replacement for it. Many SaaS products end up with both: per-decision for first-time buyers, subscription for recurring users.

Yes, but the cap has to scale with it. A $249 cap works for self-serve audit; a $25,000 cap might work for an enterprise version that audits a 500-tool stack. The pattern is the same: per-decision price, floor, cap. Enterprise buyers actually prefer per-decision when the math is transparent — it converts a "ContactUs / Get a Quote" wall into a self-serve checkout with a known maximum. Most enterprise buyers will not initiate a procurement cycle for $249, but they will swipe a card.

It is one of four pricing models in the StackSwap Operator Playbook: per-seat, usage-based, flat, and hybrid (which is where per-decision lives). The full framework — 3-tier structure, anchor logic, decoy pricing, expansion levers, discount discipline, and negotiation playbook — is what you graduate into once you have repeat customers and feature gating that justifies tiers. Per-decision is a great starting point at pre-PMF; subscription is where you go once usage patterns stabilize.

Canonical URL: https://stackswap.ai/per-decision-pricing-saas