The different ways a service price can be structured will put pressure on the business owner to develop and improve that service in different directions. It will also put pressure on the customers to use the service in different ways. In some case the pressure is even such that the business will try to degrade the service, instead of improving it. For Reesd, I want to make a conscious choice where the created pressure both naturally pushes me to improve the service, and pushes the customers to make the right technical decisions.
Before Reesd, I was working on a hosted continuous integration service (hopefully that code will eventually be merged with Reesd). That was about one year and a half ago. I recall that is at that period that I kept thinking about aligning business values with customers values. What I had in mind was that some businesses' most obvious ways to make more money was, to some extent, to harm existing customers. Examples could be to make installing a software or upgrading it artificially more difficult in order to drive people to a hosted version of that software. I felt that "necessity" wasn't tolerable (and I changed jobs for this).
Often when developing a software product, the right decision, at least from a technical perspective, seems obvious. Still, a different, lesser, decision is taken. For instance any engineer can appreciate that an email server can interoperate with another email server, run by another organization. That possibility was a strong point of XMPP. Yet, new messaging services (sometimes based on XMPP) keep emerging without that ability, or existing services remove it.
Another example is found with telecom companies. They love to make a perfectly working technology more complicated so that they have more possibilities to place arbitrary restrictions and limit what customers can do. Previously customers had a lot of freedom to use that technology (e.g. Internet access), then later their provider started to limit specific type of content (identifying and throttling required additional work, compared to the initial technology). Then the customers are offered the ability to pay to lift those restrictions.
I think that those "obvious ways" to "improve" a business are actually more or less obvious depending on how you structure your offering and pricing. That is, depending on how you design your plans, it is possible to make appear better choices (than harming your service and customers) as those "obvious ways".
For instance, imagine selling computing resources by the minute. You hope that your customers will use a lot of them. If they use poorly performing software on your platform, that is good for your business. Then you plan to offer support for some software stacks (i.e. your platform makes it particularly convenient to use them). Which software stack should you offer first ? If it has a lot of potential users, that might be a good choice. If it performs badly, and thus require more ressources that you sell, that is even better for your business.
The above situation, from a technical perspective, is very sad: favoring poorly performing solutions and pushing your customers to use them. Now consider that instead of selling ressources by the minute, you sell jobs (e.g. running a test suite). In this case, increasing the number of jobs you can run in one hour is good for your business. It is also a good thing for your customers: they will get the results they want more quickly. In this case the obvious choice to improve your business is to really make your customers more happy.
I like to think of such a service and pricing as putting pressure to use and improve the service in a "natural" way. Your employees are happy to write an efficient service. Your customers perceive the effectiveness of your service and they also try use it efficiently (i.e. make their test suite fast). Finally, this is entirely compatible with the nature of a money-seeking business.
I don't think it is always possible to choose a service and an accompanying price structure that is naturally pushing both your business and your customers (and you technical employees) satisfaction in the same way, but I think it is worth having that idea in your mind and trying to align everyone interests.
The "natural" aspect of this approach is very interesting to me. Intuitively it seems to create a virtuous cycle. Indeed if your developers can strive to create a thriving service, everything is in place to make it even better. Consider again the example where an application installation steps are complicated but it is against the monetary interest of the business to make them simpler. Such a situation is actually madenning for a developer. It is against her craft. Not simply from a personal opinion point of view. This means that a new employee onboarding will also be more difficult. This means that automated tests are more difficult. This probably impacts the architecture of the software in a negative way.
For Reesd, I wanted to provide such a "natural" offering. The natural offering should favour good engineering practice, both within Reesd, and within my customer organizations. The usual way to structure pricing plans for hosting Git or Docker (or Mercurial, etc) repositories is to sell X repositories for €Y. With Reesd, I want to let you choose how you work, without applying negative pressure. In this case (although some people might actually disagree, depending on some projects), a customer will want to break a code base in multiple well-delimited components. Those components will receive their own namespace in whatever bug-tracking software or project management tool they use. They will possibly get their own tech lead or product owner. And they will get their own repository. In particular, due to the way Docker images are organized, it is very natural to have a lot of smaller repositories instead of a big "and-the-kitchen-sink" one, even for small projects or teams.
(As an example, I have made a few PostgreSQL-based Docker images: a primary server, two standby, some images to create backups and dumps, images to restore them, ... Since PostgreSQL is very rich, the images are actually very similar in content.)
From a sales and business perspective, it might make sense to offer plans with a fixed amount of repositories. From a technically-minded perspective on the other hand (and clearly I'm not a sales guy), this put pressure in the wrong way. This is why for Reesd I have decided to adopt a storage perspective on the pricing of repositories: plans are based on storage size. If you use a big image or multiple smaller ones, the price doesn't change. Importantly to me, you're completely free to decide on creating that one image or multiple smaller images based on technical merit alone.
All this doesn't mean it doesn't make sense to use a strategy where the principal factor is money. A business needs money and can choose to try to make a lot of it, fixing the non-ideal situations later (e.g. the difficult installation procedure). Nevertheless for Reesd, I want to make a different choice. Maybe I will not extract as much money as I could, as soon as possible from my customers. That's no big deal; I will try to come up with additional value that you'll want to pay for, and that I will love working on for years to come.