Module-Based Pricing: Why Should a Customer Pay for What They Don't Use?

Three tiers — starter, professional, enterprise — is the easiest model on the sales side: you build a comparison table and the customer picks the middle one. The invisible cost is this: most customers never open half the features in their tier, and they know it. A customer looking at the monthly invoice and thinking 'I don't use half of this' arrives at the idea of cancelling without any competing offer.

The second cost is in the product. Package logic encourages making features look valuable by placing them in a higher tier; before long product decisions follow the balance of the tiers rather than customer need. Artificially pushing a useful feature up a tier brings upgrades in the short term and leaves a user base that resents the product in the long term.

In module-based pricing the product splits in two: the core and the modules. The core ships with every installation and runs the basic flow; modules are switched on as needed and priced separately. A customer starts with three modules and opens a fourth as the business grows. Every line on the invoice has something behind it — and that is what weakens the cancellation conversation from the start.

This model runs in our own hospitality product: the core flow — menu, orders, tabs, roles — is included in every installation, while the remaining modules switch on per branch and are priced separately. A small café runs on three modules; a multi-branch chain grows on the same core. The same product produces two different prices for two different sizes of business — without a discount negotiation.

The strongest sentence this model gives sales is: you do not pay for what you do not use. That sentence works when it is a direct consequence of the pricing model rather than a marketing claim — when the customer opens the panel and sees the modules that are off, they verify the claim themselves.

The core is what makes the product useless in its absence. The practical test is imagining your smallest customer's first day: which screens are indispensable for that day to happen? Business software that cannot take an order, clinic software that cannot register a patient, does not exist. Those screens are not modules; nobody wants to pay separately for them, and rightly so.

Keeping the core broad means fewer modules in number but makes selling easier: in the first conversation the customer hears 'these are already included'. Keeping it narrow gives pricing flexibility but creates a feeling that everything is an add-on. The way to find the balance is to define the core by your own customer's first day rather than by anyone else's feature list.

There is also the matter of the boundary moving. Over time a module becomes so common that everyone enables it; at that point moving it into the core is the right decision. Conversely, a feature in the core that only concerns one type of customer can move out to a module. Making these adjustments does not break the pricing model; it keeps it alive.

If you want to sell by module, the product must switch on and off by module — and that is an architectural decision, not a marketing one. The gate decision must live in one place: whether a module is enabled should be answered by a single gate rather than by small checks scattered across screens. Otherwise a module believed to be off leaks somewhere and a customer uses something they did not pay for.

The second architectural requirement is how a disabled module appears. There are two options: hide it, or show it locked. Showing it locked lets the customer see what is possible and triggers upgrades; hiding gives a cleaner interface. We chose locked-by-default — a user clicking the lock can read what the module does.

The third is the level the gate operates at. Does a module switch on per organisation or per branch? For a multi-branch customer that distinction converts directly into revenue: a chain using a module in only two branches pays only for those two. Adding that flexibility later is hard; you need to know the level you will price at while designing the data model.

A module catalogue is a list of commitments as much as a price list. So every module in it must actually work; those not yet built should be marked plainly as 'soon' and must not be sellable. That is how we run our own catalogue: live modules can be enabled, forthcoming ones cannot.

This costs something in sales — the list looks shorter. What it buys is this: when a customer enables a module, they find what they expected. Selling an unbuilt module burns trust before the first invoice, and regaining that trust costs more than the revenue of the subscription you lost.

Alongside the module decision comes a second question: what makes a module's price vary? Three measures are common — number of users, number of locations or branches, and transaction volume. The right measure is the one that grows together with the value the customer draws from the product. In a booking product it is usually appointments, in a business product branches, in a team tool users.

The price of choosing the wrong axis is that customers try to use the product less. In a tool priced per user, a business shares one account instead of opening more; that breaks security and devalues the product. The measure should be a natural indicator of the customer's growth, not something they want to avoid.

The third point is predictability: per-transaction pricing is in theory the fairest model, but the invoice changes every month and that is a problem for an organisation with a budget. The practical balance is a base fee plus tiered increases above a quota — the customer roughly knows what they will pay, and you cover the cost of heavy usage.

The purpose of a trial is not to show the product but to let the customer finish one real job with their own data. Handing over an empty installation and saying 'go ahead and try it' is why most trials end before they begin. What works is completing one genuine task in the first session: importing the menu, opening the first record, producing the first report.

In a module-based product, trial design matters even more: which modules are open during the trial? Opening everything gets the customer used to things that will later close, and the end of the trial feels like a loss. Our preference is to enable the recommended set for their business type and show the rest locked — the customer sees what is possible without losing something they had grown used to.

Publishing prices filters out unsuitable customers early and protects the sales team's time; not publishing gives flexibility per customer but starts half your conversations with the price question. In a module-based model transparency is easier: you can publish the core price and the module prices, and the customer works out their own set.

The limit of transparency is enterprise sales. The price for a multi-branch customer wanting custom integration and training is not the list price; a quote is right there. The practical solution is doing both: publish the list price for small and mid-sized customers and offer a conversation for enterprise. The small customer decides for themselves, the large one reaches the right room.

The first limit of this model is complexity. A catalogue of fifty modules produces a customer who cannot decide; beyond a point, freedom of choice becomes a burden. The solution is grouping modules and offering ready sets by business type: 'recommended set for a café', 'recommended set for a multi-branch operation'. The customer picks individually if they want, or takes the ready set if they do not.

The second limit is predictability. Some organisations budget annually and an invoice that changes every month is a problem for them. Here it helps to keep the module structure while fixing the price annually: modules can be enabled during the year, and the invoice updates at year end. The model stays flexible and accounting stays comfortable.

The third limit is the administrative cost of very small prices. Making a module with a tiny monthly amount its own invoice line creates more work in collection and accounting than it is worth. Grouping such small capabilities, or folding them into the core, makes more sense than selling them one by one.

Moving existing customers onto a new pricing model is a more delicate job than designing the model. The basic rule is that nobody's invoice rises without warning. What works in practice is leaving existing customers on their old terms and starting the new model with new customers, then making the transition by incentive — offering an advantage to those who move is better than penalising those who do not.

The most useful tool during the transition is transparency: showing the customer a comparison of the two models based on their own usage. Most customers see they would pay less under the module model and the move happens by itself; those who would pay more are the heavy users, and they understand the reason. Hiding the numbers is the only thing that makes the transition hard.

Module-based pricing closes the distance between a customer's invoice and their usage, and that alone reduces cancellations. But for the model to work, the product must genuinely be modular, the gate decision must live in one place, the core must be defined honestly, and only what genuinely exists must be sellable in the catalogue.

A pricing model is not a shell you put on later; it is built together with the product's architecture. So asking 'how will we price this' while designing the first release is far cheaper than trying to change the model in year three.