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:

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." For the StackScan audit, the floor is $25 (1 decision minimum). Below that, the audit would not pay 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. The StackScan ladder runs $25 floor → $249 cap, which is 10x. Most customers land between 4 and 10 decisions, which keeps 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 the StackScan ladder is not arbitrary. Each number does a specific job:

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:

Common mistakes when designing per-decision pricing

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. The StackScan floor is $25 because that is the price below which a single-action audit would not be 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