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 k

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.