How To Take That ‘MVP’ App Across The Line To The AppExchange

Are you curious why over 11 million installs from the Salesforce AppExchange have happened since its inception? Have you faced the same business challenge at multiple organizations? Have you ever said, “There should be an app for that?”

How To Take That ‘MVP’ App Across The Line To The AppExchange
Table of contents

If you answered “yes” to any of these questions, you might be ready to build your first app for the AppExchange.

This article will discuss where digital transformation product ideas come from, the differences between managed and unmanaged packages, and when one type makes sense.

This article will also cover how to transform your idea into an MVP (minimum viable product), find your first group of users, and prepare for and pass the Salesforce platform security review to launch your app on the Salesforce AppExchange.

Product ideas are everywhere

Often, ideas for apps come from everyday challenges end users face. These solutions can be for issues the end user solved at multiple employers throughout their career or a one-time experience that was very difficult to overcome.

Sometimes, apps are born out of the innovative technology work consultants do. As they spend time with different clients, they might experience the same challenges repeatedly. Once they solve an issue for one client, the consultant might look for a way to implement the exact solutions for other clients quickly.

Some of these solutions arise through using managed and unmanaged packages.

Managed Vs. unmanaged packages

Managed packages

Simply put, a managed package has its code builder hidden. The users of a managed package get all the package benefits, but they don’t have to worry about updating or accessing the code base for any reason.

You can think of a managed package as an app. Managed packages are typically what Salesforce ISV partners place on the AppExchange to sell and distribute to customers.

Managed packages are also fully upgradeable. However, to ensure seamless upgrades, specific changes (such as removing objects or fields) can not be made.

Some other features of managed packages include:

  • Unique naming of all components to ensure conflict-free installations
  • Versioning support for API-accessible components
  • The ability to provide patches for previous versions and seamlessly push updates to subscribers.

Unmanaged packages

Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the essential components needed for an application. Once these components are installed from an unmanaged package, they can be edited in the organization they are installed in.

While unmanaged packages can give you a headstart in building a solution, remember that they aren't upgradeable and need reinstalling once an organization upgrade has occurred.

Important differences

At first glance, you might think unmanaged packages are superior because – as the app’s end user – they are free to use. However, if you’re looking for an app that will be constantly developed, improved, and supported by its creator, the managed package should be your preferred choice.

From the viewpoint of someone building apps, while the unmanaged package takes less time and effort to develop, it doesn’t carry the Salesforce stamp of approval from the security review that the managed package does.

If you want to sell your app eventually, you’ll need to pass the Salesforce security review to list the app on the AppExchange publicly. Before you can even reach this point, you must determine how to productize your idea for user adoption.

How to productize your idea and create your MVP

The first step in creating a software product is to determine what functionality and features are the ‘bare-bones’ – the minimum criteria necessary for the product to showcase its potential benefits to those who would use it.

Once you have developed this set of requirements, you have essentially created your minimum viable product (MVP). This process is usually done in-house with your company's product developers and testers. What you are building becomes your alpha version.

The primary purpose of an alpha version is to identify bugs and features that are not functioning as intended. Think of this as your ‘pre-release’ version – unavailable to people outside your organization.

Once you have worked through most of the issues identified in your alpha version, you’re ready to move forward with a beta release. This is where you are prepared for someone outside your development team to take your app for a test drive. 

Hopefully, along your journey, you have talked to some companies about your idea (your product) to help validate that your product will meet the needs of a gap identified in business processes.

You will also gain some interest from these companies in becoming one of your early (beta) test customers to install the app and put it to use with real-world scenarios.

Congratulations! It’s time for a celebration – you have a product being used by a customer. Now it’s time to scale your app for the masses (and public signups).

Get ready for the Salesforce security review

The security import review process helps identify vulnerabilities that hackers, malware, or other threats can exploit. The Salesforce security review team tests your cloud solution using threat-modeling profiles based on the most common web vulnerabilities. The review team essentially attempts to penetrate the defenses programmed in your solution.

Their goal is to extract or modify data they don’t have permission to access. Understanding what issues are scanned helps you prepare your application for the security review.

Prevent secure coding violations

All solutions published on the AppExchange must meet the exact security requirements. Some of the more common secure coding violations include:

  • Loading JavaScript files from third-party endpoints: Avoid dynamically loading third-party JavaScript files from content delivery networks (CDNs) in favor of loading code from your package's static resources folder.
  • Running JavaScript in the Salesforce domain: JavaScript code from pre-built reports and different vendors can run in the same origin. Vendor JavaScript code is sandboxed to prevent interference. Don’t break out of a sandbox or run code outside your origin. Use Visualforce, Aura, or Lightning Web Components as they run in the proper origin.
  • Exposing private data when debugging: Logging sensitive data with debug statements in a production environment is a security vulnerability. Redact the data or omit it from the logs.
  • Using sample code in production: Sample code should only be used as an educational tool in preparation for developing your application. Try to write the code yourself, and avoid copying code from sources you don’t directly control.
  • Disabling Lightning Locker: Lightning Locker is a critical security feature for Lightning code. It provides component isolation, allowing code from many sources to execute and interact using safe, standard APIs and event mechanisms. Be sure to enable Lightning Locker for your AppExchange packages containing Lightning components or applications.
  • Securing communication: Ensure your custom object solution is accessible only via secure connections, such as SFTP and HTTPS. Don’t use HTTP and FTP protocols that don’t encrypt the information that flows over the internet.

Prepare to launch your app

You’ve just received notice that your app passed the security review. Awesome! Now you’re ready to launch that app, right? It’s not that simple. Salesforce will want to review and approve your business plan first.

The business plan gives Salesforce real-time insights about your company and the app you’re building. It helps them verify that you meet their standards for ethics and integrity. 

Salesforce must approve your business plan before you can launch your app on the AppExchange for list views. If you’re new to the AppExchange Partner Program, you can sign your partnership agreement with Salesforce after they approve your business plan.

Steps to publish your app on the AppExchange

  1. Connect a packaging organization to the comprehensive dashboard publishing console
  2. Create or edit your provider profile
  3. Create or edit your AppExchange listing
  4. Add a business plan to an AppExchange listing
  5. Make your AppExchange listing effective
  6. Select an installation option
  7. Register your package and choose your license settings.

Now you are ready

Launching apps on the AppExchange can lead to market leader gains by helping other companies:

  • Increase their efficiency
  • Spend less time utilizing manual, outdated processes
  • Improve security and decrease risk.
Have you considered the key features of the app you want to launch? There’s no time like the present to launch your app to the Salesforce stars and beyond.