Per user, per project or per use: compare software pricing properly

The cheapest advertised software price may not be the cheapest way to run your actual work. A plan can charge for people, active projects, processed items or a combination. The useful comparison starts with a workload and a feature requirement, then applies each provider's exact billing rules.

Stripe's documentation describes common mechanisms such as per-seat, tiered and usage-based billing. Every price below is fictional and expressed in EUR, excluding VAT. Stripe: pricing models.

Start with equivalent requirements

List the capabilities that are genuinely required: editing, guest access, storage, exports, support and any essential security controls. Comparing a limited viewer plan with a full editing plan can produce an attractive but unusable answer.

Then estimate named users, active projects and billable activity for an ordinary month, a quiet month and a busy month. Include occasional reviewers where the contract counts them as paid users. Do not reduce the estimate by assuming people will share credentials.

Three fictional plans

For this exercise, assume equivalent required functionality and no minimum charges beyond those stated:

• Plan A: EUR 18 per named user per month.
• Plan B: EUR 75 per active project per month, with unlimited named users under this fictional offer.
• Plan C: EUR 60 per month plus EUR 0.40 per processed item.

For four users, two active projects and 200 items, monthly costs are EUR 72, EUR 150 and EUR 140, respectively.

For twelve users, three projects and 500 items, they are EUR 216, EUR 225 and EUR 260.

For thirty users, two projects and 2,500 items, they become EUR 540, EUR 150 and EUR 1,060.

Plan A is least expensive in the first two scenarios; Plan B is least expensive in the third. This does not establish a universally best pricing model. It shows how the shape of the team's work changes the result.

Find the point where the ranking changes

With three active projects, Plan B costs EUR 225. Plan A reaches the same mathematical price at 225 / 18 = 12.5 users. Since user counts are whole numbers, A is cheaper at twelve users and more expensive at thirteen, under the stated assumptions.

That comparison would change if project archiving stops billing, viewers are free, a minimum seat count applies or a feature forces an upgrade. Write these conditions beside the calculation. A spreadsheet should not conceal the contract behind a single unit price.

“Tiered” can mean two different calculations

In volume pricing, the reached tier's rate can apply to the entire quantity. In graduated pricing, each portion is charged at its own tier. Stripe documents both mechanisms. Stripe: tiered pricing.

For a separate fictional example, let the first 100 units have a rate of EUR 1 and the next tier EUR 0.80. At 150 units, volume pricing applying EUR 0.80 to all units gives EUR 120. Graduated pricing gives 100 × EUR 1 + 50 × EUR 0.80 = EUR 140. The same displayed tier rates can therefore produce different bills.

Check whether fixed tier fees, included quantities or minimum commitments also apply before using either formula.

Define the billable event

For usage pricing, ask whether an item means an attempted operation, successful result, page, file or unit of compute. Do retries count? Are test environments billed? Is storage charged separately? Can an administrator set alerts or a hard limit, and what stops working if it is reached?

For project pricing, clarify what “active” means and whether archived projects remain readable without charge. For user pricing, clarify invited, activated, suspended and external users. Ask how additions and removals are prorated and when they affect the bill.

Compare the commitment as well as the month

An annual discount can reduce the effective monthly rate while requiring an upfront cash commitment. Include implementation, training, integration maintenance and the work needed to retrieve your data if you leave. Avoid assigning fictional precision to those costs; use stated estimates and show the assumptions.

Use a small pilot to measure real activity before committing to a large usage allowance. Recalculate with observed quantities and check a sample invoice against the rules. Keep the pricing date and plan version in the decision record, since commercial terms can change.

The final choice should state the expected workload, required capabilities, total cost range and conditions that would trigger a review. That is more durable than choosing whichever homepage displays the smallest number.