For a SaaS company, Salesforce AppExchange app development means three things. You build a second-generation (2GP) managed package from your Partner Business Org and pass a security review that Salesforce estimates at approximately 4 to 6 weeks. Then you publish a listing on AgentExchange, the store that replaced the AppExchange brand in April 2026. Salesforce prints no end to end timeline. Your launch date is your build time plus the number of review rounds you need, so most of what decides it happens before you submit.
That framing matters because the app is rarely the product. It is the way your customers' Salesforce users see your data inside the CRM they already work in, and enterprise buyers ask for it during the deal. The decisions that are hard to undo come early, such as which org owns the package, how much logic runs outside Salesforce, and which listing type you pick. Appnigma's marketplace apps team builds native Salesforce apps for SaaS companies and covers "a native app, marketplace listing preparation, and review support." If you are comparing agencies rather than planning the build, our guide to choosing an AppExchange development company covers that question.
Updated October 2026. Checked against Salesforce's ISVforce Guide, the Second-Generation Managed Packaging Developer Guide, the Secure Coding Guide and the April 2026 AgentExchange announcement. The earlier version of this post gave a 6 to 9 week review, a "roughly half fail" rate, 15% and 25% revenue shares, invented customer results and retired solution categories such as Lightning Data. None of those is in Salesforce's documentation. This version replaces them with the documented steps, adds the ownership and post-install decisions, and adds a worked launch-date example.
The seven steps from partner signup to a published listing
Salesforce describes the ISV path in one line. After joining the Partner Community you "build your solution, execute a commercial agreement, complete a security review" and list, per Become an ISV Partner. In practice a SaaS team schedules seven steps between signup and a published listing, and Salesforce sets a requirement at each one.
| Step | What you do | What Salesforce requires or prints |
|---|---|---|
| 1. Join and get a PBO | Join the Partner Community. Your Partner Business Org (PBO) is provisioned on joining | Partners "should designate their PBO as their Dev Hub org," and Dev Hub starts disabled |
| 2. Namespace | Create a namespace in a Developer Edition org and link it from the PBO | One namespace for all your 2GP packages is recommended |
| 3. Build | Develop in scratch orgs from a Salesforce DX project, create package versions | Version creation "can take several minutes" |
| 4. Promote | Promote a beta version to Managed Released | 75% Apex code coverage, and promotion can't be reversed |
| 5. Agreement | A partner recruitment rep confirms your distribution agreement | Required before you submit for review |
| 6. Security review | Submit scans, docs and a test org | "Approximately 4 to 6 weeks" for an initial review |
| 7. List and publish | Listing approval, then the Partner Application Distribution Agreement (PADA), then Publish | Live "approximately 30 minutes after you click Publish" |
The PBO lines come from Partner Business Org. The namespace steps come from Salesforce's Get Started with Modern AppExchange Development and Create and Register Your Namespace. The version and promote rules are in Get Ready to Promote and Release, and the agreement rule is in Submit Your Solution for Security Review. The review estimate is from Act on Security Review Results and the publish time from the Trailhead unit Review Your Work and Publish.
The build, the promotion and the security review hold almost all the elapsed time. The distribution agreement has no printed duration, which is the reason to start it on the first day of the build instead of the week the code is done. Our post on how long it takes to get an app on AppExchange times each stage in more detail.
Decide what runs inside Salesforce before you write code
The first design choice is where your logic lives, because it sets both your security review surface and your listing options. Most SaaS apps land in one of three shapes.
| Shape | What it looks like | What it adds to the review |
|---|---|---|
| Fully native | Apex, Lightning Web Components and Flow inside the package, data stays in the customer org | Code Analyzer scans of the package only |
| External with a thin package | Your product does the work, the package holds objects, a UI and callouts to your API | A scan of your external endpoints too, plus test credentials for them |
| API only | No package, your service calls the Salesforce API | Review of the external app, but an API listing |
Salesforce's Source Code Scanner and DAST guidance asks for a Dynamic Application Security Test (DAST) scan of external components, with a scanner such as ZAP or Burp Suite. The Required Materials for Security Review Submission page also asks for "URLs and login credentials for external components requiring authentication." Reviewers test the parts they can reach, so every endpoint your package calls becomes part of what you submit.
Most B2B SaaS integrations end up in the middle row. The customer's users want your data on the Account page and in their reports, and your product is where the data comes from. The thin package keeps the in-org experience native while the heavy processing stays on infrastructure you already run.
The API-only shape looks cheaper, but it changes what you can list. Salesforce offers three listing types (Packaged Solution, API and Consultant), and "you can't change the listing type after it's created," per Select a Listing Type. Bolt Solution, Flow Solution and Lightning Component, which older guides list as separate solution categories, are now package types inside a Packaged Solution listing. If customers will want installed components later, start with the package.
Set up org and namespace ownership before the first commit
Ownership mistakes are the ones that cost the most to fix, because a 2GP package belongs to the Dev Hub that created it. Salesforce says partners "should designate their PBO as their Dev Hub org," per Partner Business Org. If a contractor builds the package from their own Dev Hub, it is tied to an org your company doesn't control.
Four ownership checks belong in the project kickoff, not the handover.
- Dev Hub in your PBO. Enable it there yourself, because "Dev Hub is disabled in newly provisioned PBOs."
- Namespace under your name. The namespace prefix appears on every object and field in customer orgs, and you register it once in a Developer Edition org that your company owns.
- PBO trial status. Salesforce's developer blog notes the PBO "starts as a trial org, which expires in one year," and is converted to a permanent org by a case after you sign the PADA.
- A group security review contact. Review emails go to the contact on the submission. A shared mailbox survives staff changes.
Our explainer on the Partner Business Org covers the licenses and preinstalled tools it comes with, including the License Management App, which Salesforce says "is installed in all partner business orgs," per Install the License Management App.
Should a new AppExchange app use 1GP or 2GP?
Use 2GP. Salesforce's developer blog is direct about it, saying "all new packages should be 2GP. As of 2024, nobody should create any new 1GPs," in Get Started with Modern AppExchange Development. The ISVforce Guide says "we recommend that everyone use managed 2GPs to create new apps," per Use Managed Packages. Salesforce has published no retirement date for 1GP.
The practical difference is where the package comes from. A first-generation package is built from metadata in a packaging org. A 2GP package is built from source control with the Salesforce CLI, which means your CI pipeline can create and test versions without anyone logging in to an org. Read our explainer on what a managed package is if you need the managed, unlocked and unmanaged comparison first.
Two 2GP rules catch first-time teams. Beta versions "can be installed in only scratch orgs and sandboxes," and Salesforce's blog warns "you can't upgrade a subscriber installation from a beta version." Put a beta in a customer's sandbox for a pilot and that install has to be removed before the released version goes in. The second rule is the 75% coverage gate at promotion. A team that writes tests last finds it in the week it planned to submit.
If you already ship a 1GP package, you don't rebuild it. Package Migrations, "now generally available with Summer '25," converts it, per Managed 2GP with Package Migrations Is Now GA. Our 1GP to 2GP migration guide covers the conversion commands and what blocks them.
Build the package for the security review, not for the demo
The review tests for a short list of things, and CRUD and field-level security (FLS) enforcement has been the most common finding "by a significant margin," per Salesforce's top 20 vulnerabilities post. CRUD means object permissions and FLS means field permissions. Code written for a demo usually runs as an admin and never notices either.
Three coding choices remove most of that risk.
Run queries in user mode. Use WITH USER_MODE in SOQL and Security.stripInaccessible() on records. Don't use the older WITH SECURITY_ENFORCED clause. Salesforce says it "isn't allowed in AppExchange packages," per the Secure Coding Guide on CRUD and FLS, and from API 67.0 you can't use it in Apex at all.
Know what API 67.0 changes. "In API version 67.0 and later, Apex runs in user context by default," per Versioned Behavior Changes. A package with classes on mixed API versions will run some code as the user and some as the system. Moving everything to one version, and declaring sharing on every class, is easier to reason about than a mix.
Keep secrets out of code and custom settings. Package-wide secrets "(such as an API key) must be stored in Managed Protected Custom Metadata Types," per Storing Sensitive Data. Credentials for calling your own API from a customer org belong in Named Credentials, which the same page calls "a safe and secure way of storing authentication data."
Before you submit, scan the package. "If your solution is a managed package, you're required to scan it using Salesforce Code Analyzer," per Test Your Entire Solution, and "all new solutions submitted for security review must be Lightning Ready." Salesforce also notes that "applicants who don't test beforehand rarely pass and must resubmit." Our Salesforce security review guide and Code Analyzer guide list what reviewers expect in each report.
How the security review sets your launch date
An initial review takes "approximately 4 to 6 weeks after you submit," per Act on Security Review Results. Salesforce splits that into 1 to 2 weeks of verification and 3 to 4 weeks of testing, and gives 2 to 3 weeks for a retest, per How the Security Review Works. It calls all of these estimates.
What a setback costs depends on its type. A submission returned for missing items (an expired test org login is a common one) pauses until you answer. "There's no charge to resubmit a returned submission." A failed review means a new package version and a paid retest, since "there's a fee to retest a remediated solution," per Security Review Stages. No current Salesforce page prints the fee amount, so check it in the submission wizard. Free apps don't pay it.
Here is a worked example using only those published estimates. Take a 10 week build.
| Plan | Arithmetic | Weeks to a listing you can publish |
|---|---|---|
| Clean first pass | 10 build + 4 to 6 review | 14 to 16 |
| One failed round | 10 build + 4 to 6 review + 2 fix + 1 to 2 verification + 2 to 3 retest | 19 to 23 |
The two weeks of fix time are an assumption, so put your own figure in. The point of the arithmetic is the gap. One failed round adds five to seven weeks, which is often longer than the feature work you could cut to ship sooner. For a real reference point, the marketplace apps page lists Warmly at 8 weeks from kickoff to AppExchange launch "including six weeks of Salesforce security review" and labels it "a project example, not a guaranteed schedule." Our post on how long the Salesforce security review takes breaks the stages down further.
Listing, pricing and the agreements on the way
Three commercial steps run alongside the build, and two of them are easy to leave too late. The distribution agreement has to be confirmed before you submit for review, per Submit Your Solution for Security Review. The listing can be built and linked to a solution during the review, but "you can't publish on AgentExchange until it passes," per the Listing Builder overview. Then, "after your listing is approved, you must sign a Partner Application Distribution Agreement (PADA) before it can be published," per Get Your Listing Approved.
Pricing depends on how you bill. Checkout is Salesforce's built-in payments option. Its revenue share is 15% "plus a $0.30 per transaction fee charged by our payment partner" Stripe, per Checkout Revenue Share. Outside Checkout, Salesforce uses a "Percentage Net Revenue (PNR)" model that "is dependent on the app distribution model a partner chooses," per the Become a Partner FAQ. Salesforce doesn't publish one fixed figure for every model, so your rate is the one in your partner agreement. Our post on the requirements for a paid AppExchange app compares the billing paths.
Your listing is a sales asset, but it is not a lead source by itself. The marketplace apps page puts it plainly, saying "a listing supports discovery and evaluation, but it is not a promise of inbound leads." Plan for your own sales team to send prospects to it.
Is it AppExchange or AgentExchange now?
Both names are in use, and the build process is the same. On April 14, 2026 Salesforce launched a new AgentExchange that brings AppExchange, Slack Marketplace and the Agentforce ecosystem into one marketplace, per Introducing the new AgentExchange. The same page announces a new $50M AgentExchange Builders Initiative. Salesforce's newsroom counts 10,000 Salesforce apps in it, per the Headless 360 announcement. The same story counts more than 2,600 Slack apps and more than 1,000 Agentforce agents.
The AgentExchange name is older than the merger. Salesforce launched it on March 4, 2025 as a marketplace for Agentforce, where partners could offer "four types of agentic components," per the launch press release. MCP servers appear in the 2026 materials, not the 2025 launch. Today the ISVforce Guide introduction lists MCP servers next to packaged apps, Agentforce solutions, flows, integrations and OEM solutions as ways to reach customers.
For a SaaS company the merger changes the storefront, not the work. Building a managed package, passing the security review and getting a listing approved work the same way whichever name your buyers use. Our explainer on what AgentExchange is covers the rest of the change.
What changes once customers install your app
A package behaves differently in customer orgs than in your scratch orgs, and the differences show up after the first enterprise install. Planning for them is most of what maintenance means.
Governor limits change when you pass review. "Certified managed packages, managed packages that have passed the security review for AppExchange, get their own set of limits for most per-transaction limits," per Execution Governors and Limits. Before certification your package shares the customer's limits. After it, heap size and CPU time are still shared with the customer's own automation. A pilot in a customer sandbox before you pass review can hit SOQL limits that production won't, and CPU time is the limit to watch afterwards. Our post on governor limits for managed packages works through the numbers.
Professional Edition waits for the review too. Packaged Apex can run in Group and Professional Editions, but "your app has to pass the security review," per Apex in Group and Professional Editions. If your customer base includes smaller Salesforce orgs, a pre-review pilot will not represent them.
Three Salesforce releases a year need a test pass. 2GP lets you create versions against the "preview" or "previous" release during a transition, per Target a Specific Salesforce Release. Use the preview window to test before your customers' orgs upgrade.
Push upgrades need setup. Pushing a version to installed orgs is available only to packages "that have passed the AgentExchange security review," and you "log a case with Salesforce Partner Support" to enable it, per Push Upgrades for 2GP. Salesforce suggests it "might be better to wait 3-4 weeks after a major Salesforce release" before pushing major upgrades. New versions don't need the full review again, though periodic re-reviews do happen, per Periodic Re-Reviews.
Each customer org is also configured differently. Their required fields, validation rules and triggers run in the same transaction as your code. That is why an integration that worked in your test org can fail in one customer's org and not another, and why the support load grows with the number of installs, not the number of features.
Mistakes that slow a first AppExchange launch
- Building in a contractor's Dev Hub. The 2GP package stays bound to the Dev Hub that created it. Build from your own PBO.
- Leaving the distribution agreement until the code is done. Salesforce prints no time for it, and you can't submit without it.
- Testing as an admin. CRUD and FLS findings are the top review issue. Test with a restricted permission set from the first sprint.
- Writing tests last. The 75% coverage gate blocks promotion, and the review needs a released version.
- Piloting a beta in a customer sandbox you want to keep. Betas can't be upgraded to a released version.
- Picking the API listing to save time. The listing type can't be changed after creation.
- Budgeting only for launch. Releases, push upgrades and per-org support continue for as long as customers have it installed.
Frequently Asked Questions
How long does it take to build an AppExchange app?
Salesforce prints no end to end figure. Plan your build time plus approximately 4 to 6 weeks of security review, so a 10 week build is about 14 to 16 weeks to a publishable listing if the first review passes.
Do I need a Partner Business Org to build an AppExchange app?
Yes for a listed managed package. The PBO is provisioned when you join the Partner Community, and Salesforce says partners should use it as their Dev Hub, which is where 2GP packages are created.
Is the AppExchange security review free?
Free apps don't pay the review fee. Paid apps pay a fee that the current ISVforce Guide doesn't print, and resubmitting a returned submission costs nothing.
Can you build an AppExchange app without Apex?
Yes. A package can hold Flows, Lightning Web Components and configuration, and Flow Solution is a documented package type. It still goes through the same security review.
Can Appnigma build our AppExchange app?
Yes. Appnigma's marketplace apps service builds the native Salesforce app and covers listing preparation and review support. Ongoing maintenance is a separate retainer.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- How Long Does It Take to Get an App on the AppExchange?
- What Is a Managed Package in Salesforce?
- What a Salesforce AppExchange App Costs to Build
- Salesforce Security Review Guide
- How to Get Your App Listed on AgentExchange
- What Is Salesforce AgentExchange?
Sources
- Salesforce, Become an ISV Partner
- Salesforce, Become a Partner FAQ
- Salesforce Developers, ISVforce Guide, Partner Business Org
- Salesforce Developers Blog, Get Started with Modern AppExchange Development
- Salesforce Developers, ISVforce Guide, Use Managed Packages
- Salesforce Developers, Second-Generation Managed Packaging, Create and Register Your Namespace
- Salesforce Developers, Second-Generation Managed Packaging, Get Ready to Promote and Release
- Salesforce Developers Blog, Managed 2GP with Package Migrations Is Now GA
- Salesforce Developers, ISVforce Guide, Select a Listing Type
- Salesforce Developers, ISVforce Guide, Source Code Scanner and DAST
- Salesforce Developers, ISVforce Guide, Required Materials for Security Review Submission
- Salesforce Developers, Secure Coding Guide, CRUD and FLS
- Salesforce Developers, Secure Coding Guide, Storing Sensitive Data
- Salesforce Developers, Apex Developer Guide, Versioned Behavior Changes
- Salesforce Developers Blog, The Top 20 Vulnerabilities Found in the AppExchange Security Review
- Salesforce Developers, ISVforce Guide, Test Your Entire Solution
- Salesforce Developers, ISVforce Guide, How the Security Review Works
- Salesforce Developers, ISVforce Guide, Act on Security Review Results
- Salesforce Developers, ISVforce Guide, Security Review Stages
- Salesforce Developers, ISVforce Guide, Submit Your Solution for Security Review
- Salesforce Developers, ISVforce Guide, Listing Builder Overview
- Salesforce Developers, ISVforce Guide, Get Your Listing Approved
- Salesforce Developers, ISVforce Guide, Checkout Revenue Share
- Salesforce, Introducing the New AgentExchange
- Salesforce Newsroom, AgentExchange Launch Press Release
- Salesforce Newsroom, Headless 360 Announcement
- Salesforce Developers, ISVforce Guide, Introduction
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
- Salesforce Developers, ISVforce Guide, Apex in Group and Professional Editions
- Salesforce Developers, Second-Generation Managed Packaging, Target a Specific Salesforce Release
- Salesforce Developers, Second-Generation Managed Packaging, Push Upgrades
- Salesforce Developers, ISVforce Guide, Periodic Re-Reviews
- Trailhead, Review Your Work and Publish
