Comment by danenania | Hacker News Reader

Comment by danenania | Hacker News Reader

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

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.

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.

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.

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.

> 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.

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.

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?

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.

Thank you for this comment. I think it's spot on with keeping some aces in your pocket for appropriate time. It's not fun to keep onto unreleased features, but the product should continue to grow with time. If one wants to increase prices, ideally this goes along with added features.

Just limit the number of environments and keys that can be managed on each tier. 3 environments and 5 keys at the low end, 20 and 50 at the high end with a "call us" option for super heavy use.

Even if you can't rate limit in your current release it's in the license and when you can you move people up to a higher tier. This solves the issue of charging larger customers more without them getting more value.

Unlimited number of users, files, etc should never be part of a public pricing tier. Fine for a negotiated agreement with an enterprise that has a definite period - it's a great thing to concede to close an enterprise deal and should be essentially costless. When it is in a public price list it makes larger sales much, much harder.

There's nothing wrong with same features at all price points - he's allowing more users the higher the prices go.

I used to work at NetSuite and this is exactly how we did it, the real cost (after any consulting) is the cost of users.

We exited to Oracle for 9billion.

You cannot compare billion dollars established a company, existing years ago, to today's SaaS startup. It is like comparing solutions form 2010 car to 2016 car. Web market changes fast.

That doesn't mean anything.

You can charge more for more users, there's nothing wrong with that model. The more resources you require, the more you pay.

My opinion is not binary. While I understand your point of view, I think, that there is much more optimized and valuable revenue models for SaaS startups.

Reply on news.ycombinator.com