roy

This is such a timely article. (emphasis mine)

Why Build a Services Business in the First Place?
There are at least two types of tech services businesses in my mind:

1. Service as a bridge to a product business - One of the best ways for young startups to finance their business without any dilution is what I call "customer financing," which is mostly only possible in businesses that target businesses rather than consumers. Customer financing often comes in the form of your company agreeing to build a product with a "sponsor" customer or two and helping them with the rollout / implementation. Often in this strategy you end up giving them the product for free and bill them only services fees. You own the IP you create.

The benefits for the customer are: a mostly custom-built product addressing one of their internal needs, the focus of a very talented young startup focusing on their business need & free product - potentially for life.

The benefits for you are even more clear: you get to build a product raising significantly less external money (if any at all) and therefore no dilution, you get a customer who will help you figure out the real requirements for your business and you have your first real reference client lined up, which should help with future funding and with future sales.

If you set out to build this kind of business you just need to be sure you don't become a permanent consulting business by default. The "customer-financed" type of tech service business is never frowned upon by VCs - unless you've been doing it for 2-3 years with no product business to show for it, by which point they assume you're the second type of services business.

There's another reason why a product person would want to start off in services: the overhead for creating a viable engineering/product process is significant. You've got the process costs: technology decisions (what stack do we use?), defining process for bug tracking/project management, and figuring out how communication will work (for remote workers). For the most part, Agile sets a nice framework for this, but you'll still need to tweak to serve your team. Don't forget people costs: training and salaries. Ramping up a developer takes at least a month - expect this to be even worse if you're bringing on a bunch of people on board for the first time. 

The past few months at rykorp, I've been making the investments necessary: we're now getting to a point where things are getting more automated and less involvement is required from me. I've been lucky to find fantastic developers who require little management - and now the product process is getting less burdensome for me. Of course, my clients are the first to take advantage of this: but soon I'll be able to leverage it internally for rykorp products. 

Although the product business is a huge one, I am also working on rykorp because I strongly believe in providing services for small businesses: there's nothing like working on a critical project for a nascent business and watching it come to life. 

I expect by 2012 to see a 20%/80% mix of product/service revenue; I'd be perfectly ok with that mix, since my goal for the services business is to make it as hands-off for me as possible.