3 ms·

(this is my third reply) Because researched stackhut (HN, quora, your website), I feel compelled to offer (unsolicited) advice: I couldn't tell what your sellin

(this is my third reply) Because researched stackhut (HN, quora, your website), I feel compelled to offer (unsolicited) advice: I couldn't tell what your selling point was - as a commentor on one of your HN submissions also said. I see you've pivoted/changed it around it bit over the last 2-3 months, so that makes it harder. Here's a three-step exercise that might help: (1). What did you feel was cool about your basic idea (which seems to be to "wrap docker and kubernetics for easy microservice deployment in the cloud")? i.e. what excited you, what's really cool, about the technology idea, the original technological impetus? (2). What benefit would other people feel, if they were completely ignorant and had never heard of docker or kubernetics or heroku etc? i.e. aiming here at the basic benefit. To illustrate, "easier to use than kubernetics" doesn't mean anything to someone who's never heard of kubernetics or its difficulties. (Many enterprise customers would be in exactly this perfect state of ignorance - they have enough to deal with with their actual domain!) It wouldn't hurt to also consider what benefit that get from cloud hosting (assume they'd never heard of it, as unlikely as that is). Think of yourself as not converting fellow experts from other technologies, but as gaining adherents for the first time - they don't actually want your tech. They want the cloud and you are just the ladder. (3). Finally, think about target users again, now not as completely ignorant, but in terms of and their current situation: their needs (what their bosses/customers need), their plans, how they presently do things, and especially what technologies they have actually heard of and basically know what they are. [ for example, I've heard of the cloud and docker, but I don't really know what the big deal about docker is. I've heard "kubernetics", but I don't know what it is. ] Now craft a message that speaks to these people, given their present situation and perspective. There will actually be several different target customers, with different situations and knowledge, that would require different messages to really speak to them. For example, I'd like a really simple way to write a bit of code and get it hosted in the cloud, for free, to make a simple webservice (or website). It seems it could be (should be) simple, but it isn't. That would be sensational! And great publicity for paid users (freemium, as you're already using).

mands 11y ago
Hi - thanks so much for all the feedback and advice. Have just seen it and will reply fully in the morning (we've been super busy pitching for our accelerator's demo day in the UK - which is an awful excuse!) Really really appreciate you taking the time out to reply and to investigate the tool. Would be great to get on a call sometime and discuss your thoughts further - my email is my HN username @stackhut.com. Thanks again!
mands 11y ago
Thanks so much. Yes, we've pivoted a few times, first starting out with trying to be the 'github for live API's, which is an idea we love but found that the chicken-and-egg situation was tricky to overcome, and that most users just wanted a way to deploy their code to the code to support a webservice. As such we pivoted to building a shared hosting service that let's users just write their code and deploy it. Regarding your 3 questions, my preliminary responses would be (bear in mind we probably would need to think about this further!), 1) We were super excited by the idea based on our own use cases - I found it a nightmare trying to build a distributed back-end to process video in the cloud for a previous startup. This got in the way of building my product but had to be done. Similarly, my co-founder ahead ran into the same issue when he needed to perform web-rendering on the server and just needed an easy way to wrap up this functionality. At this point we though perhaps we could use containers to wrap up the code but found the container ecosystem was focussed heavily on dev-ops and not services, so we built this. 2) Yes, totally agree - our messaging needs a lot of work, we've actually become a lot better in real life but unfortunately haven't updated the website to reflect this! The basic problem is that deploying your code to the cloud is hard. After writing your code locally, you have to do all kinds of orchestration to get your code into the cloud, run it at scale, handle faults, client integration, and more. We feel we can make this simpler. As for why you'd want to move your code to the cloud, hmm, that's a good question. Why the cloud? Don't worry about physical infrastructure., have capacity and capability to scale up compute resources dynamically, ignore hardware maintenance and amortise sys-ops costs with other users. Getting across why users want our code to get to the cloud, if they know what the cloud is, is tricky. Absolutely, becoming an easy way to get code into the cloud followed after this, as we realised just how hard it was. We've moved to the cloud but our tools haven't. 3) Yes, this is the hard bit. Lots of users have existing code, perhaps in the cloud already or locally deploy. They don't know or care about Docker / Kubernetes, etc - and shouldn't have to. We think Docker is a great building block to build services on top of, but we should be able to abstract it away and build on top of it. Eventually we'd hope we can get across our core message - deploy your code to the cloud as easy as running locally - without ever mentioning containers, docker, and more. Perhaps we can do that now, we just to update our message to get that across. For now we're thinking of targeting client-side JS developers as an initial niche and going deep with that while we figure out our tech and message. but yes, the core message is the same - a really simple way to write some code and get it hosted in the cloud as simply as possible (and yes, with a free tier also). It can, and should, be simpler.

mands 11y ago

Hi - thanks so much for all the feedback and advice. Have just seen it and will reply fully in the morning (we've been super busy pitching for our accelerator's demo day in the UK - which is an awful excuse!) Really really appreciate you taking the time out to reply and to investigate the tool. Would be great to get on a call sometime and discuss your thoughts further - my email is my HN username @stackhut.com. Thanks again!

mands 11y ago

Thanks so much. Yes, we've pivoted a few times, first starting out with trying to be the 'github for live API's, which is an idea we love but found that the chicken-and-egg situation was tricky to overcome, and that most users just wanted a way to deploy their code to the code to support a webservice. As such we pivoted to building a shared hosting service that let's users just write their code and deploy it. Regarding your 3 questions, my preliminary responses would be (bear in mind we probably would need to think about this further!), 1) We were super excited by the idea based on our own use cases - I found it a nightmare trying to build a distributed back-end to process video in the cloud for a previous startup. This got in the way of building my product but had to be done. Similarly, my co-founder ahead ran into the same issue when he needed to perform web-rendering on the server and just needed an easy way to wrap up this functionality. At this point we though perhaps we could use containers to wrap up the code but found the container ecosystem was focussed heavily on dev-ops and not services, so we built this. 2) Yes, totally agree - our messaging needs a lot of work, we've actually become a lot better in real life but unfortunately haven't updated the website to reflect this! The basic problem is that deploying your code to the cloud is hard. After writing your code locally, you have to do all kinds of orchestration to get your code into the cloud, run it at scale, handle faults, client integration, and more. We feel we can make this simpler. As for why you'd want to move your code to the cloud, hmm, that's a good question. Why the cloud? Don't worry about physical infrastructure., have capacity and capability to scale up compute resources dynamically, ignore hardware maintenance and amortise sys-ops costs with other users. Getting across why users want our code to get to the cloud, if they know what the cloud is, is tricky. Absolutely, becoming an easy way to get code into the cloud followed after this, as we realised just how hard it was. We've moved to the cloud but our tools haven't. 3) Yes, this is the hard bit. Lots of users have existing code, perhaps in the cloud already or locally deploy. They don't know or care about Docker / Kubernetes, etc - and shouldn't have to. We think Docker is a great building block to build services on top of, but we should be able to abstract it away and build on top of it. Eventually we'd hope we can get across our core message - deploy your code to the cloud as easy as running locally - without ever mentioning containers, docker, and more. Perhaps we can do that now, we just to update our message to get that across. For now we're thinking of targeting client-side JS developers as an initial niche and going deep with that while we figure out our tech and message. but yes, the core message is the same - a really simple way to write some code and get it hosted in the cloud as simply as possible (and yes, with a free tier also). It can, and should, be simpler.