Integration Services
Business Consulting & Advisory
AI Solutions
AppExchange Development
Tailored Salesforce Engineering
Managed Services
Implementation
Key Takeaways
- Salesforce AppExchange development is a product business, with commercial, technical, security, and operational commitments at every stage.
- Decide early whether you are building to sell or for internal use. Commercial products require managed packaging, licensing, upgradeability, and security review..
- Treat packaging and security as architectural decisions. Plan namespace, versioning, permissions, integrations, and upgrade paths from day one.
- Budget beyond the build. Partnership economics, review costs, listing, support, licensing, and Salesforce release testing continue after launch.
- Choose the right build model. In-house, partner, or hybrid depends on your team’s Salesforce depth, product experience, and time-to-market needs.
- AgentExchange opens another marketplace opportunity for ISVs building products and components for Agentforce.
You have a product idea, a Salesforce team, and perhaps even your first customer waiting. Then you start mapping what it takes to get that product onto AgentExchange, formerly known as AppExchange. The first surprise is usually that the build is only one part of the journey. Partnership decisions come before development. Packaging choices can affect every future upgrade. A security review can send the architecture back to the drawing board. And after launch, licensing, support, and Salesforce releases become part of the product you have to run.
Most AppExchange guides explain these stages one by one. They tell you what happens, but rarely what each stage commits you to, what it can cost, or which decisions become difficult to reverse. For an independent software vendor (ISV), that distinction can determine whether the business case still works once development begins.
This guide takes a decision-first view of Salesforce AppExchange development, following the product from validation and partnership through managed-package engineering, security review, listing, and post-launch operations. Where Salesforce fees, revenue-share terms, or program requirements change, we verify the current figures and mechanics against Salesforce documentation and date them at publication.
This perspective comes from shipping and operating our own AppExchange-listed products, including LoansNeo. That experience shapes the questions we ask an ISV before committing to the next gate: what will this decision cost, how difficult will it be to change later, and what will the team need to support after launch?
The aim is to understand the full commitment before making the first irreversible one.
Table of Content
- Are You Building for Your Own Org or to Sell?
- What Does the AppExchange Journey Actually Involve?
- What Does It Actually Cost to Take an App to AppExchange?
- What Does AppExchange App Development Require That Internal Builds Do Not?
- How Should You Engineer for the Salesforce Security Review?
- What Happens After Your AppExchange Listing Goes Live?
- Who Should Build Your AppExchange Product?
- What Does AgentExchange Mean for ISVs?
- Frequently Asked Questions
Are You Building for Your Own Org or to Sell?
The first decision is not how to build your Salesforce application. It is what you are building for. An application built for your own org can be designed around your processes, users, and operating model. A product built for the AppExchange has different requirements. It must work across customer orgs, support upgrades, accommodate licensing, and pass Salesforce’s security review. If you want to commercialize the product, follow this guide. If you are building for internal use, the Salesforce App Development decision guide is the better route.
That distinction also determines which type of Salesforce partner you may need. Salesforce AppExchange partners span several roles, and choosing the wrong one can create unnecessary cost or capability gaps. An ISV partner owns and sells software products. A Product Development Outsourcer (PDO) builds products for ISVs. A systems integrator or consulting partner primarily implements Salesforce solutions for end customers. One firm can occupy more than one of these roles, so evaluate the capability behind the partner label.
What Does the AppExchange Journey Actually Involve?
Salesforce AppExchange development is best understood as a pipeline, not a single build project. Each gate moves the product closer to customers, but each also introduces a cost, a commitment, or a decision that can become expensive to reverse. The six gates below provide the map. The sections that follow examine what each one demands.
| Gate | What happens | Cost class | What is difficult to undo? |
|---|---|---|---|
|
1. Validate |
Test market demand, customer need, and Salesforce platform fit before committing to development. |
Discovery and validation |
Product direction: Building before validating can lock resources into a weak market opportunity. |
|
2. Partner |
Apply to the relevant program, complete agreements, and understand the commercial model. |
Program and partnership costs |
Partnership terms: The commercial relationship shapes how the product reaches market. |
|
3. Build |
Engineer the product as a managed package, with packaging, namespace, licensing, upgradeability, and multi-org testing in mind. |
Product development |
Architecture: Namespace and core packaging decisions can constrain every future release. |
|
4. Review |
Submit the product for Salesforce security review, address findings, and complete any required re-review. |
Review and remediation |
Technical debt: Late security fixes can force architectural changes and delay launch. |
|
5. List |
Prepare the AppExchange listing, pricing, trial experience, documentation, and go-to-market assets. |
Launch and commercial setup |
Market model: Pricing, packaging, and trial choices shape acquisition and conversion. |
|
6. Operate |
Manage licenses, support customers, release upgrades, test against Salesforce releases, and maintain compliance. |
Ongoing operating cost |
Customer obligations: Every installed version creates a continuing support and upgrade responsibility. |
The important question at each gate is therefore not only “What happens next?” It is “What am I committing to now that will be difficult or costly to change later?” That is where an AppExchange product starts to differ from a conventional development project.
Why Salesforce Skills Are Moving Beyond Configuration and Code
What Does It Actually Cost to Take an App to AppExchange?
For an ISV partner, the AppExchange decision starts as a commercial one. Before development begins, you need to understand the partnership agreement, distribution model, revenue share, security review, and post-launch costs. Salesforce does not charge a fee simply to join its Partner Program, but commercial distribution introduces other costs and contractual commitments.
The current economics also depend on how you distribute the product. Salesforce describes Percentage Net Revenue (PNR) as its standard revenue-share model, with the applicable rate determined by the partner and distribution model. Current Salesforce guidance for the ISVforce program also identifies a 15% revenue-share option, alongside an annual-fee option based on the number of customer orgs and/or users covered[1].
Direct marketplace costs also apply. Salesforce’s current security-review guidance lists a that the initial Security Review fee is $2,700 USD for each paid app submitted (no fee for free apps). The annual listing fee is $150 USD. Salesforce also says a complete security-review submission typically takes 4 to 6 weeks[2].
The business case should therefore model at least three years of revenue share and operating costs against alternative distribution channels. AppExchange provides access to an established Salesforce customer marketplace, but that distribution comes with a price. The right question is whether the reach, trust, and sales opportunity justify the economics for your product.
What Does AppExchange App Development Require That Internal Builds Do Not?
Salesforce AppExchange app development changes the engineering equation when a product must run across customer orgs. An internal Salesforce application can be designed around one organization’s data and workflows. A commercial managed package must account for different org configurations, upgrades, dependencies, licensing, and Salesforce platform changes.
1. Start with 2GP and the Namespace.
For new managed packages, second-generation packaging (2GP) provides the modern packaging model. Treat the namespace as an early architectural decision because it becomes part of how subscriber orgs identify the package’s components. Versioning and package ancestry also need discipline from the start.
2. Design for the Upgrade, Not Just the First Release
Customers upgrade an existing installation rather than starting over with every release. Schema, dependencies, APIs, and component changes must therefore be evaluated against future versions. Salesforce supports push upgrades for eligible managed packages that have passed security review.
Testing should also reflect real subscriber environments. Different editions, configurations, permissions, and dependencies can expose issues that never appear in the development org.
3. Build Licensing into the Product
Consider licensing alongside the product architecture. The License Management App (LMA) helps ISVs track package installations and manage managed-package licensing. Plan subscriber support, controlled upgrades, version management, and permitted usage analytics before launch.
The principle is straightforward: internal applications can often be refactored around their original assumptions. Commercial packages carry those assumptions into every customer org and future release. Each of these architectural decisions also affects the security review covered next.
How Should You Engineer for the Salesforce Security Review?
The security review should not be the final hurdle before an AppExchange launch. It should shape the product from its first sprint. Salesforce requires managed packages listed on AppExchange to pass the review, which examines the solution’s security posture and how it handles customer data.
“Nothing is more important to our company than the privacy of our customers’ data.”
– Parker Harris, CTO at Salesforce
The practical approach is to turn the review requirements into engineering rules. Test access controls, data protection, input handling, credentials, integrations, and third-party components continuously, rather than only before submission.
Design Rules for the First Sprint
CRUD and FLS Enforce object- and field-level permissions across every relevant code path. Don’t assume a user’s access to the application automatically protects every query or update.
Sharing and Data Access Design Apex and other platform logic around Salesforce’s sharing model. Treat every path to customer data as an explicit authorization decision.
Injection and XSS Validate untrusted input and safely handle dynamic queries, markup, and output. Security controls belong in the Salesforce implementation, not in the final review checklist.
Secrets and Credentials Never hard-code credentials or expose sensitive secrets through insecure configuration. Every credential an integration uses should have a deliberate storage and access model.
External Integrations Treat every API, endpoint, web application, mobile component, browser extension, or third-party dependency as part of the review surface. Salesforce’s 2026 guidance confirms that integrations connected to a managed package can fall within the security-review scope.
Make Security Testing Part of the Build
Salesforce Code Analyzer provides AppExchange-specific rules and requires scan reports as part of the security-review submission for managed packages. The current Code Analyzer v5 also includes dedicated security capabilities, including Flow Scanner, and Salesforce recommends integrating the tool into CI/CD so issues can be identified throughout development.
Salesforce lists the initial security-review fee for a paid app at $2,700 per submission, with a $150 annual listing fee, while free apps have no initial review fee.
The lesson is straightforward: teams that meet the security review only at the end pay twice. They pay once to build the product and again to redesign what should have been secure from the beginning.
What Happens After Your AppExchange Listing Goes Live?
Getting an AppExchange listing live starts the operating business, not the end of development. The listing itself becomes a product surface. Its positioning, category, screenshots, demo assets, documentation, and customer reviews all influence how prospective buyers discover and evaluate the product.
As Kraig Swensrud, founder and CEO of Qualified, puts it, “Building a great company is more than just creating a hit product.” On AppExchange, that means thinking beyond the release itself. The product also needs a route to market, a trial and pricing strategy, reliable licensing, customer support, and a plan for every Salesforce release that follows.
1. Turn the Listing Into a Buying Experience
A trial strategy should reduce the gap between discovery and adoption. Depending on the product, this may include free trials, test drives, or Trialforce experiences that let prospects evaluate the product in a controlled Salesforce environment. The right approach depends on how quickly customers can experience meaningful value.
2. Plan for the Product’s Long Life
Once customers install the product, operational obligations begin:
- License Management App (LMA): Manage package installations, provisioning, licenses, renewals, and expirations.
- Salesforce releases: Every seasonal release is a regression event you owe your customers. Test compatibility before each release reaches production environments.
- Customer support: Establish processes for installation issues, upgrades, configuration questions, and product defects.
- Listing compliance: Keep marketplace information current and be prepared for additional security reviews or compliance requirements as the product evolves.
The common mistake is budgeting heavily for development and lightly for everything that follows. An AppExchange product can stay in customer orgs for years, so support, upgrades, licensing, and release testing should be part of the business model from the start. The operate gate is where the build budget most often runs out.
How Salesforce Connects CRM, Cloud, Data, AI and Business Applications
Who Should Build Your AppExchange Product?
The right Salesforce AppExchange development services model depends on what your team already has and what it needs to learn. In-house teams retain the most product knowledge, while an experienced Salesforce developer can shorten the learning curve around packaging, security review, and marketplace launch. A hybrid model can combine both.
| Model | Best When | Main Trade-Off |
|---|---|---|
|
In-House |
You have Salesforce depth, product engineering capability, and a long-term roadmap |
You absorb the first-product learning curve |
|
Partner |
You need AppExchange experience and faster time to market |
You need to vet the vendor carefully |
|
Hybrid |
Your team wants to own the product while using specialist support |
Knowledge transfer must be built into the contract |
How to Vet a Salesforce AppExchange Development Company
Look for evidence rather than capability claims:
- Shipped products: Own AppExchange products or verifiable client listings
- Security experience: Evidence of successful reviews and how findings were remediated
- Packaging expertise: Experience with managed packages, upgrades, and multiple versions
- Post-launch support: Licensing, releases, support, and ongoing maintenance
- Scoping discipline: A plan that covers the full pipeline, not just development
A hybrid engagement should also specify who owns the architecture, source code, product roadmap, and knowledge transfer.
Why Achieva Fits the Rubric
Achieva’s Salesforce practice combines more than two decades of delivery experience with AppExchange product development. The company currently identifies itself as a Salesforce Summit Partner and says its team has developed and delivered 7+ apps on AppExchange. Its listed products include LoansNeo, OptimaPro, Dealer Management System, Field Sales Connect, iWorkRemote, Nonprofit Navigator, TimeSlate Pro, and Address Finder.
That matters because its relevant experience isn’t limited to implementing Salesforce for customers. Building its own products means working through the same product-level concerns covered in this guide: packaging, upgrades, security, listing, licensing, and ongoing operation.
Achieva’s Salesforce AppExchange development services span ideation, product development, packaging, listing, and ongoing support. Its published services also position AppExchange development alongside broader Salesforce consulting and ISV expertise.
For an ISV evaluating a partner, the useful question is therefore not simply whether a vendor can build on Salesforce. It is whether the vendor has carried a commercial Salesforce product through the full lifecycle and can explain what happens at each gate.
Bring your product idea to Achieva to assess the pipeline, including which parts make sense to build in-house and where specialist support adds value.
What Does AgentExchange Mean for ISVs?
AgentExchange extends Salesforce’s marketplace model into the agentic enterprise. It brings together apps, agents, and Slack solutions, while giving customers access to pre-built agent actions, topics, templates, and other tools directly within Agentforce. Salesforce says the unified marketplace now offers more than 13,000 solutions, with discovery powered by semantic search[3].
For ISVs, this creates another distribution surface. Existing AppExchange products can extend into agent actions or other agentic components, while new products can be designed specifically around Agentforce use cases. Salesforce also lets users discover and activate these solutions in Agentforce Builder, reducing the gap between marketplace discovery and deployment.
AgentExchange is evolving quickly, so check its packaging, listing, and commercial requirements against current Salesforce documentation before committing to a product strategy.
