3 ms·

Congratulations on the raise and good luck making it work! I already posted a similar question on an earlier thread from ReleaseHub, and maybe I'm misunderstan

Congratulations on the raise and good luck making it work! I already posted a similar question on an earlier thread from ReleaseHub, and maybe I'm misunderstanding the constraints, but I'm still wondering about your positioning strategy. Specifically, how will you deal with the chicken/egg problem of your customers needing a semi-mature ops pipeline in order to create the images that ReleaseHub can deploy? It seems like your best customers would be those who don't have the technical expertise to setup automated build systems and CI pipelines. But in order to use ReleaseHub, do those customers need to ship some artifacts to you? And if they have to create those artifacts anyway, and also deploy them to prod in the meantime, isn't that like 90% of the way to having an environment per deployment? At that point, if they've managed to do that much by themselves, why would they outsource the last part? Seems like you have two ways to approach this. (a) Add lots of bells-and-whistles post-deployment so that it's not just "the last 10%", but a full suite of marketing/demo/QA tools with each deployment. Or (b), simplify the requirements for what customers have to ship to you, so e.g. they can `git push` a repository with a `yarn.lock` and `package.json`, and you'll handle all the pre-deploy build steps as well. The risk of (b) seems to be feature creep, in that you end up building a generic PaaS platform rather than focusing on your core differentiator of per-environment deployments. The risk of (a) might be the classic Parse.com problem – you attract a bunch of early startups as customers, but once they grow into a more profitable customer, they also outgrow your service and churn as they decide to replicate it in-house. I'm sure you've thought about these challenges, and that the investors asked about them, so I'm just curious how you plan to approach them. You've got a clear value proposition, but positioning and differentiation will be your biggest challenges IMO. I'd be especially weary of GitLab and GitHub encroaching on this territory. Either way, best of luck to you. The website is great and the product sounds useful!

cardmagic 6y ago
I think ReleaseHub is going for (b). The differentiation is that it would be a fully managed and fully configurable/customizable PaaS on your own infrastructure or even on premise instead of a black-box infrastructure owned and managed by the PaaS provider.
jeremy_k 6y ago
Thank you for the kind words. I'll try to answer what I can! In regards to the customers needing an ops pipeline to create images, that isn't necessary to use Release. We have our own build infrastructure, running on Docker Buildx so we can take your code, turn it into container images and deploy it without you needing to have anything set up yourself aside from a working Dockerfile. But there may be customers who do already have their own pipeline setup running tests and creating images so we did create an external API for shipping those images to us [1]. Creating full fledged integrations with other service providers is something we've thought of exploring, but for now it would be possible to create an environment via a POST call with the image information and a bit of pre-setup to make sure we can pull the images from where you've stored them. What you describe in (b) is definitely possible right now. The `git push` will send the webhook to us, we'll create the image and automatically deploy the environment. What you describe in (a) is also something we think is important. We have an integration with LaunchDarkly [2] that has pre and post deployment hooks so building out features around those type of hooks for different use cases is something we want to lean into. Another example in the (b) category is our Instant Datasets [3] which gives you an RDS instance with pre-filled data to be used for say a sales demo or a QA validation. [1] - https://docs.releasehub.com/api-documentation/release-api/create-a-staging-environment https://docs.releasehub.com/api-documentation/release-api/cr... [2] - https://docs.releasehub.com/integrations/integrations-overview/launchdarkly-integration https://docs.releasehub.com/integrations/integrations-overvi... [3] - https://docs.releasehub.com/reference-guide/instant-datasets https://docs.releasehub.com/reference-guide/instant-datasets

cardmagic 6y ago

I think ReleaseHub is going for (b). The differentiation is that it would be a fully managed and fully configurable/customizable PaaS on your own infrastructure or even on premise instead of a black-box infrastructure owned and managed by the PaaS provider.

jeremy_k 6y ago

Thank you for the kind words. I'll try to answer what I can! In regards to the customers needing an ops pipeline to create images, that isn't necessary to use Release. We have our own build infrastructure, running on Docker Buildx so we can take your code, turn it into container images and deploy it without you needing to have anything set up yourself aside from a working Dockerfile. But there may be customers who do already have their own pipeline setup running tests and creating images so we did create an external API for shipping those images to us [1]. Creating full fledged integrations with other service providers is something we've thought of exploring, but for now it would be possible to create an environment via a POST call with the image information and a bit of pre-setup to make sure we can pull the images from where you've stored them. What you describe in (b) is definitely possible right now. The `git push` will send the webhook to us, we'll create the image and automatically deploy the environment. What you describe in (a) is also something we think is important. We have an integration with LaunchDarkly [2] that has pre and post deployment hooks so building out features around those type of hooks for different use cases is something we want to lean into. Another example in the (b) category is our Instant Datasets [3] which gives you an RDS instance with pre-filled data to be used for say a sales demo or a QA validation. [1] - https://docs.releasehub.com/api-documentation/release-api/create-a-staging-environment https://docs.releasehub.com/api-documentation/release-api/cr... [2] - https://docs.releasehub.com/integrations/integrations-overview/launchdarkly-integration https://docs.releasehub.com/integrations/integrations-overvi... [3] - https://docs.releasehub.com/reference-guide/instant-datasets https://docs.releasehub.com/reference-guide/instant-datasets