Why We Charge Per-Call, Not Per-Seat

Most developer tools charge per seat. Add an engineer, pay more. It’s simple to understand, simple to sell, and completely misaligned with how infrastructure actually works.

Solenoid charges per API call. Here’s why.

The Seat-Based Problem

Your team has 5 engineers. You’re paying $50/seat/month for a feature flag service. $250/month total.

You hire 5 more engineers. Your flag service bill doubles to $500/month. But your flag usage? Maybe it went up 10%. The new engineers are working on different parts of the codebase. Half of them never touch flag-controlled features.

Now you’re paying for capacity you’re not using. And you start having weird conversations about who “really needs” access to the flag dashboard.

Or consider the opposite: your team stays the same size, but your product grows 10x. Your flag evaluations increase proportionally. Your bill? Still $250/month. The vendor is subsidizing your growth with other customers’ payments.

Neither situation is right.

Usage Reflects Value

If you’re making more API calls, you’re getting more value. If you’re making fewer calls, you should pay less. This is how infrastructure should work.

Solenoid’s pricing:

• Free tier: 10,000 calls/month across all services
• Starter: $19.99/month — unlimited Gate, 100K others
• Pro: $49.99/month — unlimited Gate & Meter, 500K others
• Scale: $149.99/month — unlimited Gate, Meter & Witness, 2M Relay

As you grow, core services become unlimited. Overages on capped services are per-call at predictable rates. No “contact sales” black boxes.

Predictable Scaling

With usage-based pricing, you can calculate costs as you grow:

Starting out:     Free tier ($0)
Going to prod:    Starter ($19.99) — Gate becomes unlimited
Scaling up:       Pro ($49.99) — Meter becomes unlimited too
High volume:      Scale ($149.99) — Witness unlimited, 2M Relay

Core services become unlimited as you grow. No cliff where you suddenly need “enterprise” pricing because you added a 51st engineer.

Team Size Doesn’t Matter

A solo founder and a 500-person company pay the same rate per call. The solo founder probably pays less total because they’re making fewer calls. The enterprise pays more because they’re using more.

This means:

• Small teams aren’t priced out of good infrastructure
• Growing teams aren’t penalized for hiring
• Large teams pay proportionally to their actual usage

No “startup discount” that disappears when you raise a Series A. No awkward conversation about seat counts during budget reviews.

The Incentive Alignment

Per-seat pricing creates perverse incentives:

• Vendors want you to add seats (more revenue)
• You want to minimize seats (less cost)
• Some engineers get “shared” logins (bad security)
• Infrastructure decisions get mixed with headcount planning

Per-call pricing aligns us:

• We want you to use the product more (more revenue)
• You want to use the product more (more value)
• Everyone gets their own credentials (good security)
• Infrastructure decisions are about infrastructure

When our incentives align with yours, we build better products. We’re motivated to make the API fast and reliable so you’ll use it more, not to add dashboard features that justify seat expansion.

Why Others Don’t Do This

Per-call pricing is operationally harder. You need:

• Accurate metering at scale
• Real-time usage dashboards
• Billing systems that handle variable amounts
• Overage calculations that don’t surprise customers

Per-seat is easier: count users, multiply by price, invoice monthly.

We built Meter (our metering product) before we built our billing system. We track every API call in real-time. We can do per-call pricing because we built the infrastructure to support it.

When Per-Seat Makes Sense

Per-seat isn’t always wrong. It makes sense when:

• The product is collaborative (Figma, Notion)
• Value scales with active users, not API calls
• Users spend significant time in the product
• The marginal cost of a user is meaningful

Feature flags, metering, and webhooks aren’t collaborative tools. They’re infrastructure primitives. Your engineers don’t “use” them in a dashboard all day. They call an API and move on.

Different products need different pricing models. Infrastructure should be usage-based.

Transparency as Policy

Our pricing page shows exact per-call rates for overages. Our dashboard shows real-time usage. You can calculate your bill before you get it.

No “contact sales” for pricing. No negotiated enterprise deals with secret discounts. The price is the price.

If our pricing doesn’t work for your use case, we’d rather you know upfront than discover it after integration. We’re not trying to maximize revenue per customer. We’re trying to build a sustainable business on fair terms.

Try the Math

Sign up for free. Make some API calls. Check the usage dashboard. Calculate what you’d pay at scale.

If the economics work, we’ll be here. If they don’t, no hard feelings. At least you know exactly what you’re getting.