Pricing Strategy 101

Before writing YAML files, take a step back. Good pricing starts with understanding what makes your product valuable — not what's easy to meter.

Start from Value, Not Models

The most common mistake is choosing a pricing model (subscription vs. usage-based) before understanding where your product creates value.

Ask yourself: What are the moments where users get concrete value?

For a developer tool, these might be:

• "I deployed without breaking production"
• "I saved 3 hours of debugging"
• "My CI caught a bug before it shipped"
• "I onboarded a new engineer in minutes"

These moments often translate into usage dimensions, not flat plans — which is why pure flat pricing tends to underperform for infrastructure and developer tools.

Identify What's Scarce

Your pricing should reflect what's actually constrained in your system. Common billable axes include:

You don't need to expose all of these to users — but you do need to decide internally which ones drive your costs.

Keep it simple: Meter 1–3 dimensions maximum.

The Winning Pattern: Base + Usage

For infrastructure and developer tools, the most robust structure is:

Base subscription + usage-based overages

This gives you:

• Predictable revenue from subscriptions
• Fair scaling from usage billing
• Easy upgrades as customers grow
• Low anxiety for users (included allowances)

Think "GitHub + AWS", not "AWS only."

Designing Your Tiers

Access Tiers (Subscriptions)

Subscriptions should unlock capabilities and trust, not raw usage:

Included Allowances

Each tier should include a monthly allowance. This is psychologically important — it prevents:

"I'm scared to run this, it might cost money."

Example: Pro includes 10,000 API calls, 100 build minutes, 5 team seats.

Overages

Once allowances are exceeded, charge per-unit:

• $X per 1,000 additional API calls
• $Y per compute hour
• $Z per GB stored

This is exactly what MoneyMQ's metering is designed for.

When to Use One-Time Pricing

One-time payments work well for:

• Credits / top-ups — prepaid usage bundles
• Enterprise procurement — annual commitments
• Events / hackathons — temporary high usage
• Lifetime deals — early adopter incentives

Avoid making one-time payments the primary UX — "pay $0.01 per request" creates friction and discourages experimentation.

Feature Gating Done Right

Developers hate artificial feature gates. Be thoughtful about what you restrict.

Good gates (access & trust):

• CI/CD integrations
• Team collaboration
• API rate limits
• SLAs and support tiers
• Audit logs and compliance

Bad gates (feels punitive):

• "Advanced" versions of core features
• Accuracy or performance tiers
• Features that should just work

Rule of thumb: Core functionality should feel free. Gate access, collaboration, and guarantees.

Validating Before You Ship

Before finalizing your pricing:

1. Interview 5 power users — Ask what they'd expect to pay, what would scare them, what feels fair to meter
2. Shadow price internally — Track real usage for 2–4 weeks, simulate invoices
3. Check your margins — Ensure your pricing covers costs at scale

You'll typically find that 80% of users fit comfortably in your mid-tier, while 20% are power users who benefit from usage billing.

Getting Started

Ready to implement? MoneyMQ's declarative catalog makes it easy to express any pricing strategy:

• Creating a Catalog — Define products and variants in YAML
• Using the Catalog — Query products via the SDK
• Deploying Updates — Ship pricing changes with GitOps