In the age of the Internet, it is difficult for websites, web services and software developers to monetize the value they create. Most customers are extremely price sensitive and try to pay as little as possible for software or web services provided through software.

The prevalent business model is to provide a basic, ad-supported service for free and to charge for the full-featured service. Rates of conversion from the free to the premium service are generally low, and ads do not pay much per impression. As a result, such services are only sustainable if they reach massive scale quickly.

These economic constraints shape the software services we use - often not in a good way: Software that could run perfectly well as a standalone application is turned into a web service to funnel traffic past advertisements. Services that would work perfectly well for a small group of users are turned into yet-another social network, in order to advance scale through network effects. Companies put the interests of advertisers before the interests of their users, because advertisers are where the money comes from. User data offers additional revenue streams at the expense of user privacy. And software that caters to niche markets cannot be financed, even if the value created for its users would cover the costs of development.

Many of these constraints are not facts of life, but simply a feature of current business models. In this post I describe a radically different business model, dubbed Fund I/O for web services, that provides incentives for users to finance the development of software products and web services directly. This model is based on the Fund I/O mechanism, and provides one key feature: it gives developers and users a rational mechanism to communicate about price.

Key Benefits

Fund I/O for web services offers a number of advantages for both users and developers.

Advantages for users

• Users get access for the lowest possible price, that covers the cost of providing the service.
• Users can pledge how much they are willing to pay. If enough users pledge, the price of the service will go down.
• Early adopters receive a refund as the price goes down. Everybody pays the same price, nobody overpays.
• Users pay only for what they use. If a user ends up not using the service after they sign up, they won’t pay anything.
• Users have full cost control. They never pay more than their pledge for a subscription period, no matter how much they use the service.
• By supporting developers directly, users know that the company has the economic incentives to serve their interests over the interests of advertisers or investors.

Advantages for developers

• Costs are covered through revenues. No need to finance operations through equity or debt.
• Fund I/O is optimized for growth. Prices are set automatically to maximize the number of active users, while costs are covered.
• Customers reveal how much they are willing to pay for the service, providing invaluable market data.
• Fund I/O provides incentives for price-sensitive customers to support the service financially and stop free-riding.
• Developers can focus on creating value for their customers, instead of worrying about placing advertisements or maximizing profit.

Fund I/O for web services creates a playing field that is radically different from the current model centered around VC capital, ads, freemium services and massive scale. As such, it caters primarily to web services for which the current model is not a good fit. Fund I/O is a great choice for web services that:

• do not have the scale neccessary to support itself through ads or sales of premium features,
• cannot be supported through donations alone, or
• do not have the venture capital to support years of operations at a deficit.

How it works

Fund I/O for web services is around the following three assumptions about the behavior of the majority of users with regard to web services and software:

Users want to pay as little as possible. Here, the Fund I/O model subscriptions can be of tremendous value, as it gives users rational incentives to reveal their true valuation for the product or service. This is in contrast to a classical sales context, where users would understate their true valuation and, e.g., opt for the free tier of a service, even if the value they obtain from the service exceeds the price of the premium tier.

Users do not want to buy something they do not know. Most software products and web services are not commodities. They cannot be perfectly substituted. Instead it depends on the particular characteristics of a given software product whether a user will want to work with that software at all. Thus, users avoid making a significant up-front investment without trying the product first. However, even after a trial is over, relatively few users make a purchase. In short, discontinuities in spending turn away users. A simple solution is to adopt a simple rule: Charge users in proportion to their actual usage.

Users do not want to constantly monitor their usage. Hence the popularity of flat rate offers for all kinds of services. Therefore, users should be charged in proportion to their actual usage, but only up to a fixed total amount. This way, users have peace of mind, even if they do not pay attention to how much they are using the product.

Here is an example how this could work in practice. Suppose a company wants to develop an HTML5 web app. It needs \$10,000 per month for developer salaries. To keep things simple, let us assume that on top of that, additional hosting costs are \$1 per user per month of non-stop usage. However, the average user would use the app for about 30 hours per month, which amounts to average hosting costs of about 5 cents per user per month.

The pricing now happens as follows:

• Development cost are distributed equally among all users, according to the Fund I/O for subscriptions model.
• A user counts only as a “full user” when they used the web app for 20 hours or more in the current month. A user who just tried the web app for 2 hours would just have to pay for “one tenth” of the average development costs.
• Hosting costs are passed on to the user directly. This boils down to a rate of less than 0.2 cent an hour, with an absolute maximum of \$1 per month.

Suppose the web app has a small but consistent user base of 1,000 “full” users, 500 occasional users at 10 hours per month and another 1,000 users who just stop by and look at the app for 1 hour. Then the app would have a total of 1,000 + 500 * 0.5 + 1000 * 0.05 users, which amounts to a total of 1,300 “full” users. Distributed evenly among them, the development costs amount to \$7.70 per user. So, the 1,000 full users are charged \$7.75. The 500 “half” users are charged \$3.87. And the 1,000 “window shoppers” have to pay 77 cents each. Just opening the app and looking at it for a couple of minutes would cost less than 10 cents.

Now, suppose over time the service grows by a factor of ten, so that we have 10,000 full users, 5,000 half users and 10,000 window shoppers. Then the respective price would drop to \$0.77 + \$0.05 = \$0.82 for full users, \$0.385 + \$0.02 = \$0.41 for half users and 8 cents for window shoppers. Just looking at the app for a couple of minutes would cost just 1 cent. The tremendous economies of scale inherent in web apps are passed on entirely to users. Moreover, the Fund I/O concept of average cost pricing and refunds as prices drop mean two things:

• Users can pledge how much they would be willing to pay for the service, even if their pledge is below the current price. When enough users pledge, the price will go down.
• To compensate early adopters for their investment in the service, a part of the revenues can be passed on to them as a refund for the premium they paid early on. The golden rule is that within one subscription period, everyone pay the same price for the service, no matter when they join or how much they pledge. There can also be transfers across subscription periods, for example if version 1.1 of a web service builds on version 1.0, for which early adopters paid a premium.

Of course this is not the end of the story. There are many variations that can be used to tailor this protocol to particular use cases. (See this list of posts for more details on these variations.)

• To price-discriminate low-valuation from high-valuation customers, web services can offer tiered subscriptions where the upper tiers are tied to a higher base cost. The higher tiers can include dontations made in exchange for special rewards. The lower tiers can include an ad-supported free tier; however, as a free tier decreases the incentive for users to participate in the pricing mechanism, this is not recommended.
• Producers can choose the cost function such that they make a limited profit if the service becomes popular. * Stretch goals can be used to achieve specific growth targets and provide funding for additional features.
• The fact that prices drop over time can be used to create a smooth transition to a release of the software developed under an open source license. (See here and here for more on Fund I/O for free software.)

Conclusion

Fund I/O for web services is a business model that breaks with many of the conventions we currently take for granted in the internet economy. At the heart of the model is a transparent mechanism for users and developers to communicate rationally about price. Users actively shape the pricing of the web service through the very payments they make. Developers cover their development costs while reducing their dependence on advertisers and venture capital. Fund I/O for web services makes web services for niche audiences sustainable and at the same time provides them with a smooth transition to serving mass audiences if they become popular. Finally, Fund I/O offers a flexible toolbox that can be adapted to many different use cases.

Fund I/O offers a felxible toolbox of concepts for designing innovative business model, and it is just the beginning: There is plenty of room for disrupting the internet economy.