Set and test a first price for a small software product

Price the outcome and the operating model

Price is a product decision: it affects who can buy, what they expect, how often they use the product, and whether the business can support it. Start by naming the customer, the problem solved, and the outcome they receive. Then estimate your delivery and support costs. Costs establish a sustainability floor; they do not reveal what the customer values or what the offer is worth.

Talk to people in the intended segment about their current alternative, the time or money it consumes, who approves spending, how they buy similar products, and what happens if they do nothing. Ask about real past purchases and budgets before asking what they would pay for your concept. Treat stated willingness to pay as evidence to compare with behavior, not a purchase commitment.

Pick a value metric customers can predict

The value metric is what the bill scales with: seats, projects, transactions, locations, or usage. A useful metric should grow when customers get more value, be easy to understand before purchase, remain reasonably predictable, and avoid punishing healthy use. A per-seat price may fit team collaboration; it can frustrate a tool whose value comes from a shared workflow. A usage meter may align with infrastructure cost but create an unpredictable bill.

Choose the simplest model that matches the way a customer buys and the cost you incur. One-time purchase can fit a durable tool with low ongoing service costs. Subscription can fit continuing access, updates, or recurring outcomes. Usage pricing can fit a measurable unit of value and cost, provided customers can anticipate the bill. A free tier is useful only if it has a clear acquisition or product-learning purpose and its costs are bounded.

Stripe’s pricing material describes several SaaS structures and comes from a company that sells billing services; use it as a vocabulary for models, not an independent benchmark or a claim that any model is universally best. Compare models with actual customer interviews and your own cost structure.

Build a first offer people can compare

For the first version, publish a small number of options, ideally one primary paid plan plus a clearly bounded trial or free path if justified. For each option, specify who it is for, the outcome, included limits, overage behavior, billing period, cancellation terms, and whether taxes are included or added. If a customer needs a custom quote, explain what drives it and when they will receive a response.

Estimate gross margin at plausible low, expected, and high usage. Include payment fees, infrastructure, support time, refunds, and any human service bundled into the plan. For usage-based services, test a realistic customer scenario against current provider costs and set alerts or hard limits to avoid an unexpected bill. Prices and payment-provider fees change; verify official terms immediately before making calculations public.

Learn with honest tests

Use a sequence that matches your stage:

1. Problem interviews: learn what customers spend today and what alternatives cost them.
2. Offer conversations: show a specific package and price, then ask what does not fit and why.
3. Pilot or preorder: ask for a real commitment only when delivery scope, timing, cancellation, and refund terms are clear.
4. Live pricing: monitor qualified purchase starts, completed purchases, refunds, support burden, expansion, and cancellation reasons by customer segment.

For a test brief, low-traffic methods, outcome metrics, and decision log, use the early-stage pricing experiment workflow.

Change one part at a time when you can: price, included usage, package boundary, or billing cadence. Record who saw each offer and what they did. Small samples can guide qualitative learning but rarely support precise conversion claims. Keep existing customers’ promises explicit before changing a live offer.

Never invent a crossed-out price, fake a deadline, hide a recurring charge, or make cancellation deliberately difficult. The FTC’s dark-patterns report discusses such practices in a U.S. consumer-protection context; requirements elsewhere differ, and this page is not jurisdiction-specific legal advice. See add payments safely and design a clear offer before implementing checkout.

When you need purchase evidence before full automation, a paid pilot can test a specific outcome and expose the real delivery work.

Check whether the offer can support its delivery costs with the contribution-margin worksheet.