Skip to main content

Pricing strategy and tradeoffs

This guide explains the current pricing strategy in Vluna and why we recommend it for most integrations.

It is about strategy and system behavior, not endpoint syntax.

Current capability boundary:

  • Vluna currently does not provide first-class per-plan meter unit-price override support.
  • Option A below is a conceptual alternative for tradeoff analysis, not a currently supported default capability.

Use this baseline:

  • keep meter_code pricing stable as the canonical unit price layer
  • use billing plan for packaging:
    • entitlements (what can be used)
    • limits/policies (how much/how fast)
    • funding design (included credits, grants, purchases)
  • use contract terms only for explicit negotiated exceptions

In short:

  • price baseline on meters
  • commercial differentiation on plans and funding

Why this is the current default​

1) Better explainability and support​

With stable meter prices, a disputed amount is easier to explain:

  • which meter was charged
  • what quantity was used
  • what effective price snapshot was applied
  • what funding source covered it

2) Lower operational complexity​

Without per-plan unit price overrides:

  • pricing behavior is simpler to reason about
  • rollout risk is lower
  • audit and reconciliation are more predictable

3) Cleaner object responsibilities​

  • meter prices define unit pricing
  • plans define packaging and customer experience
  • funding objects define how value is granted/consumed

This avoids mixing pricing, entitlement, and enforcement semantics.

Strategy options and tradeoffs​

Option A (conceptual, not currently supported): per-plan direct unit price overrides​

What it means:

  • same meter_code may have different unit price by plan

Pros:

  • straightforward sales story ("plan X has lower unit price")
  • direct expression of price-tier contracts

Cons:

  • configuration surface grows quickly (plan x meter combinations)
  • harder incident forensics and historical explainability
  • more rollout and migration complexity

Option B: stable meter price + plan/funding differentiation (current default)​

What it means:

  • meter unit prices remain stable
  • plans differentiate via access, limits, and included value (credits/grants)

Pros:

  • stable pricing core, lower drift risk
  • clearer accounting and support workflows
  • easier to operate at scale

Cons:

  • "effective discount" may be less visually direct than unit-price discount
  • product/finance communication must explain included-value mechanics

Option C: commitment/contract discounts (terms-led)​

What it means:

  • commercial discount is expressed through contract commitments and terms
  • runtime pricing references those terms where applicable

Pros:

  • good fit for negotiated enterprise contracts
  • separates baseline pricing from contract exceptions

Cons:

  • requires strict contract lifecycle governance
  • adds policy and audit complexity

Market patterns (why this is not unusual)​

In practice, markets use mixed models:

  • direct tiered/volume pricing exists
  • commitment discount models exist
  • included-usage/credit models exist

So per-plan direct unit price is one option, not a mandatory end-state.

Decision rule for integrators​

Start with Option B. Option A is not currently supported as a first-class default capability.

Use Option A only when all of the following are true:

  • sales and finance repeatedly need persistent per-plan unit-price differences
  • included credits/grants cannot express required commercial behavior clearly
  • support and reconciliation workflows are ready for added complexity

Practical recommendations​

  1. Treat meter_code pricing as a stable canonical layer.
  2. Express plan differentiation through:
    • entitlements
    • limits/policies
    • included credits/grants
  3. Keep exceptions explicit and auditable (contract terms, not hidden logic).
  4. Require support-grade traceability for any pricing decision.