Posts Tagged ‘business models’

A map of business models in the software industry

Recently I’ve been doing a lot of thinking about the different business models available in the software industry. While software companies sometimes assert that they have a unique model used by nobody else, all of them ultimately boil down to four basic ones: services, product centered services, products, and products distributed as services. All four of these are perfectly valid models with unique opportunities. The best way of showing the relationship between these modelsĀ  is what I call the Software Industry Model Map. Version 1.0 is seen below:

Software Industry Map
(Software Industry Model Map, version 1.0., license)

Here is a brief description of each model, including advantages and disadvantages:


This is the simplest business model and has the fewest barriers to entry. You build custom code for clients to do whatever they need. So long as you know how to code and have basic computer equipment, you can be in business. Many boutique web development firms operate this way.

This model is on cash basis: you do the work, tally the hours, then invoice the client. Barring cash flow issues (and deadbeat clients), you usually get paid a few weeks after sending the bill. While the simplicity of this model is appealing, there are several drawbacks:

  • Code reuse tends to be lower than other models.
  • You tend to get maintenance work, which may dictate the tools you have to use.
  • When clients request unpleasant or time-consuming work, you either have to do it or convince them to accept an alternative.
  • Cash flows can be irregular, unless you have retainer agreements in place.

Product centered services

This model is usually the logical successor to services (if it isn’t used from the beginning). While it tends to take more planning and investment than pure services, the revenue streams are greater. You also have a specific product you’re familiar with and can reuse to a degree. You can develop this product in house, or you can learn how to extend an existing product. Code reuse and standards are more easily found here than in pure services.

Although the most obvious implementation of this model is with “enterprise solution” businesses, some boutique firms create products to narrow in on niche markets. This model frequently employs significant numbers of non-programmers because the software itself may not represent the bulk of the value added. Despite high revenues, this model has some pitfalls:

  • Expenses tend to be high due to the wider array of expertise needed.
  • The complexity of services offered can lead to scope creep and unrealistic expectations.
  • Clients can still request unpleasant work.
  • Unless you’re developing your own product (which is more expensive), the whims of external software authors may hamper plans. Crucial features may disappear along with support for older versions.


Rather than doing custom work for specific clients, it’s far more profitable to build a product and sell it over and over again. The incremental costs of selling more copies of the product are negligible. Aside from providing support, maintenance costs are also close to nil. This results in an extremely high profit margin. When the product is marketed appropriately, the revenue potential is also great. Microsoft, Adobe, and Intuit are companies that have roots in software products. While financial rewards of this model are obvious, it also presents the highest barriers to entry:

  • Startup costs are staggering. Millions of dollars can easily be sunk into building a software product before the first sale is ever made.
  • Although you do not answer to the daily wishes of individual clients, the features you offer must be flexible enough for the majority of your users to accomplish their tasks.
  • Completing a software product does not guarantee that it will sell.
  • Software products are environment dependent: it can be difficult to test software under all of the configurations customers will have.
  • Bug fixes are distributed slowly and may not be applied correctly.

Products distributed as services

Developing a product is very expensive, but this can be offset early on if you offer the product as a service. The big advantage to using this method is that your customers receive the benefits of code updates instantly; code reuse and profits are inherently high. This method is also the most efficient at leveraging network effects: when people can easily connect through your service, your software becomes more valuable with little extra effort on your part.

Your customers usually don’t need any special environment to use your service, aside from a live connection to it. You have complete control over the code environment. Services also tend to have simpler interfaces or ones that are user defined. Data storage typically occurs on your end, making it trivial for users to change hardware on their end. Google, 37signals, and many other Internet-based services released over the past 5 to 10 years fit this model. Products distributed as services may appear to be very attractive, but they are not without downsides:

  • You must maintain the hardware where the code resides as well as network connections. When any of this fails, customers cannot use your service.
  • Your code has little or no access to the client’s hardware. Personal computers can easily handle an advanced calculation or data operation for one user, but the same action on your server multiplied by tens of thousands of users at once is not cost effective.
  • Revenue levels are lower than those of a pure software product. In exchange for reduced functionality, customers expect your service to be low-cost or advertising supported.
  • Although storing data on your server makes it easy for users to change their hardware, they lose control over the data. This is a problem for businesses in sensitive industries or users with security needs.
  • Users cannot keep old versions of your software. If you take away or change a feature they rely on, they must wait for you to either add it back or provide an acceptable alternative.

More analysis and examples to come…