Thinking of building an app and listing it on the Salesforce AppExchange? This could be a daunting task, especially for the first-timers. The size of the app, what it does and a host of other characteristics of the app will determine the resources and level of sophistication required from the development team.

This blog breaks it down into three parts, Plan, Develop, and Publish. While we address details where needed, these blogs are intended to give you a good idea of what to expect at a high level.

As with any software project, the first thing you need to do is to define the scope. While it may not be possible to write down the exact specification/requirement at this stage, you will need to clearly articulate what you expect to get out of this app. Ideally, describe the app with all its features as you see them in the final version of the product, even though you may not be targeting to build the full version right away.

We will now go through a series of questions, and discuss possible answers and what it means for your app development project.

Free vs. Paid Salesforce App

Is this going to be a free app or a paid app?

Not all free apps are truly free. Be prepared to explain or demonstrate this to the Salesforce representative, they will want to know if there is any kind of monetization of the free app. If the free app has a back-end service connected to it, you may be subject to Salesforce’s revenue share agreement.

Native vs. Hybrid Salesforce App

How will your app be developed and deployed?

Native app: Will the capabilities/features of Salesforce be able to meet all the technical requirements to develop the product? If not, you will have to go to the hybrid path.

Hybrid app: You will develop a native “connector/interface” in Salesforce to connect with and consume the services provided by a back-end API. Often, ISVs have large investments made in developing stand-alone products. In such cases, it’s most efficient to leverage that investment and build a hybrid app that uses the stand-alone product back-end via Web Services/API. This, of course, requires that the stand-alone product has a well-defined API that can be used to integrate it with Salesforce.

Editions, Versions, Packaging

Does your app require features that are only present in certain (higher) editions of Salesforce?  Does a single version of your app’s features meet the requirements of all your target users or will you need to create different versions targeting different users? Do you have a Price Discrimination strategy that you wish to implement?

Answers to these questions will determine the complexity of the product architecture and consequently, the development effort and its cost. Having a well defined plan on how the app will be sold and packaged is critical to the success of the project. It will be best to get the sales and marketing team engaged to help with this part. We will discuss development and deployment considerations in subsequent parts of this blog series.

Integration Considerations

Is there a need to integrate with external apps/APIs OR expose a web service for consumption by external apps? Integrating with external apps will influence design, architecture, security, and scalability decisions.

You’ll need to create a list of all external APIs that the app will integrate with, including specifics of what exactly each app will be doing, what information from Salesforce will be sent to the external system, what will be received, connectivity, data structures, formats, etc. The more detailed, the better. The product architect will need this information to correctly design the system at an early stage.

Deployment Considerations

Will an admin user be able to customize your app? To what extent? Will the Salesforce developers be able to invoke features of your app via code? Which ones? What is the impact of exposing these features to developers? What safety measures do you need to implement as part of exposing these features programmatically?

Exposing a set of features programmatically requires a lot of thought and design work to ensure that all the dependencies are covered, and all use cases are taken into account. The product architect will need to clearly understand the extent of exposing app features as they will impact app design and development effort.

User Interface Considerations

Do all your app’s user interfaces need to be supported on all devices?

This is especially true for Visualforce pages. List all user interfaces and for each one of them, identify device support requirements, desktop, tablet, and phone. Certain interfaces may be restricted or not available on the phones, specifically, setup screens. “Heavy” interfaces optimized for desktops are also possible candidates for this restriction.

At the same time, there may be certain aspects of the application that are primarily targeted for mobile users, and hence will need special emphasis. All of these need to be addressed by the design/architect team early on to ensure smooth development.

Go-To-Market Plan

Do you have a plan that will let you get there soon?

The product owner and/or the sales and marketing team might want to attempt to release the app with ALL of its planned features. Resist that temptation. Take a good hard look at the features and come up with a list that will deliver an app that meets the requirements of a small segment of your target audience.

While this is tough, it will be best thing you do for the success of the app. Trying to build the entire product in the first release will most likely lead to scope, resource, and schedule issues risking the entire endeavor.

Cost-Benefit Analysis

Is it worth it?

If the app will be adding value to an existing service or product, you will need to evaluate the cost of building this app, its ongoing maintenance and also the resulting revenue share (takes away revenue from the main product/service) vs. the benefits of increasing customer;s switching cost, incremental revenue from existing customers, opening up an untapped channel (Salesforce users), etc.

These questions and considerations will help you with the initial planning of how to get your app on the AppExchange.

How to Get an App on Salesforce AppExchange Series

• Part 1: Plan (this post)
• Part 2: Develop
• Part 3: Publish

If you’d like a more detailed analysis, email us at customersuccess@appshark.com for a free no-obligation consult. AppShark is a Salesforce Product Development Partner with multiple apps on AppExchange. Having developed Salesforce apps for customers, our developers and consultants have the experience and expertise to help you with your AppExchange development needs.