Dev tool pricing examples

How to communicate the flexible part of your plan?

Many dev tools have 3 plans:

• Free
• Team
• Enterprise

Especially the ones doing some flavor of product-led-sales or open-source go-to-market.

Now, the Team plan is often a self-served version.

And for many dev tools, this part is partially or entirely usage-based.

So how do you present it?

You can just have "+ what you use" and explain it in the big table below.

But if you have just one usage dimension then why not do it here?

Resend does it beautifully communicating right away that it starts at 20$ / month and grows with the amount of emails you send.

Very clear. Very nice.

Pricing in your docs? That is how @Fly.io does it.

You click a pricing page link on their homepage and you go to the docs!

No 3 boxes with the "most popular" being the middle paid plan ;)

They just give it to you how it is. Exactly what you'd expect from the docs.

There are tables, explanations, and links to other docs pages.

Very bold decision imho. It definitely makes them feel super developer focused.

Plus if you do want a more standard, enterprise stuff you see:

"If you need more support or compliance options, you can choose one of our paid plans. These come with usage included and additional support options."

And that page looks like a classic pricing page.

But they focus on the developer buying experience here. Super interesting.

Why not highlight your free plan?

Most companies highlight their middle paid plan saying it is "most popular".

First thing, yeah, sure it is your most popular plan.

But more importantly, most visitors will not convert to your paid plans right away.

So why not try and capture as many devs as possible on the free plan?

If they like your dev tool there are many things you can do to convert some of them to paid plans.

But if they leave that pricing page and go with some other free tool, you are not converting anyone.

@CircleCI highlights free and they are in the mature, competitive market of CI CD tools.

Idk, it really does make a lot of sense to me.

If people need more advanced features they will choose higher plans anyway.

But if they want to get things started with the basic plans they will choose free or go elsewhere.

I'd rather have them choose free than none.  

Most dev tools have two deployment options:

• SaaS
• On-prem / private cloud

And then companies present it on their pricing page with some flavor of two tabs.

And you need to name them somehow. 

And how you describe those things sometimes adds confusion for your buyers:

• You put “your server” > then does it scale to a more robust infra?
• You put “on-prem" > then can I deploy on private AWS cloud?

I like how nice and simple solution Retool used on their pricing page:

• "Cloud (we host)"
• "Self-hosted (you host)"

Explicit, obvious and to the point.

Love it.

Sometimes your product just wins on price.

I like how New Relic owns it on this page:

• They show you price comparison graphs
• The CTAs are focused on helping you compare the prices
• They use jargon specific to the category to drive the price argument: "peak usage", "overages and penalties", "SKUs"

After reading this I'd trust them to give me a solid price estimate and that it will likely be cheaper than Datadog.

Obviously price is not the only reason why we choose tools, but if that was a problem I had with Datadog, they have my attention.

When selling dev tools you typically have 3 "buyer" levels:

Individual dev:

• wants to experience your value prop
• ideally wants to play/test/use the free tool
• doesn't buy tools but strongly influences buying decisions
• wants to use it right now, not talk to his boss to get a credit card, not talk to sales

Team lead:

• wants to improve teams productivity
• collaboration, developer experience, and happiness are important
• buys tools at a team-level budget
• doesn't want to go through a lengthy sales process but  swipes the card and gets the team on this week

Org lead:

• wants to improve the security and compliance of the entire eng org
• security, control, governance
• buys tools for the entire organization/enterprise
• expects a longer sales process with a lot of moving parts and needs to discuss and negotiate

How does Postman solve it?:

• packages their plans in a way that aligns with those buyers
• different plans have features needed for Dev/Team lead/Org lead
• CTAs are exactly what each buyer wants: Use > Buy > Talk

They even go the extra mile. Something I didn't see too often.

They understand their customer's reality and identified one more level between Org and Team.

Basically a department-level unit that probably has multiple teams but is not at the organization/enterprise level.

I really like what they did hear. Solid.

Usage-based pricing is loved by devs. But has its own problems.

Ok, so first what are those problems?

Value metric:

• users don't understand your value metric
• even when they do, they cannot map it to their usage patterns.

Predictability and procurement:

• it is easier to predict the headcount than the usage
• per user pricing is obvious, everyone across the org understands it

But devs love usage-based pricing:

• it is "fair", you pay for what you use
• you can scale up/down as you need

It is great for a dev tool company:

• you align user adoption, the value created, and monetization
• as org-wide usage so does the invoice

But pulling it off is not as easy as you may think.

Choosing that value metric, packaging it, and presenting it is a struggle.

@Appsmith solved it in the following way:

• give people an option to go with a usage-based pricing
• but cap a per-user cost at $X a month
• it guarantees a better deal than a flat per-user pricing
• but gives you the predictability of a per-user pricing

Very interesting approach.

Sometimes your pricing is just complex. But you can still make it work.

If you want devs to convert, make it possible for them to estimate the cost.

@Mux does it nicely with a calculator:

• They give sliders for dimensions that are obvious to the dev
• They give (pre) select boxes for things that are a bit less obvious
• They show additional costs
• They give you a clear final price estimate

What is crucial is that the calculator dimensions need to be understandable and familiar to the reader.:

• If you use expected industry concepts (view count, upload, users) you should be fine.
• If you use weird obscure concepts the best calculator will not help.

The goal of this is to make it possible for a person to get an estimate right here right now.

Not have to setup a meeting with half the team to figure your pricing out.

How do you make your dev tool pricing simple?

I really like this one.

Saw someone share a pricing page from Userfront some time ago and really liked it. They changed it now but I really like the thinking behind the older version.

It is just remarkably simple while hitting all the boxes:

• You have tiers aligned with buyer persona: Free, Self-served (team), Custom (enterprise)
• Your usage metric is obvious (Monthly Active User)
• For Enterprise you just go with "Contact us" CTA (which is what enterprise buyers expect anyway)

Just a very good baseline.