[debarshri]

My 2 cents, having been in the space for a while and then pivoting out of it. All devops first engineers thinking this is a problem, building something that is more like PaaS but then soon you will realise now not only you have convince engineering managers but also engineers. The total addressable market is fairly small for this type of product, you can throw in compliance guard rails but when an org becomes big they will leave your platform. If you find a customer, you should charge 100 or more as your long value is fairly small. Do checkout the list of PaaS here [1]

[1] https://github.com/debarshibasak/awesome-paas

[bsick7]

Thanks for the feedback!

We have seen the same with our customers and our own experiences -- most teams "graduate" from a PaaS because you're locked into a set of proprietary technologies and hosting.

When they do get large enough, they leave to build their own infrastructure. Unfortunately, they have to rebuild much of the automation and user experience that a PaaS provided for them.

It's fair to call us a PaaS given our launch, but our vision is to give teams automation and collaboration in their own tooling and workflows.

[debarshri]

Ok, let me give you 2 more cents on that. When we had pivoted, to pivoted to automation, tooling and workflows, if-then-then-that framework with webhook and github hook etc. Exactly what you are pitching. That has another set of challenges. It is very hard to sell and motivate engineering teams to use a product like that, forget about even monetizing it. It is what I call the chasm. You get some revenue but not enough to get a breakthrough. One of the insights we had, is that you have to become an enterprise product and you have to let go of consumer-like or product led approach you have in the product. Also, the ICP of your current product is probably not the ICP of the automation product you are building, the learning from the current iteration is not transferrable. I have lot of cuts in this space. Feel free to reach out to me.