Founder here. Would love feedback from HN. If you'd like to try out the platform, please email me - rsingh@distelli.com - and I'll set you up with an account.
I don't get it. The value prop: "Easily Deploy your Code to Any Server."
I don't want to deploy my code/application to "any" server. In fact, I want to deploy it to the smallest number of servers possible and then change that infrastructure as infrequently as possible. Time spent futzing with infrastructure that's not essential to my customer's experience is time wasted, after all.
And from your copy it seems like you're selling "portability." Once I settle on EC2, though, I'm going to be pretty-well settled on EC2, so portability does very little to benefit me.
Moreover, once I've settled on EC2 I'm quickly going to set up a deployment process. Let's say I'm using Rails + Capistrano for deployment. In a world where I need to switch urgently to another infrastructure service, I know I'll be able to do so with only minimal modifications to my Capistrano script. In any case, necessary changes to the deploy script will be about the same amount of work as necessary changes to the application code and I'm going to have to make those, regardless.
So, overall, the value this provides seems very minimal relative to the likely complexity it would add in other places.
Edit: Reading other comments, this is more like Capistrano-as-a-service it seems? That might be interesting, especially if it comes with process monitoring tools. The page really screams "portability" to me, though.
A tag line like "Deploy your application like the professionals" might do better to get that point across.
I like where this is going. I actually had this idea too, sort of (I wanted a hosted puppet master, then when salt came along, hosted salt master).
However, there's one gaping problem with it.
You seem to have a hosted "weird proprietary yaml language" master.
I don't want the headache of learning a new language, particularly not one with vendor lock in. If it is one of the above, tell me. If it's not, why the hell not?
P.S. This is a hint, I signed up yesterday but haven't received access yet. Here's hoping I get the beta email today and not in a month.
When I sign up I'm attempting to test it out now, on "my time". When access is delayed by a month testing it is on "whenever I get to it time" and generally just falls by the wayside. Hopefully this is meaningful feedback in and of itself.
The only thing I really have to say is beware of carousels... I didn't even notice you had carousels until reaching the bottom of your 'how it works' page.
The system requirements are only that you be running linux and python 2.4 or greater on your server.
I agree that it sounds too grandiose but I would love the opportunity to have you as a beta users and demonstrate that are claims are not marketing speak and smoke and mirrors.
I'm a developer myself and I don't like marketing speak.
Firstly, I like the idea. Its a great application.
At first glance I got a feeling that the website design is incomplete. The hovering on the menu seems a bit too sharp. I am no designer so I am not sure what the exact terms to be used are. I just think you should maybe put some work into the interface and it would look much more appealing.(I am just talking about the look and not the app itself). Good Luck.
Thanks for your feedback. We have a lot of work to do and we'll iterate on the site design! Your feedback and detailed thoughts would be welcome (rsingh@distelli.com)
Sorry I say we because I'm practicing to talk like we're a big company but you're right, that right now I'm working alone. I'm looking for a biz dev / sales /marketing type person to join though
Your text animation doesn't work well on mobile (iOS Safari). When you scroll down, the text keeps bouncing up and down, due to the resize of the text (1 vs. 2 lines).
Love the concept. I think the main area with the white rects is too busy. You want to have fewer hooks, that users can dig in to. Signed up for the beta!
You just have a signup for beta button that you are using to collect email address instead of a full pricing page. I understand why people tend to do their for their first version. You're scared that not everything works yet, and you don't want to take the time to setup the payment system if no one even wants it.
However, this does a disservice to you and to me.
To you:
You don't really know if people want to buy your product or not. Collecting email addresses is way easier that collecting money. It's also not nearly as exciting. Don't remove the option for me to just give you just my email address, but also let me give you money.
You'll know I really want your product that way. Also, initial customers are probably more forgiving that you imagine. Worst case scenario, you can just refund the money.
To me:
Without the pricing page, I can't really tell what your product does. For all the description and "how it works" pages in the world, nothing really tells me what you are selling like your pricing page.
Companies tend to charge where they are adding value. If I can see what you are charging for, I can see where you are going to add value to my company. Are you charging per server, per deploy, per employee, per user? Without the pricing page, I don't understand what I'm buying.
You're right and all your points are on target. We have a working platform right now (and infact we're using it to deploy our own code and services to EC2).
Our pricing is still TBD, but its going to be a low price per server per month sort of model.
We'll update the site with a pricing page soon! Please email me and I can answer more of your questions in detail.
Please don't do yourself a disservice by accomodating low price for high value. If your product is going to derive lots of value charging a high price isn't absurd.
Thats a good point. We're still trying to figure out the price point, but our goal is to go for adoption and volume. Your thoughts on this would be welcome and help us figure out our strategy.
Yes. I am a single founder. I have a mentor who is advising me and the "we" is because I'm practicing to sound like a big company when I talk to enterprise customers. They don't like hearing "I". I'm also working on growing the team and getting additional people to join me.
It's probably your first reaction to try and sound like a big company, but personally I'd would avoid that if I could. Especially if it comes off unnaturally (which it appears to have done at least in this instance). In some cases you can play your small size as an advantage, at least for your first customers. Just as a single example, a small company can offer much more personalized customer service. For more about this, see the "Delight" section of pg's most recent essay: http://paulgraham.com/ds.html
I think you should spend some time to talk about the pain you are fixing. There's no hook. What problem am I having now that you are going to make go away?
Excellent point! The pain is around making it easier for developers to deploy to multiple servers and clouds but also to help you keep track of whats deployed and running and where is it running.
Also the teams features make it easy to collaborate and see who change what and when.
So what process am I using now that you are going to replace? I must be doing something because my code gets deployed.
Give point by point details about how what I am doing right now sucks. It make me hate my job, keeps me up at night, turns away customers, and loses me money.
Then, after you have convinced me that my current process sucks (and epiphanized with me that it was the best I could do at the time), go back though every point and tell me how you have fixed them.
Thank you Bilal for your endorsement and kind words!! I appreciate it. Building a company as a single founder is hard and every bit of encouragement helps.
So I load up my services that I need to run on multiple Linux servers into a package, and then distelli will deploy, run and manage those packages.
You're selling a service though - I'm guessing your service will connect into the Linux servers directly (root access?) and manage everything directly. Obviously, that gives your service full access to both the package contents and to the servers themselves. That feels a bit risky - am I correct here?
The service does not connect to the linux server directly. The server runs an agent that connects to the service. You do not run the agent as root. You can give the agent sudoers access but only if you want to do deployments where sudo is required. Most apps do not require sudo so you don't have to give the agent sudo access.
You also do not give distelli access to your code or package . Your code is uploaded to your S3 bucket directly from your laptop or dev machine and the service merely gets a bucket name and s3 key which it passes to the agent.
Congrats on getting a project shipped and taking this step to get more people using it. It's something most people never even accomplish.
The thing I noticed that I would improve upon is simply the blog. It's all about your product and its latest features, but it could be such a better channel for you to reach users and customers.
Open these posts up to all sorts of topics you know something about that your audience is probably also going through. How do I get better at: server monitoring, security, downtime, status communication, setting up DNS, mail, etc.?
Don't neglect helping me get better at being a system admin. If you help me get awesome, you'll have a fan for a long time. I'll be happy to check out products you're selling.
Kathy Sierra has even more on this topic. And it's brilliant:
Thanks for the kind words and encouragement. It means a lot! You're right about the blog. Its still new and I will work on opening it up with more topics or even trying to get a guest blogger or two.
Our biggest differentiator is that we do not run your servers like a PaaS would. You start and run your own server and distelli enables you to deploy your application and code to that server. We do not access, login or control your server.
edit: Also Distelli works with any server whether its a cloud server (AWS, Rackspace, Digital Ocean) or a private server (private datacenter, under your desk etc) and lastly distelli does not need your cloud credentials if you do run a cloud server
Nice job! I think it's great that you've got a MVP up and are seeking objective feedback. I signed up for the beta (michael (at) mherman (dot) org. Your product looks promising. You're solving a big problem. The teams feature looks very cool.
Your design could use a bit of work, but nothing to worry about right now.
If you need help with dev or design in the future, I'd gladly put some time in to a project like this. I can help in other areas as well. Contact me.
I signed up for beta and will provide feedback once I can spend a bit more time looking a it. And you should be proud of yourself for getting this far.
108 comments
[ 3.3 ms ] story [ 98.1 ms ] threadI don't want to deploy my code/application to "any" server. In fact, I want to deploy it to the smallest number of servers possible and then change that infrastructure as infrequently as possible. Time spent futzing with infrastructure that's not essential to my customer's experience is time wasted, after all.
And from your copy it seems like you're selling "portability." Once I settle on EC2, though, I'm going to be pretty-well settled on EC2, so portability does very little to benefit me.
Moreover, once I've settled on EC2 I'm quickly going to set up a deployment process. Let's say I'm using Rails + Capistrano for deployment. In a world where I need to switch urgently to another infrastructure service, I know I'll be able to do so with only minimal modifications to my Capistrano script. In any case, necessary changes to the deploy script will be about the same amount of work as necessary changes to the application code and I'm going to have to make those, regardless.
So, overall, the value this provides seems very minimal relative to the likely complexity it would add in other places.
Edit: Reading other comments, this is more like Capistrano-as-a-service it seems? That might be interesting, especially if it comes with process monitoring tools. The page really screams "portability" to me, though.
A tag line like "Deploy your application like the professionals" might do better to get that point across.
However, there's one gaping problem with it.
You seem to have a hosted "weird proprietary yaml language" master.
I don't want the headache of learning a new language, particularly not one with vendor lock in. If it is one of the above, tell me. If it's not, why the hell not?
One tiny nit on the logo, you should use hexagons instead of pentagons. Lots of hexagons fit together nicely. Pentagons, not so much.
When I sign up I'm attempting to test it out now, on "my time". When access is delayed by a month testing it is on "whenever I get to it time" and generally just falls by the wayside. Hopefully this is meaningful feedback in and of itself.
The only thing I really have to say is beware of carousels... I didn't even notice you had carousels until reaching the bottom of your 'how it works' page.
Mostly because marketing speak is often far more grandiose than reality...
"Easily Deploy your Code to Any Server".
Really? Any server? There are a lot of operating systems in this world.
I agree that it sounds too grandiose but I would love the opportunity to have you as a beta users and demonstrate that are claims are not marketing speak and smoke and mirrors.
I'm a developer myself and I don't like marketing speak.
At first glance I got a feeling that the website design is incomplete. The hovering on the menu seems a bit too sharp. I am no designer so I am not sure what the exact terms to be used are. I just think you should maybe put some work into the interface and it would look much more appealing.(I am just talking about the look and not the app itself). Good Luck.
Sign Up|How it Works|Documentation|Blog
And the Twitter follow button in the main navigation is really confusing.
Digging the concept!
However, this does a disservice to you and to me.
To you: You don't really know if people want to buy your product or not. Collecting email addresses is way easier that collecting money. It's also not nearly as exciting. Don't remove the option for me to just give you just my email address, but also let me give you money.
You'll know I really want your product that way. Also, initial customers are probably more forgiving that you imagine. Worst case scenario, you can just refund the money.
To me: Without the pricing page, I can't really tell what your product does. For all the description and "how it works" pages in the world, nothing really tells me what you are selling like your pricing page.
Companies tend to charge where they are adding value. If I can see what you are charging for, I can see where you are going to add value to my company. Are you charging per server, per deploy, per employee, per user? Without the pricing page, I don't understand what I'm buying.
Our pricing is still TBD, but its going to be a low price per server per month sort of model.
We'll update the site with a pricing page soon! Please email me and I can answer more of your questions in detail.
edit: Also see my comment about this below.
How would sidekiq/delayed jobs worker instances be deployed using a setup like this? I glanced through the docs section and didn't see that.
In a nutshell you'd run it just like you'd run any ruby or rails app.
Also the teams features make it easy to collaborate and see who change what and when.
Give point by point details about how what I am doing right now sucks. It make me hate my job, keeps me up at night, turns away customers, and loses me money.
Then, after you have convinced me that my current process sucks (and epiphanized with me that it was the best I could do at the time), go back though every point and tell me how you have fixed them.
I'll send you details later tonight with details on how to get set up.
You're selling a service though - I'm guessing your service will connect into the Linux servers directly (root access?) and manage everything directly. Obviously, that gives your service full access to both the package contents and to the servers themselves. That feels a bit risky - am I correct here?
You also do not give distelli access to your code or package . Your code is uploaded to your S3 bucket directly from your laptop or dev machine and the service merely gets a bucket name and s3 key which it passes to the agent.
The thing I noticed that I would improve upon is simply the blog. It's all about your product and its latest features, but it could be such a better channel for you to reach users and customers.
Open these posts up to all sorts of topics you know something about that your audience is probably also going through. How do I get better at: server monitoring, security, downtime, status communication, setting up DNS, mail, etc.?
Don't neglect helping me get better at being a system admin. If you help me get awesome, you'll have a fan for a long time. I'll be happy to check out products you're selling.
Kathy Sierra has even more on this topic. And it's brilliant:
http://businessofsoftware.org/2013/07/building-the-minimum-b...
edit: Also Distelli works with any server whether its a cloud server (AWS, Rackspace, Digital Ocean) or a private server (private datacenter, under your desk etc) and lastly distelli does not need your cloud credentials if you do run a cloud server
Your design could use a bit of work, but nothing to worry about right now.
If you need help with dev or design in the future, I'd gladly put some time in to a project like this. I can help in other areas as well. Contact me.