4 ms·

I've been trying to figure out the ideal pricing structure for EnvKey[1], a saas configuration and secrets manager. I want something that is affordable for indi

I've been trying to figure out the ideal pricing structure for EnvKey[1], a saas configuration and secrets manager. I want something that is affordable for indie devs and smaller teams, but then scales up for larger companies who face this problem to a greater degree and tend to see more value in solving it. The pricing is currently per user, since I've envisioned it as a tool that you'd invite all your developers onto. For the most part, this has been the case, but there are some companies using it heavily on the server-side and only inviting a small number of users. To account for this, I've considered charging a small amount per access key (say $2/mo for a base plan) instead of per user. A typical app has an access key for each developer working on it, plus one per server, so for a team of 5 this would work out to ~16/app/month (assuming test, staging, and production server environments; some have more). Most teams seem to have at least a few apps; some have as many as 10. The good thing is this would scale up with usage, starting very low and then getting pretty substantial as you get more and more use out of the product. The bad thing is... it would scale up with usage, and therefore might disincentive heavy use. Any thoughts? 1 - https://www.envkey.com https://www.envkey.com

ttul 9y ago
Don’t fall into the cost-plus trap. Figure out typical usage sizes and then provide tiered pricing. Don’t underestimate what people will pay, and don’t try to capture the $2 user. They will not make you rich unless you have mega capital to find millions of them.
- ttul 9y ago
  And by tiered, I mean $49/mo for up to 10 keys, $249.99/mo for up to 50 keys, etc... and gate features at each tier.
  - gingerlime 9y ago
    Per key feels greedy and potentially insecure to me. “Damn. We reached our limit. Ok, let me hard code this key for now...” I think per developer is more fair and still a good approximation of buying power and utility.
    - ghein 9y ago
      You want to charge based on the value that you deliver. You can have small teams with large per capita usage, and large teams with low per capita usage. You ideally charge a price that each customer is happy with and that makes sense for your business. If you can't survive with 100x or 1000x as many customers at this pricing tier, you either take it off the price list immediately or when you get n additional customers of this tier (if you're still testing for product market fit). The ideal price list repels potential customers that are a bad fit for your business. Doesn't make anyone greedy or customers bad people - just that a firm has a higher cost base or a specific business/individual won't get enough benefit from the product offered.
      - gingerlime 9y ago
        > You want to charge based on the value that you deliver. Charging per key reduces the value in my opinion, exactly for the reason I stated above. It puts blocks at the point where the product is most useful (Adding a key). I can live with extra cost when a new developer is brought on board. There's already a few things I need to buy to bring them on, and this is a reasonable extra cost. But adding charges when I add key adds friction exactly at the point where I want the product to reduce it.
BartBoch 9y ago
I have checked your pricing page, and I think you are penalizing larger users without trying even to hide that. You require large users to pay more for the same functionality, that $5/mo user gets. I would create 2 plans: 1) Regular, $9/mo per user 2) Enterprise, $29/mo per user with some added functionality, like custom login page, branding and some user management/sub-users. This way you will give an actual value to enterprises, that justifies paying more, while keeping smaller users happy, by removing confusing pricing.
- danenania 9y ago
  Yeah, I was curious what people would think of that. My logic is that resource usage for end-to-end encryption scales exponentially, not linearly, and it's also a more expensive problem for a larger company to deal with (either in terms of engineering time or dealing with a breach). I've been planning to add additional perks to the larger tiers over time though. For example, I'm now working on audit logs, and will likely limit the amount of history for the lowest plan (sort of like Slack). On the per-user pricing, how do you think about the possibility of a company that signs up with just a few users but manages hundreds of servers through the product?
  - BartBoch 9y ago
    I think this is a non-problem now. As of now, you want to grow your user base as much as possible. Since all your users are paying, you are not carrying a dead weight of freemium. Build up user count by any means possible. Only once you will see a significant drop in growth of revenue try to upsell current user base by adding important features. Keep, for example, Cloudflare in mind. They have first built their user base, and once they were used by thousands of companies, they started offering additional options, Enterprise ($2K+) accounts etc. Focus on growth first, and keep some aces in your pocket for the time your revenue will stall. This way you will be able to be innovative whenever growth is slow, and there is a possibility a competitor will show up and take your business.
    - mkarnicki 9y ago

ttul 9y ago

Don’t fall into the cost-plus trap. Figure out typical usage sizes and then provide tiered pricing. Don’t underestimate what people will pay, and don’t try to capture the $2 user. They will not make you rich unless you have mega capital to find millions of them.

ttul 9y ago
And by tiered, I mean $49/mo for up to 10 keys, $249.99/mo for up to 50 keys, etc... and gate features at each tier.
- gingerlime 9y ago
  Per key feels greedy and potentially insecure to me. “Damn. We reached our limit. Ok, let me hard code this key for now...” I think per developer is more fair and still a good approximation of buying power and utility.
  - ghein 9y ago
    You want to charge based on the value that you deliver. You can have small teams with large per capita usage, and large teams with low per capita usage. You ideally charge a price that each customer is happy with and that makes sense for your business. If you can't survive with 100x or 1000x as many customers at this pricing tier, you either take it off the price list immediately or when you get n additional customers of this tier (if you're still testing for product market fit). The ideal price list repels potential customers that are a bad fit for your business. Doesn't make anyone greedy or customers bad people - just that a firm has a higher cost base or a specific business/individual won't get enough benefit from the product offered.
    - gingerlime 9y ago
      > You want to charge based on the value that you deliver. Charging per key reduces the value in my opinion, exactly for the reason I stated above. It puts blocks at the point where the product is most useful (Adding a key). I can live with extra cost when a new developer is brought on board. There's already a few things I need to buy to bring them on, and this is a reasonable extra cost. But adding charges when I add key adds friction exactly at the point where I want the product to reduce it.

BartBoch 9y ago

I have checked your pricing page, and I think you are penalizing larger users without trying even to hide that. You require large users to pay more for the same functionality, that $5/mo user gets. I would create 2 plans: 1) Regular, $9/mo per user 2) Enterprise, $29/mo per user with some added functionality, like custom login page, branding and some user management/sub-users. This way you will give an actual value to enterprises, that justifies paying more, while keeping smaller users happy, by removing confusing pricing.

danenania 9y ago
Yeah, I was curious what people would think of that. My logic is that resource usage for end-to-end encryption scales exponentially, not linearly, and it's also a more expensive problem for a larger company to deal with (either in terms of engineering time or dealing with a breach). I've been planning to add additional perks to the larger tiers over time though. For example, I'm now working on audit logs, and will likely limit the amount of history for the lowest plan (sort of like Slack). On the per-user pricing, how do you think about the possibility of a company that signs up with just a few users but manages hundreds of servers through the product?
- BartBoch 9y ago
  I think this is a non-problem now. As of now, you want to grow your user base as much as possible. Since all your users are paying, you are not carrying a dead weight of freemium. Build up user count by any means possible. Only once you will see a significant drop in growth of revenue try to upsell current user base by adding important features. Keep, for example, Cloudflare in mind. They have first built their user base, and once they were used by thousands of companies, they started offering additional options, Enterprise ($2K+) accounts etc. Focus on growth first, and keep some aces in your pocket for the time your revenue will stall. This way you will be able to be innovative whenever growth is slow, and there is a possibility a competitor will show up and take your business.
  - mkarnicki 9y ago