Pricing dilemma

A year back I was involved with a leading mobile apps company on an issue related to product pricing. The company developed customized mobile apps for business. At the time it had a staff of 20 programmers and reasonably successful – having on its customer list several top global corporations like cola companies, few leading banks, advertising giants and others. It had revenues close to USD 1 million. The company had identified 20+ software functions (routines) that were commonly used in most mobile apps. They had put these together into a single library that programmers could access from a central repository when working on a mobile app project. Examples of such routines included memory management, real-time authentication, camera control, text messaging within the app and so on. Use of this central repository of frequently used routines had resulted in 30% saving in programmer time, standardization and uniform quality across projects, shorter time to market and finally the monetary benefit.

The company saw a window of opportunity externally. They knew the mobile app business was growing at a fast clip with app vendors mushrooming all over. They were also aware of the trend of end customers developing mission critical apps internally. Both these customer segments would see a value proposition in the library if the company offered it. The company was at a critical point – thinking how to breach the psychological revenue barrier of USD 1 million. It faced fierce competition that had brought down margins from 80% to 25% in just two years. They thought the library was a ticket to new profit stream and improved competitive position. They were debating how to price and market the product.

However this meant a sea-change in the way the company thought and worked. So far, they delivered single project as per known customer requirements to a single known customer at fixed price. They did their best to deliver within time and budget. They priced their services at cost plus margin. Any delay ate into their margin. Selling the tool externally would involve selling a generic product to external customers whose size and number was unknown and uncertain. They had a hunch but did not know for sure the external customers would really see value in the offering. For example a tribe of software programmers take pride in and get thrill from solving tough problems. They would not care for such a product. A few team members even felt that their competitors would also acquire the library thus diluting company’s competitive advantage in the market.

The company sought answers to several questions:

1. Should they sell the library externally at all?
2. Should they price it on cost plus basis or some other method e.g., value based pricing?
3. What should be the list price of the product?
4. What should be the license structure i.e., kind of licenses they should offer?

The company made a set of decisions. I will share those in the next post. Meanwhile, I invite you to share your suggestions on the questions facing the company.

Mobile Apps pricing strategy

Sangeeta Patni

The art of being able to package libraries and selling a set of libraries as a Product is a tough one indeed. The packaging sounds perilously close to being labelled as a “Platform” or a “Framework” – one of the most difficult things to sell. Coupled with it is the fact that the company clearly sees developers as its target group, one of the most avidly wooed set of people from all tech companies. And for a company that is used to selling services – this is close to changing DNA midlife! I do not envy the entrepreneur at all 🙂

That said, the best thing would perhaps be to license the framework on a Per Dev User basis, based on the platforms (iOS, Android, BB etc) delivered on. This will give the internal IT team some kicks in building their software skills on the framework – along with providing Certification on the Framework, which will increase their pull on the developer community.
- ARUN SAXENA
  
  Sangeeta, you have an interesting point regarding treating the library
  as a platform. The company thought about both product and platform strategies
  for the library.
  
  If you look at successful platforms, few salient features spring forth. These
  are:
  
  The technology solves an essential problem. It has unique features that are
  hard to imitate. Yet, it facilitates others to add complementary products. This
  meant the technology was relatively open at the same time having intellectual
  property that allowed the inventor to have some control and ownership. It is
  important that it forces some dependencies between itself and the complementary
  products built on it. In business terms it must provide incentives for others to
  contribute and build offerings off it. Finally, a platform is predicated upon a
  large number of ecosystem members engaging with it. That requires huge amount of
  marketing and evangelization. In this context, the company had many challenges
  promoting it as a platform.
  
  For starters, there were 3-4 big competitors i.e., iOS, Android, Windows
  Phone and Blackberry (RIM). There promoters provided frameworks (SDKs) for
  developing apps on those platforms. The question was how to align with these
  big players?
  
  Second, the developer market was highly fragmented – consider the number
  of one-man shows in this business. Moreover, the developers tended to solve tough
  problems themselves. How could one build high momentum roping them into the platform?
  
  Third, what would be the business model? For one, what would be the
  incentive for the developers to come onto the platform? Other issue was how
  would the developers exploit the platform?
  The library was not just like other IDEs; it would have more direct
  impact on user experience. How would this come in the way of developers
  differentiating their product in the market (assume everybody was using the
  same library of routines).
  
  Some solutions company considered were –
  
  1. Get into OEM licensing with the big mobile operating system vendors. The vendors made the library part of the their SDKs. The pricing could be based on a fixed annual fee or per copy
  downloaded.
  
  2. Sell directly in the open market like a product. Go commercial open source (COS) – buyers with
  certain volumes would get full source code. That meant they could customize the code as much as they wished.
  
  More to follow. Thanks.
  - Sangeeta Patni
    
    Following this conversation keenly – all ears 🙂
Vinod Shintre

Best strategy would be to run a quick survey with existing target users & ask how much & what would they pay for. Select a alpha-beta pricing cycle but again its a thin line.
Sandeep Todi

Arun, there is no doubt they should sell the library. If there are more avenues to leverage your IP than what you can do directly, then why shut out those options?

I feel they should …

a) Offer a free version that’s got 80% of the common pain areas addressed. This gives them visibility and scale and allows them to acquire a large footprint of potential paying users.

b) Offer a paid version to independent app developers and corporate IT. This should have the complete feature set and include dedicated support.

c) The value should be 1/10th of what it would cost someone to develop something similar. If someone considers the cost of hand coding those repetitive tasks and the long term cost of ironing out bugs in that code, it should appear like a bargain too hard to refuse.
d) Licensing has many options, but I’d opt for a simple strategy to sell the licence with one year of free updates. Anyone could then update to the latest version at anytime in the future by paying an upgrade fee. I would choose this over a subscription/AMC model to keep it simple for the buyer, and minimize the cost of servicing contract renewals.