When it comes to software built for developers, we’re all used to seeing some sort of freemium, self-serve element.
Naturally, as a result, striking the right balance between what’s free and what’s paid is one of the business’s biggest growth levers. But I’ve personally found that if it feels easy to set that paywall for your product, you’re probably forgetting something. For example, when Toast added a fee to its online orders that was pushed through to end-users ordering food, they caused backlash among their own customer base–restaurateurs: a small word-of-mouth driven community.
Best case scenario, if you mess up paywalls you’re leaving money on the table and you can potentially raise prices later. Worst case scenario, you can inhibit user engagement, growth, and potentially virality.
Pricing must equal value
The best products align their exchange of value (their pricing metric) with the value that users receive from their product. Data shows that developers prefer to pay for infrastructure software via a consumption model, which makes total sense. They may spend weeks setting up a proof-of-concept and shouldn’t be charged for that until they actually receive product value.
That’s not to say other packaging models don’t exist. The framework below shows how I think about packaging free products for optimal adoption paths with examples of large businesses that price and package in this way.
Usage-based pricing at ngrok
“It just works” is a catchphrase heard from ngrok users constantly, and it supports our vision of an easy-to-use, developer-first ingress platform. Whether developers are using ngrok for testing webhooks, or as an API gateway within their production environment, they are frequently pleased with the product’s ergonomics.
Unfortunately, the same couldn’t be said about ngrok’s pricing and packaging. As ngrok is more widely adopted for production use, outreach from users trying to spin up multiple endpoints for device or app connectivity increased greatly; nothing we offered via self-service felt like a great fit for these users. For the team at ngrok, that felt like a miss–we want all users, even large enterprises, to be able to get their project up and running on the platform in a self-service way.
The problem is complicated, but the answer is simple: as ngrok has gained users who see our product as an infrastructure solution, we need to be priced in a manner they expect. A manner that makes them excited to continue using ngrok. In fact, 92% of developer-focused products with public pricing price their products based on usage.
So, after months of testing with sales conversations, competitive analysis, surveys, and users like you, we launched the pay-as-you-go plan—a new pricing plan that represents a new era of how users leverage ngrok capabilities to move beyond development and testing and into production environments. This plan metrics on a few things, but the largest metric is monthly active endpoints—the distinct number of TCP addresses or domains that you transmit data through in a given month. So, if you have an endpoint that’s live but isn’t used, you don’t pay for it. If you have agents out in the world, you don’t have to remember to take them offline or remove them–you don’t pay for them unless a session is actively transmitting data.
This plan is best leveraged by developers using ngrok in production—using ngrok to get ingress into APIs or apps on devices or machines, in bring-you-own-cloud customer scenarios, or using ngrok to surface up their own applications or websites to the web safely.
Get started with ngrok today, and only pay for what you use
As trite as it sounds, this is just the beginning for usage-based pricing at ngrok. You can learn more on our pricing page, or sign up today and get started. For a breakdown of how our pricing works, check out our new doc. We’re working out the bugs, so hit me up with feedback, comments, or questions at sam@ngrok.com.