Getting An App Listed On The AppExchange

I opened up my trusty Macbook Pro and headed over to the collection of articles and Trailhead resources I’d found that described how to set up and get started with SFDX, Salesforce’s collection of features, APIs, and tools that help developers do their stuff as efficiently as possible.  

Step by step, I completed the Trailhead modules and before long I was creating Scratch Orgs, pushing and pulling source code via the Command Line Interface (CLI), running automated tests, and turning my coded creations into neat packages ready for listing on the AppExchange.

This was two years ago and now I’d like to share with you what it takes from having done no Salesforce development to creating a successful app on the AppExchange. Why do I want to tell you this? Because I’m super impressed with the whole process and there isn’t enough out there that describes the end-to-end journey and how low the barrier is, to anybody who has some experience of programming.  

This isn’t a step-by-step “How To” article though. That is covered by the AppExchange folks here and here.  This is more of a “look, if you’re a developer who is thinking about branching out, this might be the thing for you – it’s not super hard”.

Minimum Person Requirements

In my past life, I was a software developer with experience mostly in scripting languages like ruby, python, and a long time ago, Coldfusion. My SQL and understanding of relational databases were pretty good. 

In the years after I was a developer, I managed software and agile teams and later led marketing and operational teams. So I became a high-level jack of all trades. Whilst this was helpful in my effort to develop an AppExchange product, I think there are only one or two crucial boxes you need to tick, in order to be successful.

An App could simply be a collection of Salesforce Objects and other declaratively produced functionality (Flows, etc.) that don’t require any coding experience at all. However, to create an App with rich functionality it is almost certain that it will require some coding; Apex and maybe some Javascript are the languages you will use.  So…

Requirement 1: you should have some experience with coding; Java/C# would be ideal as Apex looks very much like Java, otherwise if you have decent experience with any other language, it is pretty easy to pick up. JavaScript is useful as well for developing UI things called Lightning Web Components.  If you don’t have any coding experience, you could learn, and there are plenty of Apex tutorials on Trailhead.

Requirement 2: you need to be pretty familiar with the Salesforce platform. Maybe it goes without saying, but to create an App on Salesforce, you must know how Salesforce works and what it is for. If you are a Salesforce Admin there is a good chance that you’ve come across challenges in your Salesforce org that you wished there was a solution to.

I don’t think you need much more. You don’t need bags of money. It isn’t critical to have sales and marketing experience, and it isn’t even necessary to devote all your time to this.

The Idea For Your App – What To Build?

This warrants an article all to itself. I cannot tell you what to build; but here is a summary of common approaches:

• You’ve already felt a Salesforce pain-point and you think you can build an App that solves it. My first app, SuperRoundRobin, falls into this category.
• You browse the AppExchange and forums for ideas; I recommend finding an area that has established Apps because that tells you that customer demand exists.
• You’ve had a novel idea that you want to turn into an App. If nobody is doing this yet that is great – but beware – it might be that nobody needs it, so do your research.

Whichever approach you choose, you need to establish the following things:

1. That there are Salesforce customers out there that have a business requirement for your App.
2. A price-point exists that you are happy with that isn’t already crowded out by similar, well-reviewed, more established Apps.

Key advice that I provide to people looking to create successful Apps on the AppExchange:

1. Stick to simple, core features and avoid adding bells and whistles.
2. If a prospective customer asks for X, unless it is something that 8/10 customers ask for, don’t build it and politely say your app doesn’t have that feature.
3. Complex features are hard to support, often do not meet any one customer’s use-case 100% of the time.
4. All the above are different ways of saying the same thing – Keep It Simple.

I’ll cover the reasons for the above advice in a different article. The rest of this article focuses on the key steps in starting the journey to launching the App you’ve decided to create.

My First Eureka Moment: It’s (Mostly) All Free

As a manager of .NET development teams, I was used to paying lots of money for Visual Studio licenses, Azure/AWS/Cloud fees, CI tools and all the other stuff you normally need to develop and release software.  

I just had a laptop and an internet connection. However, I soon discovered that I didn’t need to buy any coding tools, or even pay for a Salesforce subscription. I realised that money wasn’t going to be a barrier to launching an App on the AppExchange.  However, some costs were involved – read on to find out.

After a little research about developing and publishing apps on the AppExchange, I understood the following things:

1. I would code everything in Visual Studio Code, using the Salesforce Extensions. Git for source control. All of that is free.
2. There are two stages to being a Salesforce ISV, the partner status you need to list on the AppExchange: Pre-contract: You can sign up to be a Salesforce ISV and get access to a Partner Business Org in order to start the development process very quickly and easily. You also have access to the Partner Portal. Post-contract: You need to sign an ISV agreement with Salesforce. You can do this after you have built your App, but it has to be done before you list it on the AppExchange. See the ‘Bumps In The Road’ section later on.
3. This PBO allows you to spin up different types of Salesforce orgs for testing and development, including ‘scratch’ orgs – temporary orgs linked to the development environment that you use for creating your App.
4. There is a set of development tooling called SFDX – including a CLI that makes it easy for you to push your source code to the scratch orgs, and to deploy code to your ‘Packaging Org’…
5. The Packaging Org is a special org that is used to turn your app code into a Managed Package. This Managed Package is the thing that is listed on the AppExchange and can be installed by admins of other Salesforce orgs.
6. Finally, I understood that when I was ready to release my App to the world, it would first need to pass the Salesforce Security Review. This was a process involving some automated and some manual review, to ensure that the App meets the requirements to be listed on the AppExchange. Furthermore, if I listed a free App, then there would be no security review fee.

Armed with this knowledge, I became a Salesforce ISV (pre-contract), set up Visual Studio Code, created the various Salesforce orgs I needed for my development workflow and I began coding my App. The plan was to list for free so that I could assess the demand and get feedback before spending any real money. Onwards and upwards…

Bumps In The Road: Additional Requirements Discovered

Several months later through on-and-off app development, I had reached the point where my first App was ready for the world. I knew that in order to list my App I needed to complete the ‘business plan’ section in the Partner Portal. Having looked at the forms it had seemed straightforward, so I submitted the forms thinking this was a formality.  

My Partner Account Manager (PAM) contacted me with the following message:

“I can confirm I’ve now received your updated business plan with the compliance form completed. Do you have a registered entity in the UK? I couldn’t find anything on Companies House and I am afraid this is a minimum requirement for the partnership.”

Well, that was a bit of a bombshell. Nowhere in my research had I seen this requirement that you have to incorporate a company!

Luckily these days it’s easy to set up a new company. That same day I created a company via an online company registration service which cost me around £50. It also meant that I needed a company bank account, so I opened one of those as well. 

Once those details had been supplied to the ISV Partner application process, I received news from my PAM that the business plan was approved with some conditions:

“This ISV partnership request is conditionally approved from an anti-corruption perspective, with the caveat that the entity provides proof that it has implemented an anti-corruption training covering bribery, fraud, kickbacks, corruption, gifts, conflicts of interest, etc. for all employees touching Salesforce business within the next 3 months.”

The easiest way to meet this requirement is to complete the Ethics and Integrity for Salesforce Partners on Trailhead.  I had already completed it, so the job was done; thanks Trailhead!

It’s Free Until It Isn’t

After the ISV Partner application process was completed and I was accepted into the fold with a signed ISV Partner Agreement, there remained only the Security Review to pass before my App could be listed on the AppExchange. 

Remember, my plan was for the App to be free so I could assess demand and get customer feedback. Another advantage of this plan is that the security fee is waived for free Apps.

Until I got another message from my PAM:

“If you ever intend to list this app as Paid, then you will need to pay the Security Review Fee of $2700.”

At this time I wasn’t sure. I figured that if the App was successful, then I would want to switch to the paid version. I didn’t want the hassle of maintaining two Apps (Free and Paid). I bit the bullet and paid the Security Review Fee.

So my costs so far:

• Company registration fee: £50
• Security Review Fee: £2000

Ok, so that isn’t a trivial amount of money; but remember this – you can get all the way through to having a listed AppExchange product (a free one) that will enable you to validate whether your App will sell without having to pay the £2000 security fee.

Incidentally, I made that money back in the first month that I listed as a paid App. More on that later.

Security Review Isn’t That Scary, But It Does Take Time

For most would-be Salesforce AppExchange developers it is the Security Review that sends shivers down their spine. The forums and community are full of new Partners asking all sorts of questions about the Security Review.

The key to passing the security review is following a few key best practices:

• ISV Force Guide: AppExchange Security Review
• OWASP Top Ten Security Risks
• Secure Coding Guidelines
• Prevent Common Violations of Secure Coding Guidelines

The Security Review team has limited time, so as soon as they find something that causes a fail, they will stop the review and won’t continue looking for more things. So, if you fail the review it won’t be a comprehensive list of things you need to fix; they may find more in the next review.

Resources exist to help you pass; once you’ve read through all the documentation, you can always hit up their Security Review Office Hours; a scheme they run that allows you to speak directly with Salesforce technical staff. Use this time to ensure you know what the submission requirements are.

They can also assist with creating test environments and the logistics of the Security Review process. Specific technical questions regarding App security can be discussed with the Product Security Team, via the Partner Security Portal.

It generally takes up to 6 weeks, but having followed the best practices laid out by Salesforce (and the wider web-application development community), you will eventually receive a very exciting email:

Now For Some Marketing

With the Security Review in my rear-view mirror, getting the listing polished is the priority now.

Here’s what I focused on:

1. Achieving a consistent look and feel so you look as professional as possible. Look at any established brand. What do you notice? Everything hangs together well. There is a consistent colour palette. Logos are neat, simple and powerful. There is a ‘strapline’ that conveys in a few words, what the product or brand is about. Even though you might be one lone developer with low marketing experience, it is possible to achieve a look and feel that is at the level of a much larger organisation.
2. Demo video. I failed miserably at my own advice here which is to keep it short (my first demo video was 14 minutes long!), and keep it focused on how your App solves the key challenges it was created for. My first demo video at 14 minutes had only 25% engagement at the end of the video. My second demo video at just over 2 minutes had 65% engagement at the end. This means that the majority of people that started to watch the first demo never got to hear about the most interesting things my App does.
3. The text copy should be succinct and must contain the key phrases that people might use when looking for a solution on the AppExchange. Think old school SEO.
4. Use the slides to convey your elevator pitch; most people who land on your page won’t scroll past the first slide. Think really hard about the second slide – use a slide that you think will keep people scrolling through the rest of the slides.
5. Space is very limited on the listing page, so use the resources section to add more in-depth material: use-cases, how-tos, etc. You can even link to videos down there; a mature and successful listing will usually have a well built out resources section.

The Big Question – Free or Paid App?

I’ll answer this with a little story. My App, SuperRoundRobin, went live on the AppExchange in January 2020. What happened next? Nothing, absolutely nothing. Tumbleweed for 6 months. Not a single install, not a single lead. So I put myself in the shoes of a potential customer and looked again at how my App appeared on the AppExchange in the context of the other Apps that did similar things.

This is what stood out:

• There were free and paid Apps with lots of 5-star reviews
• My App wasn’t free, and it had zero reviews

So why would anyone look at my App?

What I needed at this time wasn’t necessarily money for my efforts, it was these two things:

1. Validation that the App actually does solve a common problem and 
2. If I want to make any money, I have to make sure a place (space) exists in the market

What I needed were real customers to test and use my App in real-world situations.

So I switched the App to free and began a ‘beta’ phase where my goal was to get installs and customer feedback. I immediately started getting enquiries and installs. Great feedback followed shortly after and over the next 8 months, the App went from Version 1 to Version 6, with dozens of minor versions along the way.

I learned the following:

• Free Apps will always get the highest frequency of leads and installs
• Paid Apps in a competitive landscape need to have some reviews to get considered by potential customers

So when you are planning the App you want to build, check out the competitive landscape. If there are competitors, then great – that means it’s likely there is good demand. Look at their price points. Are the incumbents expensive and feature-rich? Can you make a product with just the core features at a fraction of the price, where none of the competitors are playing? 

This sounds easy, but it isn’t. Before long, your delighted customers will be thinking of a dozen little things that in their org would make it a perfect product. But remember this – we’re not trying to build a perfect product for one org. We’re trying to build a good product for thousands of orgs.

If there aren’t any competitors then it means you might be able to get in there with a paid product and with more success than I had. It also means there might not be much demand, or that you need to create the demand by developing marketing tactics that describe why your App is a must-have product.  

In this situation, where it isn’t clear what the demand is, only build the core features before launching the App; don’t spend months and months building bells and whistles – look up ‘minimum viable product’ and make it your goal to validate (or invalidate) your product plan.

Now It’s Selling, How Do I Scale?

When your App starts selling, congratulate yourself for a job well done and then immediately get on with the next challenge – how to scale this endeavour. In fact, if you have been following best coding practices, you will have already started contributing to the scaling challenge by shipping non-buggy software.

It can be summed up like this…

An App that scales well is one that requires minimum man-hours from the ISV to:

• Get new leads
• Close deals with new customers
• Get these customers setup and happy
• Support all your existing customers
• Fix bugs

All the while, you should be maximising the satisfaction experienced by your customers.

An important metric to start becoming obsessed with is the Annual Recurring Revenue per Head. This is the amount of annual subscription revenue that your App earns, divided by the number of people you employ. To give you some insight, my personal goal for this metric is $250k.

If your App requires lots of hand-holding and ongoing customer support, you would need to hire support staff sooner. This has the effect of reducing your ARR per Head, limiting your ability to fund further marketing and development efforts.

An ideal situation would be one where customer acquisition and onboarding is efficient and ongoing support is minimised through well-designed software with in-app help. When subscribers do need help, they should first be aware of where they can find answers (e.g., in a knowledge base), and then be able to contact your support team, when they are unable to find out the answer themselves. 

And then this is critical – every support case that reaches your team should be met with a question; how easy is it to find the answer to this question in the knowledge-base / in-app help? If the answer isn’t in there – they should add it. This helps to reduce all the future instances of this question coming in from other customers, keeping your support burden low. Awesome.

Summary

The Salesforce ecosystem for the ISV Partner includes the development toolset, org provisioning and access to the Partner Community that houses lots of documentation to help you with whatever stage of your journey you might be in. Add to that, the huge Trailhead resource and you have an immense set of free resources to build your AppExchange business.  

It is of course your responsibility to come to the table with an idea that you can turn into an App, but hopefully, this article has given you some insight into how you can take that idea and turn it into reality on this platform.  

Do you have any questions? Fire away in the comments section. Check out how I’ve laid out the AppExchange listing for SuperRoundRobin. To get going on your own journey, start with the ISV Onboarding Guide from Salesforce. Have fun and good luck.