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
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.
Source: I run a few production backend services in Python. Mostly to Debian boxes.
No matter what your product anticipates, it doesn't anticipate all the things I do, in fairly boring applications. I compile my own Python. I install postfix for some applications. I install a kernel module that increases the Linux entropy pool. You have not anticipated my set of problems.
What this means is that no matter how much great stuff your product brings to the table, I bring just as much, if not more, configuring your product and designing a deployment solution around it for my application.
If your product isn't open-source, that's a non-starter for me. Because now I'm worried that I could spend a lot of time configuring the product, and not being able to add that one feature that I need. I'm not sure if you can run a business with an open-source deployment product, but I know that I won't ever use a closed-source one.
Do a better job of explaining how these apps run. I took a look at your sample manifest files, and it wasn't clear to me if you are installing nginx or something? Or if you intend the apps to be daemon-like? So create a page that explains, in words, how to deploy a daemon-like app and how to deploy a webapp, and who is responsible for installing the web server and editing its configuration file(s) (do you clobber them?) and what web server it is supposed to be.
Finally, add a docker.io example. It's not production ready, but it looks like it's designed for people like me who have deployments involving heterogeneous payloads. I'm going to move to it eventually, so if I was to switch deployment stacks I would want good support for it.
All your points are really great! I do need to work on writing additional docs / examples of how specific use cases would be handled.
Also you are correct that I have not anticipated your set of problems and I would love to get some time with you (phone / email or chat) and learn what your problems and pain points are around deployments and figure out if distelli is a good fit.
Distelli can be used to automate compiling a new python on the server (eg. I already have an example where NodeJS is built from source) as well as installing postfix or a kernel mod.
Lastly having an example that integrated with docker.io is a great idea. I'll add that to the list.
Thanks for your feedback and please contact me if you're available to share details of your pain points around deployments and help me improve my product for you.
>If your product isn't open-source, that's a non-starter for me. Because now I'm worried that I could spend a lot of time configuring the product, and not being able to add that one feature that I need. I'm not sure if you can run a business with an open-source deployment product, but I know that I won't ever use a closed-source one.
One can certainly provide an open source software which is not free software and illegal to redistribute. I can't see how that's detrimental to business. E.g. you can download the source code but you can share it to anyone.
Not really. Well, you can of course do that but you can't really call that "open source". "open source" has a set meaning that a lot of people spent a lot of time building the reputation of. http://opensource.org/osd-annotated
I'm not just being pedantic; this matters because if Distelli advertised itself as "open source" and I invested time into it then I found out that they didn't allow me to redistribute my amazing changes or to see my friends brilliant changes I'd be really pissed off. It would mean there was no scope for building up an alternative ecosystem that wasn't under the control of Distelli and thus I'd have no real freedom.
For what it's worth (ie. not much, I'm probably not your target market), I agree with drewcrawford - If I'm looking at this kind of tool freedom is important to me and I'll check the open source options before checking the closed source ones.
I actually thought of that when I wrote my comment, but I wasn't sure if open source only meant the open source definition by the open source initiative. Apparently there's no "access to the source code" meaning if we are to believe Wikipedia.
Therefore there's three possible cateogories: closed source, open source and 'access to the source code but no free license'.
> open source only meant the open source definition by the open source initiative
Some people will argue about that point and say it ain't so, but you've seen what I think about that :-)
> 'access to the source code but no free license'.
I've never seen a good term for that but some big names do it - Atlassian used to do it with JIRA and Confluence (don't know if they still do). It's not a bad thing to do - it's just not Open Source.
Never heard of one. That sounds a bit unworkable to me tho - where would you draw the line? "I fixed your indention. In every file.". And if the parent company could control who got the original source, they could still shutdown alternative uses and thus maintain control.
Part of the central definition of open source is the users freedom; which means the producers have to give up some control.
You either go full Open Source and accept the potential loss of control or you don't (in which case be honest and don't call it that).
We don't have any custom python build. The distelli manifest just runs virtualenv and then pip to install dependencies from the requirements.txt file. Here is an example:
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?
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.
This might be the second time I've said this in two days but...
So it's a git post-receive hook that parses a YML and starts your app?
In all seriousness though there have been a lot of businesses that are evolving out of this relatively easy to do push-to-deploy mentality. The ability spin up new servers on demand is kind of nice but ultimately doesn't save me much in the way of overhead when I can already set up a new AMI with the push-to-deploy mechanisms already built into it with just a few clicks. Why should I use your product when I can set up the same thing manually in under 10 minutes?
I applaud your effort and I also think you've done a bang up job at packaging it and I really like that you support so many hosting environments (that is your key differentiator here) but I hate to see too many people dump a lot of time into heroku-style deployments. This was a solved problem even before heroku came around and it seems many of these new variations are just saturating the market which drives down the value.
Although having said that, I'll be honest, I'm very jaded on this topic. Also I'm not your target customer at the end of the day because I have a decent understanding of how this works behind the scenes having built similar deployment mechanisms into just about every project I've worked on in the last 4 years manually.
My advice is that you need to differentiate yourself with up front feature based value. Your compatibility with many hosting providers is a really nice feature, but all it gives me up front is the confidence to know I can move to a cheaper competitor if I don't like how it's going. Focus on some upfront feature based value differentials and I think you'll do pretty well in this market if you focus on private enterprise.
As a follow up thought around this market perhaps the saturation is a good thing in the long run. Heroku definitely over charges, so having thought about it a little more I'll say I hope more of these come out and do a really cohesive job like this one is. It'll normalize the price over time and give more affordable options to the masses.
I realize this isn't a direct review of your product, but there are a couple front-end things you might want to take a look at.
Concatenating/minifying/compressing your JS files on the home page would speed things up a _lot_. If you have web inspector open, you'll see 55+ HTTP requests just for the landing page. If anyone is trying to view your site over a mobile network, especially those that pay for data or time, that could really hurt.
Also, unless there is a specific reason you're doing it that I'm not seeing, I would really recommend getting rid of the @imports in your CSS in favor of just adding more <link> tags; or better yet, go with my last suggestion and compress them. You could even just copy and paste the code into a tool like this[1].
Congratulations on shipping! I'm working on my own bootstrapped, single founder project right now and it's inspiring to see others releasing their products.
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.
I'm not a web dev, so I'm no help on that side, but I noticed something odd/wrong(?) about your main page:
When I scroll all the way to the bottom your footer bar appears (with your Facebook and Twitter icon/links). The footer then disappears if I don't move the cursor for a second or two. This happens on Firefox, Chrome, and Safari on my Mac.
It's kind of jarring for the footer to disappear when I didn't knowingly do anything to make it disappear because:
1. it disappeared
2. the rest of the page moves when the footer disappears.
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.
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
Nice and simple. Slow down the fading text. Consider a carousel. I know they're cliched, but people understand them.
Edit: Too much text. Show some screenshots. What are the benefits? Weird logo. My brain spent too long trying to piece it together, which bothers me from a design perspective. Having the logos of your integrations (like AWS) is great!
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.
Just a minor styling note - the black background on hover behind the twitter button is not attractive - at least to me. And, from a consistency standpoint, is not the same height as the rest of the menu options. If you keep it, at least make it consistent.
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
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 idea of being able to deploy on bare metal and to the cloud with the same config scripts. At least that's what I'm understanding from it. Correct?
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.
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.
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!
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.
Hi, Can you send me an email at rsingh@distelli.com and I'll set you up with an account. We have a large backlog of requests and I'm unable to connect your HN username to your email address.
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.