Software Products vs. Services: Are You Making Money While You Sleep?

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Software Products vs. Services: Are You Making Money While You Sleep?


I think that deep down inside the soul of most software developer/entrepreneurs is a desire to build that killer software product that sells millions of copies.  This is not surprising.  Once the software is written, it doesn’t cost much to deliver it to customers (and in cases like SaaS, it doesn’t have to be delivered at all).  Business and finance types would label this as a business model with high gross margins (as the cost that goes into actually reproducing/delivering the product is very, very low).  I’m much more simple minded and would call this “Making Money While You Sleep”.

This is one of the essential differences between a software products company and a software services company.  Software services can be loosely defined as any activity involving the creation of software that is done for a specific situation with a relatively low level of leverage and reuse.  Stated differently, you’re selling a service (once again, I demonstrate my uncanny knack for the obvious).  To make software services revenue, there’s generally work involved.  Every time.  Though you can certainly increase your billing rates or the size of your fixed-bid projects, there are few software service companies where you are making money when you are not working.  It generally doesn’t work that way.  That’s why I love products companies.  They’re much, much riskier – but the upside is much higher.  You really can make money while you sleep.  (That’s assuming you get much sleep in the first place, but that’s a topic for another article).

This high profitability is also why many companies that start out as service companies decide to try and convert to products companies.  But, based on the high rate of failure of these kinds of “conversions”, this seems to be relatively hard to do.  Most software service companies have a hard time “productizing” their business and creating software they can resell.

Here are some of the reasons why I think this is so hard:

Why It’s Hard to Switch From Services To Products
  1. Customers Want To Own The Code:  If you’re engaged in a software contracting project, chances are very high that the customer wants to own the resulting intellectual property.  Most contracting agreements transfer the rights to the resulting work over to the client that paid for that work.  As such, without a special provision, you can’t reuse or resell that code.  If customers are unwilling to let you retain all or partial rights, any work done is essentially locked into that customer project.  There’s no product for you to (legally) resell.

  1. Code Is Too Client Specific:  When doing software contracting work, the client is often very specific about what they want the software to do.  The more specific the end result, the more unlikely it is that you’ll find another customer that can use the same product.  It takes careful planning and design to ensure that a resellable product emerges from a custom development project.  This almost never happens by accident.  Also, it’s much more expensive and difficult to try and take what was a custom development project and then later try and morph into something other customers will pay for.  It can be done, but it’s not easy.

  1. Different Tradeoffs:  Software development is often about a series of tradeoffs.  When working on a product, the end result is an outcome of a series of choices the development team makes about how the product is implemented.  In a software products company, the team is usually good at making the choices that are optimal for creating a packaged product.  They do things like keep “custom code” out and implement rules engines and templating mechanisms and domain-specific scripting languages.  The idea is that an investment is made in the right areas in the short-run, so that the product can sell better in the long run.  On custom programming projects, the team makes a different set of choices that are optimal for getting the project finished on time, within a certain budget and that meets the business requirements.  Rarely is there the opportunity to invest “for the long term” nor does it makes sense to make investments so the product can be used at another company.  There’s no incentive for the company footing the bill to pay for these features.

  1. Lower Capitalization:  One of the best things about a services company is that there is much less risk involved.  Once the engagement is finalized, you can be reasonably sure that you’re going to get paid based on hours spent or milestones reached.  There is no large investment required to first build the product and then find customers to pay for it.  You’ll often have a customer commitment to pay you before you do any work.  Though this is great for services companies, it’s easy to get used to this and hard to break out of the habit.  When you try to switch to a products company, the financial needs of the company change dramatically.  All of a sudden, you need to work without anyone guaranteeing payment.   It’s tough to make that transition.

  1. Products Are HarderWhen writing software for an individual customer, life is pretty good.  First, you have a financial commitment (as discussed above).  But, you also have requirements.  So, you’re not forced to come up with what the product should do – the customer paying you generally has an idea of what they want.  In a products business, you don’t have this luxury.  You have suspicions of what future customers might want, but it’s never crystal clear.  You may even ask potential customers what they want, and they’ll tell you, but the answers are rarely as accurate and thoughtful as when the customer is writing a check up-front.  And finally, the underlying code itself is usually much more complicated in a products company.  In a custom programming project, you generally know a lot about the environment that the software will run in.  If you’re building a software product, you may need to create software that will (gasp!) run on computers other than your own.  Unless you’ve ever written code and been forced to get it to run on someone else’s machines (or hundreds of machines) it’s hard to understand how difficult this is.

  1. Team Selection Is Different:  Chances are, if you built up a software services company, you hired people that would be good at doing custom programming jobs.  Sure, you’ll hire good programmers (doesn’t everyone?) but often they are different programmers than the one’s you’d hire for a products company.  Since the risk is so much higher for a products company, it’s life-threatening to hire programmers that can’t create working software and meet a release date. In the services business, hiring mistakes are painful, but not always fatal.

Summary Of My Point:  It would seem that writing software should be a relatively consistent process (hire great people, use workable methods, etc.) regardless of whether you’re building it for a services company or a products company.  But, a software services business is very different from a software products business.  Different team, different financing, different decisions, and different goals.  It shouldn’t be that surprising that few companies can make the transition from services to products.

In a future article, I’ll make an attempt at identifying some ways to increase the chances of success if you’re looking to make this kind of transition.  It’s hard, but it’s not impossible.

Posted by on Thu, Jul 20, 2006


I believe that Oracle was one company that converted from a services company to a products company. Seemed to work out pretty well for them. I believe their client was originally the Government (CIA or NSA or FBI or something), and funding issues killed the project, so they got to keep the code.

Whenever I do contract work, I always keep a look out for ideas to use for my first product. I get to learn from their mistakes without actually having to experience them myself. The product that I'm building right now is similar to a product that I was contracted to help build last year. Subsequently, I know what works and what doesn't, and for the first part can code out of my memory and not have to worry about making architectural decisions, because I've already experienced the decisions before and know which outcome was the best.

I don't think, in this situation, there's much to be worried about, IP-wise, because I'm coding everything from scratch, and while things are similar, absolutely nothing is identical. In this case, the correction of past mistakes makes the end product both significantly better and significantly different. There might be a trade secrets argument to be made, but at least in my situation, there's nothing that wasn't painfully obvious once you examined the problem domain.

posted on Thursday, July 20, 2006 at 10:14 AM by

Excellent post! I think you hit it bang on.

Point #3 about tradeoffs is my favorite. The different constraints involved between services versus product influence the dozens of tiny tradeoff decisions you make when building software. For example, the deadline is often more important than "doing it right" for a services oriented build, so you tend to take shortcuts.

I've also found that it is difficult trying to inject Agile practices into organizations when you are a beholden to the client, even when the goal is to provide value faster and build a better quality product.

posted on Thursday, July 20, 2006 at 12:25 PM by Gavin Terrill

In my line of business I see the issue of #3/tradeoffs come up often. A common trade off that can be made is the choice of software licenses for the system you are building. Work done on a consulting or services gig may give you wider range of license choices (e.g. GPL) that may conflict with IP considerations for a typical Product company.

I see this come up when companies decide to build out a product around the work they did as a services and consulting company and they find that will be in violation of the licenses they agreed to long ago if they go the proprietary software route.

posted on Thursday, July 20, 2006 at 2:00 PM by Jeff Luszcz

I recently discovered your site and have to say every post recently has hit home in so many ways. Thanks for a great article.

posted on Thursday, July 20, 2006 at 2:21 PM by Chris

Very accurate.

I can attest to the great difference in a programmer's perspective between programming for one customer vs. programming for many customers.

Software given to hundreds of customers must do what the customers need and must be very reliable. The developers have little chance to tweak the system at hundreds of locations. It must be correct and useful when shipped.

This concept is not obvious to programmers I have seen switch from one customer to many customers. You will not be able to babysit the system at each customer's site.

Everyone needs to work in a successful product-for-sale development environment for a few years to gain a wide perspective.

posted on Thursday, July 20, 2006 at 3:57 PM by Dave

We are small software company which does mainly services but we also try and do products, usually they don't have anything to do with the software that we write for services but may be inspired by it.

We try and fund the product development from the money that comes from services - although services always get priority as that is what brings in the money. We have had a succeesful product which has been bought by several National Health Service Trusts in the UK. We are working on another at the moment.

Our products are always web-based (with maybe a mobile element) which means we don't need really need to worry about making sure that they work on a particular machine. Also, depending on the complexity, the products do require varying degrees of support. Our goal is to produce a simple but very useful web-based product where we don't do anything but get partners to sell & support!

Thank you for an interesting read.

posted on Thursday, July 20, 2006 at 6:33 PM by Zahid

Informative Post. 

posted on Saturday, September 27, 2008 at 3:22 AM by Rahul Bhagat

Comments have been closed for this article.