How to Price Software: The Architecture Behind the Price

TL;DR: How to price software well is not a matter of picking a model or landing on a number. It is an architecture of three decisions: the licensing model that selects your value metric, the packaging model that groups capabilities into editions, and the pricing model that sets prices and governs discounting. Most pricing that “feels broken” is one of those three decisions failing, and the first job is telling which one.

What pricing architecture is: The three structural decisions that determine how a software company captures value. The licensing model defines the value metric a price attaches to, the packaging model groups capabilities into editions and add-ons, and the pricing model computes list and net prices across every deal. Made together, they compose. Made separately, they leak.

Pricing software is not a number, it is an architecture

Ask most teams how to price their software and the conversation jumps straight to a menu: per user or per usage, flat rate or volume-tiered, penetration or skimming, cost-plus or value-based. Pick one, set a price, move on. That framing is where the trouble starts. Naming a model is not the same as making a decision, and the menu hides the choices that actually determine whether you get paid for the value you create.

Here is the tell. Two companies can sell nearly identical products on the “same” per-user model and run completely different economics, because one attaches its price to a unit that grows with customer value and the other does not. The model label they share tells you almost nothing. What separates them is the architecture underneath the label.

So the useful question is not “which pricing model should I choose.” It is “which of three decisions have I gotten wrong.”

Software pricing is the composition of a licensing model, a packaging model, and a pricing model. When those three are designed together, the customer understands what they are licensed to use and sees a package that fits their use case. The price attaches to a metric that reflects the value they receive. When any one is missing or out of alignment, the gaps surface at the deal desk as discounting no one can explain.

The three decisions behind every software price

The architecture has a fixed order, because each decision constrains the next. Licensing comes first, packaging second, pricing last. You cannot package rights you have not defined, and you cannot price a bundle you have not packaged. We weight the three decisions roughly three to two to one: the licensing model carries the most weight, packaging the next, the price points themselves the least. That weighting surprises teams who spend the bulk of their pricing energy arguing about the number, which turns out to be the decision with the least weight of the three.

The full catalog of named models, and how each maps onto these decisions, is its own subject. Our guide to SaaS pricing models walks the catalog and shows why the model is rarely the decision, and for the complete monetization picture across revenue models, our software monetization guide is the deeper reference. Here, the goal is orientation: what each decision does, and how to tell which one is failing.

The licensing model selects your value metric

The licensing model defines what the customer is allowed to do with your software and, inside that, which unit your price attaches to. That unit is the value metric, and it is the single most consequential choice in the whole architecture. Per seat, per active user, per transaction, per outcome resolved: each is a different answer to “what do we count.” The metric decides whether revenue grows as the customer succeeds, or stays pinned to a variable that has stopped tracking value.

This sits upstream of everything else, which is why we treat “should we go usage-based or stay on subscription” as a confused question. Subscription describes how often you bill. Usage describes what you meter. They live on different axes.

The decision that matters is the metric itself, and the difference between a pricing model and a value metric is where most of the industry’s pricing confusion lives. For the deeper work of choosing a metric, and the properties that separate a good one from a bad one, the value metric decision is the reference.

The packaging model groups capabilities into editions

The packaging model decides how your capabilities, the software features plus the services and insights around them, group into editions, add-ons, and modules. Done well, packaging lets a buyer see at a glance which edition is theirs, so the deal moves faster. Done poorly, every deal becomes a custom configuration and the sales team papers over the mismatch with one-off bundles and exceptions.

The move most teams reach for here is segmentation, and it is where a common piece of advice gets the sequence backwards. Segmentation applied to a fixed model, as a way to make it “adaptive,” treats grouping as a bolt-on. In our framing, grouping is a packaging input that sits downstream of the metric, and it works on Customer Groups. Customer Groups cluster buyers by how they actually derive value from the product, not by company size or vertical, which rarely predict usage.

Peer-reviewed economic work on versioning information goods supports the underlying mechanic. Quality-differentiated editions let buyers self-select into the edition that fits the value they get, but only when the groups genuinely differ in what they will pay. If they do not, more editions add confusion rather than capture. Our packaging decision framework is where that design work lives.

The pricing model sets the numbers and governs discounting

The pricing model is the rulebook that turns a list price into a net price on every invoice: the price points, the approved discount tiers, volume breaks, renewal mechanics, and the floors that constrain them. It is the terminal decision, and the one that gets iterated most, but it is also the one most often blamed for problems that originate upstream.

When deals keep landing at irrational net prices, the visible cause is a discount rule, and the real cause is frequently a mis-chosen metric or over-complex packaging that made the rulebook impossible to calibrate. The discipline of discounting on purpose rather than by reflex is its own craft; margin-calibrated discounting covers how a discount surface should actually be engineered.

Why the value metric sits upstream of everything

If you take one idea from this, take this one: the metric does the work. In our work with software companies, we have watched the same product, with no change to its features, produce a very large revenue swing from a change in the value metric alone. A single renewal moving from a few thousand dollars to several hundred thousand, not because the software changed, but because the unit the price attached to finally tracked the value the customer received. That is a swing the price number can never match.

This is also why cost-plus pricing fails, and here the broader market is right. Cost-plus is disconnected from value; it charges everyone the same average, wrong price, too high for the small customer and too cheap for the large one.

Where the common advice goes soft is the fix. “Switch to value-based pricing” is not a model you select off a shelf. Value-based pricing is what emerges when you choose a metric that scales with the value the buyer receives, then keep refining it against what actually happens in deals. Value-based pricing as a strategy explains why it is a discipline rather than a menu item.

The metric also decides whether an account can grow or quietly stalls. Set the meter on an action the customer controls and you invite metered-action suppression. The customer throttles the billed action to manage the invoice, and the reduced usage reads as satisfied demand when it is really demand your meter design suppressed. The account settles into a shallow deployment, lodged in one narrow slice of the workflow because the pricing blocks it from spreading.

None of that is a discount problem. It is a metric problem surfacing as a discount problem.

Peer-reviewed research on industrial-market selling finds that a seller’s ability to quantify value for the buyer predicts pricing success more reliably than product quality does. That quantification becomes difficult when the unit you meter corresponds to nothing the buyer values. The shift off seats specifically, and how to pick the unit that replaces them, is covered in the per-seat to usage transition.

How to tell which decision is your problem

Most teams know something is wrong before they can name it. The symptom is loud and the cause is quiet. What the architecture buys you is a way to turn a vague “our pricing is broken” into a decision about which of the three to examine first. A few recurring patterns, and where they usually point:

• Discounting is everywhere and no one can explain it. When every deal needs an exception, the discounting is usually compensating for an upstream gap. Look at packaging first, since forced custom configurations mean the editions fit no one, then at the metric. The pricing model is rarely the root cause even though it is where the pain shows.
• Deals stall on “I can’t predict my bill.” That is a metric problem. A unit the buyer cannot forecast before signing transfers risk onto them, and buyers price that risk back to you or walk.
• Every deal is a custom configuration. That is a packaging problem, and usually a Customer Groups problem underneath it: your editions map to how the product team organized features, not to how buyers actually decide.
• A usage line posts a record quarter, then flattens. That is the signature of metered-action suppression. The first cycle prices in the spike before customers reorganize their behavior around the new bill.

Read these as a place to start looking, not as a scorecard that hands you the answer. The catch is that the real diagnosis, and the redesign that follows it, needs evidence a public frame cannot supply. That evidence is your own win and loss records, the configurations buyers rejected, the discounts your deal desk actually approved, and how value is perceived across your customer base. A recipe applied without that evidence is a guess presented as an answer.

The frame tells you which decision to interrogate; the interrogation runs on your data, and it is the kind of read a pricing specialist can do with you.

What changed, and why pricing keeps drifting out of date

Pricing that was right three years ago drifts, because the ground moved under it. Buyers are further into the decision before they ever talk to a salesperson, and they arrive having already modeled the value and the risk themselves. The market shifted from growth at any cost to profitable growth, so every point of leaked value now draws scrutiny. And AI changed the cost and value picture underneath products faster than most pricing architectures were built to absorb.

AI is the sharpest case. Teams undervalue AI features early and anchor low, or overvalue them before the value is proven, or split them into disconnected add-ons that create quoting headaches. Worse, when a customer uses AI to automate a workflow inside your product, the headcount your seat-based metric counts can fall even as the value climbs, which turns your own metric against you. Pricing AI well is its own architecture problem; AI software pricing works through the variable-cost and metric questions specific to it.

Pricing is a discipline, not a one-time project

The deepest reason software pricing goes wrong is that most companies treat it as a project done once, too early, and rarely revisited. It behaves more like product development: a set of hypotheses tested against real transactions and refined. Peer-reviewed work that frames pricing as an organizational capability finds that a structured pricing process is itself a source of competitive advantage, not merely a finance function. Companies that build that capability stop re-pricing in a panic every couple of years.

Treating pricing as a discipline means giving it an owner, a shared language across product, sales, and finance, and the instrumentation to see how a change plays out before it is permanent. That choice separates rewriting your whole architecture in one high-stakes event from revising one decision at a time on the cadence your product already ships on.

That ongoing practice is continuous monetization, and it is where enterprise pricing in particular earns its durability, since enterprise SaaS pricing has to hold up under deal pressure that exposes every architectural gap. LevelSetter is the instrumentation we use to make that cadence sustainable, but the decisions stay with the people accountable for the customer base they land on. The tooling senses; the practitioners decide.

Where to start

If your pricing feels off, resist the reflex to reach for a new number. Put the frame to work in order:

1. Name which of the three decisions is most likely failing, using the symptoms above as a pointer rather than a verdict.
2. Pull your own evidence: the deals you won and lost, the configurations buyers rejected, the discounts your desk actually approved.
3. Interrogate that one decision against the evidence before you touch the others.
4. Revise one decision at a time, on the cadence your product already ships.

This is diagnosis, not a formula, and the real answer lives in your own data. If you would rather work through the diagnosis with someone who has done it across many software companies, talk to a pricing expert and describe what you are seeing. A specialist will read the symptom back to you and tell you which decision to open first.

FAQs