4 ms·

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure,

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently. I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there was a discussion[0] on HN that I think you triggered actually). I really find it hard to estimate how many config requests or connected servers we might have... And the last thing I want is for things to stop working or trigger some unknown billing when we're bootstrapping new servers, or re-jigging our configs. Per developer sounds totally reasonable to me. You're aiming to make secrets management simple. Can't your pricing mirror this? [0] https://news.ycombinator.com/item?id=16477316 https://news.ycombinator.com/item?id=16477316

danenania 9y ago
Thanks for the feedback. As you can see from that thread, EnvKey started out with per-developer pricing. The main issue is that we have some customers who use EnvKey with hundreds of servers and only one or two users. This, of course, doesn't work out very well for us in terms of unit economics and pricing based on the value the service provides. That said, the usage caps are meant to be generous and not get in the way. If you're using EnvKey in a 'normal' way and not spinning up thousands of parallel processes or something along those lines, you'll be way, way under the limits on config requests. For connected servers, it's really just a question of how many server instances you're running that use EnvKey, which is something I would think you need to plan for anyway when it comes to hosting costs. I'm very open to adjusting these based on feedback if they are getting in the way / not matching up correctly with value. But as much as I'd prefer otherwise, I'm afraid there do need to be some sort of usage-based limits to make it work.
- CaveTech 9y ago
  I'm in a similar boat to the OP. We're near the boundary of your pricing between startup and traction, but the non linear jump (while being more common these days) is an immediate turn off. There's a pretty big difference between $240 and $1200 a year when it comes to discretionary spending.
  - pw 9y ago
    I'd argue that if you're worried about a thousand dollars a year difference over the course of a year, you're not a customer worth having.
- rjhacks 9y ago
  I think the use case where the per-config-request pricing model could break is with serverless (like Lambda or Cloud Functions or ...). Secret management there is super important, and your solution looks great, except that what makes these platforms great for low-cost deployments is that they "scale to 0" (turn off your instances when there's no traffic), which means that each instance potentially lives just briefly. Since each start of each instance is a config request, that could in some cases become problematic. That said, at your lowest tier you could have ~20 moments of "booting a new instance" per hour. That's probably plenty for most cases, although you may find users for whom it isn't enough.
  - danenania 9y ago
    Good point. What I'll say for now is that if anyone wants to use EnvKey with Lambda or Cloud Functions and is worried about this, feel free to reach out - dane@envkey.com. We'll make sure you're paying a reasonable price that reflects your usage level.
pw 9y ago
I don't get what the issue here is. Guess at which plan you'd need and go about your business. I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. Even if they weren't, what's the risk here? That you'd end up owing a couple hundred extra dollars? If you're worried about that, you're probably not a customer they want. This sound like standard developer cheapness.
- gingerlime 9y ago
  > I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. I certainly hope so, but we've been bitten by surcharges before when we had a mini-DoS on our system... Besides that, there's a big element of trust here. I'm going to trust these guys with my most important secrets. I expect a trustworthy, transparent and simple solution that doesn't surprise me. Pricing is an element of that. > This sound like standard developer cheapness. I'm sorry, but this is just mean. I'm happy to pay, but I want to predict my costs. I understand usage-based pricing, but for a secret management system, I really don't see how this applies. Sure, there might be outliers who might spin 1 billion micro-processes each connecting to their system, but I think it's the wrong approach to base your pricing on those. At least not until you're the scale of Amazon. Or even Digital Ocean. I think I'm exactly the customer they want, but my 2 cents advice is to simplify pricing. Charge more. Fine. Just make it simple and clear.
  - danenania 9y ago
    Thanks for laying out your concerns. Is your feeling that any sort of usage-based tiers that go beyond per-user pricing are too complex? Or is there some way to limit usage in a reasonable way that wouldn't rub you the wrong way?
    - gingerlime 9y ago
      Just to clarify, I truly believe it's in your interest to make pricing simpler. It just helps building trust, and conveys the same product simplicity. This is key (no pun intended) with this kind of service. Specifically, I think per-developer pricing should correlate well with value. Sharing secrets increases in complexity when more people are involved. One other thing I can think of perhaps is environments. Maybe bigger customers would have more environments that need to be kept separately? (production, staging, test, dev come to mind, but potentially a more granular split in larger orgs. Billing environment, Marketing etc). Maybe you could offer totally separate accounts that are independent of each other, but billed together. Keeping things separate also has security value. Servers: it gets much more messy much quicker in my opinion. Docker-based setups, auto-scaling groups etc make this difficult. So this reduces pricing predictability for us, and I imagine others. Config requests: I don't even have a clue what this means before I start. But seeing this deters me. You explain it on the FAQ section, but I still have to do some homework to figure out roughly my usage, before I even try your product... This is the worse pricing element in my humble opinion. In any case, I'm just one data point. If you have enough traffic, then you should A/B test this. Otherwise, talk to your customers (although then there's selection bias at play), or copy from someone else with a similar service? At your early stage, I think building momentum and traction is more important than worrying about outliers. You have many more years to refine pricing and figure out how not to lose money and attract the right customers. But now you should probably get as many customers as possible to see that it's a viable business and build a reputation. Just my 2 cents.

danenania 9y ago

Thanks for the feedback. As you can see from that thread, EnvKey started out with per-developer pricing. The main issue is that we have some customers who use EnvKey with hundreds of servers and only one or two users. This, of course, doesn't work out very well for us in terms of unit economics and pricing based on the value the service provides. That said, the usage caps are meant to be generous and not get in the way. If you're using EnvKey in a 'normal' way and not spinning up thousands of parallel processes or something along those lines, you'll be way, way under the limits on config requests. For connected servers, it's really just a question of how many server instances you're running that use EnvKey, which is something I would think you need to plan for anyway when it comes to hosting costs. I'm very open to adjusting these based on feedback if they are getting in the way / not matching up correctly with value. But as much as I'd prefer otherwise, I'm afraid there do need to be some sort of usage-based limits to make it work.

CaveTech 9y ago
I'm in a similar boat to the OP. We're near the boundary of your pricing between startup and traction, but the non linear jump (while being more common these days) is an immediate turn off. There's a pretty big difference between $240 and $1200 a year when it comes to discretionary spending.
- pw 9y ago
  I'd argue that if you're worried about a thousand dollars a year difference over the course of a year, you're not a customer worth having.
rjhacks 9y ago
I think the use case where the per-config-request pricing model could break is with serverless (like Lambda or Cloud Functions or ...). Secret management there is super important, and your solution looks great, except that what makes these platforms great for low-cost deployments is that they "scale to 0" (turn off your instances when there's no traffic), which means that each instance potentially lives just briefly. Since each start of each instance is a config request, that could in some cases become problematic. That said, at your lowest tier you could have ~20 moments of "booting a new instance" per hour. That's probably plenty for most cases, although you may find users for whom it isn't enough.
- danenania 9y ago
  Good point. What I'll say for now is that if anyone wants to use EnvKey with Lambda or Cloud Functions and is worried about this, feel free to reach out - dane@envkey.com. We'll make sure you're paying a reasonable price that reflects your usage level.

pw 9y ago

I don't get what the issue here is. Guess at which plan you'd need and go about your business. I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. Even if they weren't, what's the risk here? That you'd end up owing a couple hundred extra dollars? If you're worried about that, you're probably not a customer they want. This sound like standard developer cheapness.

gingerlime 9y ago
> I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. I certainly hope so, but we've been bitten by surcharges before when we had a mini-DoS on our system... Besides that, there's a big element of trust here. I'm going to trust these guys with my most important secrets. I expect a trustworthy, transparent and simple solution that doesn't surprise me. Pricing is an element of that. > This sound like standard developer cheapness. I'm sorry, but this is just mean. I'm happy to pay, but I want to predict my costs. I understand usage-based pricing, but for a secret management system, I really don't see how this applies. Sure, there might be outliers who might spin 1 billion micro-processes each connecting to their system, but I think it's the wrong approach to base your pricing on those. At least not until you're the scale of Amazon. Or even Digital Ocean. I think I'm exactly the customer they want, but my 2 cents advice is to simplify pricing. Charge more. Fine. Just make it simple and clear.
- danenania 9y ago
  Thanks for laying out your concerns. Is your feeling that any sort of usage-based tiers that go beyond per-user pricing are too complex? Or is there some way to limit usage in a reasonable way that wouldn't rub you the wrong way?
  - gingerlime 9y ago
    Just to clarify, I truly believe it's in your interest to make pricing simpler. It just helps building trust, and conveys the same product simplicity. This is key (no pun intended) with this kind of service. Specifically, I think per-developer pricing should correlate well with value. Sharing secrets increases in complexity when more people are involved. One other thing I can think of perhaps is environments. Maybe bigger customers would have more environments that need to be kept separately? (production, staging, test, dev come to mind, but potentially a more granular split in larger orgs. Billing environment, Marketing etc). Maybe you could offer totally separate accounts that are independent of each other, but billed together. Keeping things separate also has security value. Servers: it gets much more messy much quicker in my opinion. Docker-based setups, auto-scaling groups etc make this difficult. So this reduces pricing predictability for us, and I imagine others. Config requests: I don't even have a clue what this means before I start. But seeing this deters me. You explain it on the FAQ section, but I still have to do some homework to figure out roughly my usage, before I even try your product... This is the worse pricing element in my humble opinion. In any case, I'm just one data point. If you have enough traffic, then you should A/B test this. Otherwise, talk to your customers (although then there's selection bias at play), or copy from someone else with a similar service? At your early stage, I think building momentum and traction is more important than worrying about outliers. You have many more years to refine pricing and figure out how not to lose money and attract the right customers. But now you should probably get as many customers as possible to see that it's a viable business and build a reputation. Just my 2 cents.