The Ultimate Guide: Succeeding on AppExchange
As an ISV partner, to succeed on AppExchange, a good idea must be accompanied by careful planning, as it’s not just one solo org but many customer orgs with various licenses, features and other variations.
The following are critical checkpoints in your ISV journey.
Signing up as a Partner
Have a business entity incorporated as per residency state law.
Sign up on Partner Community - https://partners.salesforce.com/partnersignup.
This process involves a review of your business entity, submitting various incorporation papers for compliance, filling out partner questionnaire forms, and signing compliance and other relevant agreements.
High-level Specs
Document critical features of the app and brainstorm within your team and/or with our Appexchange experts to draft crisp high-level specs that will cover:
What business problem or use case is the app trying to solve?
Which Salesforce clouds, editions, features and licenses will be needed?
Integrations with 3rd party services (is it optional)?
Personas of end-users interacting with the app?
Pricing strategy?
Business Plan Approvals
Before investing effort, time and money, it’s good to get your business plan validated and approved by Salesforce.
This ensures that your app does not conflict with some existing Salesforce offerings and is also a good market fit.
A business plan is created and submitted via the Partner community.
The high-level specs created in the above step are pretty helpful in drafting a business plan.
Specs - As a Business User
Depending on the founding team’s Salesforce familiarity, this can be high-level or very detailed.
The idea here is to go deep on each feature and explain, at a minimum, as a business user.
Prioritise the features to scope the efforts, release timelines and roadmap. Along with feature prioritisation, plan what features are must-haves for a MVP (Minimum Viable Product) release.
It is crucial to plan a lean MVP, which leads to early submission for security reviews, along with early access to prospects and alpha/beta customers.
Specs - Technical
A Salesforce architect is involved here, who will translate all business requirements into various technical counterparts in Salesforce. Hiring a Salesforce Architect with decent exposure to the AppExchange development/compliance process is crucial. This architect will work with business stakeholders to document
the detailed technical architecture for the app, including which frameworks to use, clicks vs code, etc.
a release plan for MVP, as per the budget.
team mix to deliver the app, like Developers, architects, QA, PMs, Designers/UX, DevOps etc.
Finding the right team mix
The beauty of the Salesforce platform is it's not code-heavy, so you don't need a lot of developers to deliver a MVP (Minimum Viable Product). Thus, apart from a few good developers onboard, you could need the following roles, depending on your budget, the number of developers and the app’s complexity.
A seasoned Salesforce Architect who can set the app's architecture correctly, as it's challenging/impossible to fix some wrong metadata decisions later on.
User Experience: Unless you are building a lightning bolt or experience cloud solution, all the internal screens should align closely with Salesforce design guidelines; Salesforce users are familiar with Salesforce UX. There are tools like https://www.avonni.app/ that can help you mock your internal Salesforce experience really well, and it saves costs by generating an excellent boilerplate LWC/Aura/VF code as well. Again depending on budget and UX requirements, you could plan to have an existing architect/lead who can use these UX tools like Avonni (if they have good taste and understanding of UX), or hire a dedicated UX guy.
Product Manager - It could be you as a business owner and the person with ideas, or a Salesforce Architect, or someone who understands Salesforce well, can see a long-term vision, create a roadmap, and translate the same into epics, stories etc. Depending on the budget, the same person could be your Project manager to drive sprints, track velocity, etc.
QA - depending on budget, it can be your developers, CXO, PM Architect, or you. If budget permits, it's good to have a dedicated QA team. Your app will be exposed to one edition of Salesforce and various features/abilities with multiple user personas. Developers don’t do an excellent job testing all these permutations and combinations.
DevOps - Any of your Architects or developers can do this initially, and a seasoned DevOps guy could be hired later if required.
Sales/Marketing: Manage the listing on AppExchange, give demos, market via social media, attend events, and much more. It could be a business owner (or someone from their team). It could be outsourced to PDO as well.
Customer Success / Support - Planning a support function and having them assist with customer onboarding/implementation, troubleshooting, and random support requests is essential; the quality of customer support highly impacts your brand/app’s success & reputation. Good support leads to highly positive reviews and frees developers to focus on your app's subsequent iterations (v2, v3).
Documentation Team: Detailed documentation is required for all AppExchange apps, including installation and setup instructions, videos, user guides, and API references. It could be from the business owner’s side or the PDO’s team.
Security Reviews
Security is Salesforce's top priority, as many Fortune 500 brands use it. AppExchange apps must meet strict security standards for quick security approvals.
None of the apps can go live on AppExchange without clearing security reviews.
Many ISVs hire inexperienced PDOs or vendors to develop their apps. For sure, this saves money, but at what cost?
The app gets rejected in the Salesforce security review, and it delays the release by months, not weeks.
It typically takes at least 4-6 weeks for Salesforce to respond to security review submissions.
Many security gaps reported in security reviews can cause major architecture overhauls and lead to delays and development costs.
Develop in-house vs hire a PDO.
This is a crucial decision for all entrepreneurs in the short and long term. But 1st, let’s understand who PDOs are.
Product Development Outsourcers (PDOs) are Consulting Partners with expertise in building commercial apps and other valuable services like training, supporting, marketing, or selling your app. They have proven experience in listing ideas of ISVs (Independent Software Vendors) on AppExchange.
PDOs act as a compass for ISVs, making the right business decisions, choosing a correct/scalable application architecture, planning a release roadmap, and deciding the sales, support and marketing strategies.
This is required if you lack the technical team and expertise in the AppExchange listing & development process. This engagement could be done in multiple forms, depending on the skill set of your in-house team, forex.
End-to-End Delivery - Your team primarily comprises business stakeholders, and PDO is onboarded to architect, develop, QA, list and support the app.
Hybrid - Your team has Salesforce architects/developers. PDO fulfils the remaining roles and assists with AppExchange expertise in discussing architecture, development strategy, security review and other agreed responsibilities.
Implementation/Support - PDO can take this role or be owned by ISVs.
One can argue about learning the AppExchange development process via Trailhead instead of onboarding a PDO. This could be a good idea, but we don’t recommend doing trials & errors with AppExchange, as it could delay your app launch, and some architectural decisions, if went wrong, impact the ability of the app to scale, especially when you have some customers using the app with lousy architecture.
Learn more about our PDO offerings here - https://www.concret.io/service/ideas-to-appexchange-listing
