Yea, I think it does. I'm glad that you're not looking at support as a primary revenue source since that seems to be the kind of thing that leads to companies

Yea, I think it does. I'm glad that you're not looking at support as a primary revenue source since that seems to be the kind of thing that leads to companies not wanting to fix pain points because those pain points are what people pay support contracts to handle. That's just a horrible tension because there's no reason to eliminate complexity. An enterprise company with a giant support contract just gets a support engineer to solve that complexity for them and it pushes everyone else to buy a support contract to get you to solve things. As someone working on a small team and trying not to burn cash, it feels like so much has become expensive since the "old" days of VPSs. Part of that is that people are accustomed to CI/CD, zero-downtime deploys, etc. Those are kinda table-stakes in a sense now. Many things are "solved" if you're willing to pay Amazon or Google higher margins, but it's tough if you're trying to build something user-friendly and lower-margin on your end (I mean, ultimately, it probably means that we should be pivoting toward something higher margin, but we love what we're working on). I definitely think RBAC can be a great differentiator between "small team" and "people who should pay us". At some point, you go from startup where people trust each other to "we need to be responsible and only some people get access to some parts". At the point that you're paying dozens of engineers, it seems reasonable to send some money to your PaaS provider that helped you get there and keeps you humming. I think mentioning RBAC really gets me on the "oh, yea...that makes sense. It's great and happy for a team of 3 looking for that awesome Heroku experience and fighting cash burn and when they hit a dozen or so engineers and are getting revenue and scaling up, $5,000/mo probably seems like nothing to pay for RBAC". I really hadn't thought much about "what" might be a good up-charge without either making the platform crappy for free users or something people wouldn't pay for. Heck, make SSO a paid add-on. Companies will pay so much for SSO while a small team of a few people can easily be like "yea, you just have a different password in the PaaS". I mean, Okta is worth billions just trying to solve SSO. Those both feel like features that companies making real money wouldn't hesitate to fork over cash for while someone working on a side project or a startup trying to become ramen-profitable can avoid. It definitely quells my worries of "will they decide that it's limited to 3 machines" or "will they decide that high-availability is just an enterprise feature" or "will they disable Let's Encrypt for free users". I mean, there are so many ways that a product can go into the "this is basically just trial software unless I pay" bin. I think pointing out that you're post-dating k8s by a decent amount is a great point too. A lot of things like Portainer pre-date k8s (and lots of things we take for granted now-a-days like Let's Encrypt) and now have Docker, Docker Swarm, and k8s modes that they're looking to support. Building as the ground is shifting underneath you isn't easy - you're building when k8s is pretty well-established, Helm seems established, etc. You're not trying to figure out where containers are going. You're not worried about Docker Swarm, Mesos, etc. You're just trying to make it fun and pleasant for people. Since you're here, one thing that I would say is that it would be nice if there was an easy "get a basic k8s setup on these servers I have" automated into your thing or a small doc of how you think it should be setup to start. I see that one can choose between AWS, GCP, DO, or "I already have k8s", but it would be nice to see something to get over that hurdle outside the three blessed platforms. Best of luck to you over the coming months!