> Everything is "exposed" by default. It works on top of AWS Cloudformation. You can extend the CF template using native AWS Cloudformation, or override anythin

> Everything is "exposed" by default. It works on top of AWS Cloudformation. You can extend the CF template using native AWS Cloudformation, or override anything that Stacktape generates. > So basically, Stacktape gets you to production very fast, but isn't an obstacle when you need to scale and go "lower level". I get what you're saying, but please look a little closer at your messaging and your value proposition. Your value proposition is "with Stacktape, you don't need to hire a DevOps engineer, we charge you not even 10% the cost of a DevOps engineer, therefore by buying Stacktape you will save money." But, apparently, eventually your customer might/will grow out of what Stacktape can offer, in which case your customer will hire a DevOps engineer anyway, and well at least they can take comfort that there won't be any vendor lock-in. Which begs the question - how is a customer supposed to know when that point in time could or would be? You're not promising that they'll never need a DevOps engineer, because you'll help them migrate, and you're not promising the benefits of a PaaS, including full responsibility for the resources you create, because ultimately they just belong to the customer on their account and it's all their responsibility. I don't think telling people "we help you spin up lots of stuff that you don't understand but you'll be responsible for it anyway if something goes wrong" is a compelling message. People who look at your pricing page, they're not going to compare your price to the price of a PaaS or a DevOps engineer, because you're not providing the value of a PaaS or a DevOps engineer, i.e. someone with the experience to take responsibility and fix things when and if they go wrong. Instead, they will compare it to the actual value they are getting, which is "is it worth it to me to pay $45/month to read these docs and maintain this shorter YAML, than it is to read these other docs and maintain this admittedly longer YAML?" Maybe there is a market like that, and if so, then I wish you the best of luck (I'm a DevOps engineer so I already understand that longer YAML so your solution doesn't give me value).