Show HN: I'm a single founder. Please review my bootstrapped startup
Published in 2013, this chronicle by @kt9 details the mechanics of building a profitable, self-funded business without venture backing.
Core Principles for Independent Builders:
Charging customers from day one acts as the ultimate filter for building software that solves genuine, high-urgency problems.
Keeping fixed overhead low and leveraging lean infrastructure allows founders to stay alive until market tailwinds kick in.
Small, repetitive improvements in customer retention and conversion rates yield massive returns over multi-year horizons.
Community Debate Themes:
The community focused on B2B customer acquisition channels, cold email vs SEO distribution, and balancing full-time employment with side-project development.
CATEGORY Bootstrapping & MRR →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 158 points
TOTAL DISCUSSIONS 103 comments
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.
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.
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.
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:
http://businessofsoftware.org/2013/07/building-the-minimum-bad-ass-user-some-unfinished-business-kathy-sierra-at-business-of-software-conference-2013/ ↗
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 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.
[1] http://refresh-sf.com/yui/ ↗