Is it possible/allowed to list an ISV app as a 'Free' and then make it paid for additional features?

Question

We are still starting up and 2700$ is a lot for us so we do not want to spend on listing an app which may not have enough potential.

We are thinking of listing an App with basic features, if it gets traction, we will add more features to the same app which will cost extra.

Can we list an ISV app as a 'Free' and then make it paid for additional features?

Additional details:

SFDCFox has detailed. There can be two packages(base and premium), 'base' package checks the existence of 'premium' package on the same org. 'base' can be free and 'premium' can be paid. https://salesforce.stackexchange.com/a/149360/3788

An App can be listed as free and then made paid(with payment of security review fees). However, it does not explain the impact on existing users of the app who downloaded it when it was listed as free. Convert a Free Listing to Paid, with Checkout

Answer 1

It probably depends on how you collect payment for those additional features. For paid apps there is also a revenue sharing component (currently 15%).

However, I did find this:

Does the revenue share apply to non-Checkout processed transactions?
The revenue share applies only to Checkout transactions, that is, any charges in your Recurly account linked to your AppExchange Publishing Organization (APO).

However, I'm not a lawyer and that isn't legal advice.

Based on the AppExchange Partner Program Policies (Currently linking to ProgramYear2019, which appeared to be current when this was posted). Interpret this section as you will:

As part of the ISVForce Partner Category, Partners may distribute free applications to existing SFDC customers. Partner’s distribution of free applications to existing SFDC customers does not require Partner to pay SFDC fees (other than Program Fees) for such distribution; provided, however, that an application is only a free application for the purposes of these Program Policies if the applicable customer can install and/or access and make full use of all of the features and capabilities of the application without paying Partner fees of any kind. A Partner application that integrates to or makes use of any application, service or other product for which Partner collects fees is not a free application. (For example, an application is not a free application if it is provided under a “freemium” payment model or if it requires purchase of another application from the applicable Partner.) SFDC reserves the right in its sole discretion and at any time to determine whether an application is a free application for the purposes of these Program Policies

From my, very non-lawyerly, reading it seems like it is only a free app if there aren't fees involved for using it. That middle section seems fairly clear that you aren't a free application when you start collecting fees.

---

With regards to what happens when an existing free listing is converted to a paid listing I've asked for further clarification via the Partner Q&A forum.

Answer 2

So, as Daniel Ballinger mentions in his post, the Partner Program Policies explicitly forbid you from making an app that is labeled 'Free' if there is intention of selling something to the Partner or the partner incurring additional fees after they've installed the app. Specifically this bit here:

(For example, an application is not a free application if it is provided under a “freemium” payment model or if it requires purchase of another application from the applicable Partner.)

However, that doesn't stop your company from making 2 versions of your app, one being a free version with a specific set of features, and another being a paid version (listed as such in the AppExchange) with extra features that aren't offered in the free app model. I've seen this done before without any issue. If you build it right, you should be able to maintain it from the same code-base also, but as two separate, distinct packages (free and paid versions).

If you want a real-world example of this, go to AppExchange and search for AddressTools, you will see that they have two listings: a free and a paid version.

Answer 3

I'm currently going through this exact process (AppExchange Checkout ISV going from Free >> Paid).

It's probably too late for the OP, but for others that come across this thread, this is what happens to existing subscribers to a free AppExchange app when the app is switched from free to paid.

1. App is listed on AppExchange as Free. Salesforce customers install app which may be licensed as Site Wide or Licensed Seats.
2. After some period of time and potentially several App updates later, the App developer decides to switch their listing to Paid. They pay the security review fee if they haven't already.
3. They switch the listing to Paid. Consequences for the current install base are:

• In the LMA, their license shows as Status=Active and Expiry Date=Does Not Expire
• In the AppExchange, the status shows as Trial Subscription
• If the App is installed as licensed seats (let's say 20 by default), and the subscriber buys more (let's say 5) through the AppExchange (for Checkout enabled Apps), then what happens is their total licenses in the LMA change from 20 (from before when it was free) to 5. If the subscriber had 'used' 10 licenses, the LMA will report 10/5 licenses used. The AppExchange reports 'Active' against those 5 licenses.

4. When the app is updated and the version bumped on the AppExchange, the existing clients that have it for free cannot get it from the AppExchange without having to take out a paid subscription. If, as the developer, you decide you want to continue providing it for free to the client, you can generate a coupon via Stripe (% off or $ value off) that you issue to the client. They enter the coupon during the checkout process.

I'll provide more updates if anything changes...

Answer 4

On a similar note to Morgan's suggestion - you could create a free app, and then later on a paid extension package. The latter package will require you actually pay for the Security Review.

Also, if your customers are comfortable with the extension package temporarily being non-Security-Reviewed, then you could charge them for the extension services without AppExchange being involved. This may give you an opportunity to get some revenue with which to justify the fee.

And finally, if your package is quite elaborate and jam-packed with features, you might be able to earn some revenue by providing the customers paid consulting services on how to set up high-quality customizations using your package.

Answer 5

I agree with all comments above in terms of whether or not you can advertise as free.

In terms of how you implement ... there may be more elegant solutions leveraging 2nd generation packaging. You could have separate packages in same listing and also use features to unlock 'pro' features:

https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/fma_best_practices.htm