It's been a year since my original Show HN post announcing Server Check.in, so I thought I'd post a reflection after my first year running the service.
Server Check.in is an inexpensive website uptime monitoring service that I started out of my own need—if I had no users, I'd still keep it going. Fortunately, there are enough paid customers to keep me interested, and I've learned a lot from their feedback.
I had a good initial batch of signups after the announcement post on HN, and some other posts on Reddit, Low End Talk, and other forums. These early customers gave me a lot of feedback, and some suggested fairly major revisions to the service. It took a lot of discipline early on to make sure I only worked on the most valuable features first.
I decided early on to focus on stability, scalability, and performance before working on some of the requested features. This has paid off many times, as I have not yet had to revisit Server Check.in's architecture and basic functionality since a couple months in. The distributed Node.js-based server checking is working very well, and the master app server running Drupal with PHP/MySQL (which runs this blog) still has plenty of room for growth.
Below are some of the major lessons I've learned in the past year; I hope you can learn something from my experience.
1. Your priorities are not your customer's priorities.
This is a continual struggle. I have some pretty neat features I'd like to work on to make the site look and function better—but most of the features my customers (both existing and potential) need are features that are more invisible or are a little less fun to implement. I find that if I develop with in a tick-tock cycle, where I develop a feature I want, then one a customer wants, I keep the development interesting, and keep my customers happy.
2. Sales is an uphill battle (for a developer).
I understand why sales people seem to be pushy—it takes a lot to convince some people that a product would benefit them, even when they already know it. Especially with for-pay services, you need to make a hard sell to get most of your customers. (This assumes you have a good product in the first place, of course!).
I'm a developer. I like creating cool things, and I don't like 'wasting' my time selling these things. The reality is, though, that development is meaningless without sales, and time spent getting new customers is never wasted.
3. Contributing back to OSS improves you and your code.
Not only does contributing back (patches, documentation, testing, modules, etc.) a Good Thing™ in general, it also helps you build rock-solid components. Instead of spending an hour on a bit of code and coming up with an inflexible solution, you'll end up with a flexible, stable, and much more useful tool or solution if you decide you want to contribute it back to a community.
I don't do sloppy work in any of my projects, but I am especially thorough when I write code for an OSS community. Through my work on Server Check.in, I've been able to supply a Node.js module, some Drupal contrib module patches, and some blog posts on the process of using different OSS platforms together to build Server Check.in.
Finally, if I hadn't been following best practices for the different coding communities in which I participate, I would not have as secure of code, almost complete test coverage, or a highly organized infrastructure.
4. Keeping a good work-life balance prevents burnout.
In the past, some of my side projects became burdens due to the time I devoted to them, and my excitement for them fizzled after a few months. Most weren't profitable anyways, but I learned this: if you spread yourself too thin, you will become a lot less effective at the things you do. You only have enough bandwidth for a certain number of things.
I develop Server Check.in and other projects in my spare time, and I keep my priorities straight: family first, full-time job second, side projects third. I still ensure my side projects are reliable (Server Check.in has had more than 99.9% uptime this year, as measured by Pingdom); but I split my time in a way that keeps me sane. This helps everyone to whom I have an obligation to serve—wife, kids, co-workers, and customers.
5. Experimenting makes you a better developer.
Without Server Check.in's HTTP request scaling issues, I probably wouldn't have spent much time learning Node.js or learning how to code for asynchronous functionality. I went from being able to check a few hundred servers per minute to being able to check thousands (and more, by simply adding more Node.js check servers).
I also learned (and have adopted for other infrastructure needs) Ansible after realizing my hacked-together shell script deployment strategy wouldn't scale past a few servers. Now instead of taking an hour or two to get a new server spun up, I can have one in a couple minutes.
Finally, I've worked quite a bit on Stripe and Twilio integration, and now know parts of their APIs pretty thoroughly. This has already helped me in my current full-time job, and will continue to pay off—both literally and figuratively!
You aren't allowed to take risks or go off in crazy new directions in most jobs (especially in the 'enterprise' or corporate arena). Flex your development muscles and increase your enjoyment of developing with a side project or two. Who knows? Some of the things you learn might become extremely valuable for your next job—or help you in your current one.
6. It's harder than you think to build a simple tool like Server Check.in.
If you're building a one-off utility to check whether a server is up or down, for a few servers, and you're the only one that will view this utility, it may be simple. But add in historical tracking, latency monitoring, SMS and email notifications, thousands of concurrent requests, a user and billing system, and other bits and pieces, and the project is no longer as simple as it seems.
Many developers (myself included) think to themselves, "this sounds really simple—I'll just build my own". Almost always, it takes more time than you'd think to get everything running. What is your hourly rate? If you're working on a project for 12 hours, at $70/hour, was it really worth the almost $1,000 to have a product that isn't as good as one you could've paid for at a fraction of the cost?
Sometimes it's worthwhile because of point 5 above—but other times, what's the point? Don't waste time on side projects that won't hold your interest. Often paying for something or using an open source application that fits most of your requirements is better than spending a lot of time on a bespoke application.
These are just a few of the lessons I've learned. I could probably think of many more, but I need some material for next year's retrospective! I hope something you read here can help you when you're deciding what to do next, or how to improve your current projects. If you have any more questions, please let me know on Hacker News or in the comments below.