AppExchange 2005-2026: Twenty Years of the SaaS Marketplace Salesforce Invented

When Salesforce launched the AppExchange in September 2005 at Dreamforce, the press coverage was thin. The trade publications treated it as an integration directory, which is what it looked like on launch day. Behind the scenes, the team at Salesforce knew it was building a marketplace. Marc Benioff, in keynote remarks at the launch, called it “the eBay for enterprise software”. The framing was deliberate: a two-sided platform where independent software vendors sold packaged applications to Salesforce customers, with Salesforce taking a cut of the transaction and providing the infrastructure underneath.

The framing turned out to be the right one. AppExchange is now twenty years old and the template every other major SaaS marketplace copied. The Apple iOS App Store, which got most of the cultural credit for inventing the app marketplace concept, did not launch until July 2008, almost three years later. Atlassian Marketplace launched in 2012, the Shopify App Store in 2009, the Slack App Directory in 2014, and the Microsoft Teams store in 2017. Each of them owes the AppExchange a structural debt, whether or not the founding teams admit it.

This retrospective walks through the seven phases of AppExchange between 2005 and 2026: the original “eBay for software” pitch, the Force.com platform-as-a-service expansion, the Apex and Visualforce developer experience, the ISV economics that made the marketplace work, the Lightning components rebuild, the 2024-2026 agentic AI shift, and the lessons that other marketplace operators absorbed (sometimes painfully).

AppExchange launch September 2005: the “eBay for software” pitch

The original AppExchange went live on 14 September 2005, with about 70 partner applications listed at launch. The pitch was straightforward: Salesforce customers needed a way to find, install and pay for third-party applications that extended their CRM, and ISVs needed a distribution channel that put them in front of those customers.

The mechanics on day one were minimal compared to a 2026 marketplace. A listing had a name, a description, screenshots, a “Install” button, and a pricing page. Installation pushed metadata into the customer’s Salesforce org. Payments were generally handled directly between the ISV and the customer, with AppExchange functioning more as a directory than a transaction platform. The security review process (which would later become the AppExchange’s most important gatekeeping function) was lighter than the 2026 version.

What worked from the start was the distribution. Salesforce had roughly 16,000 customers by the end of 2005 and was growing fast. Every one of those customers had login credentials, an established trust relationship with Salesforce, and a tendency to extend rather than rip and replace. An ISV that could build a useful add-on (territory management, document generation, marketing automation, dialler integration) could put it in front of every Salesforce admin in the world through a single channel.

The first generation of AppExchange winners reflected this. Conga (document generation), Apttus (CPQ, later acquired by Conga in 2020), DocuSign (electronic signature, originally listed in 2007), Vlocity (industry CRM, acquired by Salesforce in 2020), Veeva (life sciences CRM, founded 2007, spun out, and IPO’d in 2013 as the most famous AppExchange-to-public exit) all built initial scale on Salesforce distribution before becoming standalone companies. The AppExchange functioned for them roughly the way Y Combinator’s demo day functions for current SaaS startups: a forcing function to get product-market fit, validated by paying customers, on a clock.

The marketplace’s first real test came in 2007, when Apple announced the iPhone and the industry’s attention turned to mobile. AppExchange was already producing meaningful ISV revenue by then. Salesforce was past 30,000 customers and the ecosystem was generating its own gravity. The decision to expand from a directory to a full platform-as-a-service was made the same year.

Force.com 2007: platform-as-a-service for ISVs building on top of Salesforce

Force.com launched at Dreamforce 2007 (September 2007) and changed what the AppExchange could host. The pre-Force.com AppExchange was a directory of integrations: an app could push metadata, create custom objects, and call out to Salesforce APIs. Force.com let an app run inside Salesforce. The shared multi-tenant database, the application server, the security model, the user interface framework: all of it was made available to ISVs.

The pitch was that ISVs could build full applications on the Salesforce platform and inherit:

• A multi-tenant database with row-level security already wired in.
• An identity and access management layer that customers already trusted.
• A user interface framework (initially called s-controls, then Visualforce) that produced applications visually consistent with Salesforce itself.
• A deployment model where the app got installed into the customer’s org with one click.
• A packaging system that let the ISV ship versioned upgrades.

The trade-off was that the app ran in Apex, the proprietary Salesforce programming language, with Salesforce governor limits on CPU time, heap size, query rows, and DML operations. The app was portable to no other platform. The lock-in was real and explicit. (Our 2008 essay Lock-In is Inevitable was written from inside Salesforce during exactly this period, defending the trade-off against contemporaneous criticism.)

The first wave of Force.com applications proved the bet worked. Salesforce reported that within 18 months of the platform launch, several hundred ISVs had built native applications on the platform, and the ones that adopted it (FinancialForce in financials, Veeva in life sciences, ServiceMax in field service) hit revenue scales that the pre-Force.com directory model would not have supported.

Force.com also produced one of the most consequential architectural decisions in SaaS history: the metadata API. The platform was metadata-driven from the start. Customisations (objects, fields, layouts, workflows, validation rules) were represented as metadata XML, not as code. The metadata API let tools, ISVs and customers programmatically read, deploy and migrate that metadata. Twenty years later, the entire Salesforce DevOps tooling ecosystem (Copado, Gearset, Flosum, Salesforce DX, every CI/CD pipeline for the platform) rests on the metadata API. The 2007 decision is still load-bearing in 2026.

Apex + Visualforce 2008-2014: the proprietary developer experience

The Apex) language was made generally available in 2007 as part of the Force.com release, and the Visualforce UI framework followed in early 2008. Together they formed the proprietary developer experience that ISVs had to learn to build serious applications on the platform.

Apex looked, syntactically, like a stripped-down Java with database operations as first-class language constructs. A developer could write a SOQL query (Salesforce’s SQL variant) directly in Apex code without an ORM. Triggers, batch jobs, scheduled jobs, web service callouts, all of it was native to the language. The runtime ran inside Salesforce’s shared infrastructure, with strict governor limits to prevent any one tenant from consuming the cluster.

The governor limits were the visible cost of multi-tenancy. A single Apex transaction could not consume more than 100 SOQL queries, more than 150 DML statements, more than 6 megabytes of heap, or more than 10 seconds of CPU time. ISVs who built complex applications spent significant engineering effort working within these limits, often refactoring iterative algorithms into batch jobs or asynchronous queues. Every Salesforce architect of the 2008-2018 generation has a story about a bulk DML refactor.

Visualforce was the matching UI framework. Pages were defined in a tag-based markup language similar in spirit to JSP or ASP.NET, with Apex controllers behind them. The framework was opinionated, integrated tightly with the platform, and produced applications that looked and behaved consistently with the rest of Salesforce. It was also, by 2014, considered dated. The page model was server-rendered, the developer ergonomics were uneven, and the modern web (jQuery moving to React, single-page applications becoming the norm) was leaving it behind.

The technical debt of Visualforce became a problem for the AppExchange. ISVs who had built their apps on Visualforce found themselves locked into a UI framework that customers no longer wanted, and which Salesforce itself was preparing to replace. The transition out of it took most of a decade.

ISV economics: revenue share, platform tax, certification requirements

The economics of being an AppExchange ISV are the part of the story that gets least public coverage, partly because the revenue share numbers are negotiated case by case and partly because Salesforce treats the exact terms as confidential. The publicly reported ranges, from industry surveys and ex-employee accounts, look roughly like this:

• Standard ISV revenue share on AppExchange-checkout listings: typically 15 to 25 percent of the ISV’s subscription revenue, depending on partner programme tier and listing type.
• Co-sell or AppExchange-distributed listings with Salesforce field-team involvement: revenue share rises, sometimes to 30 percent or more, in exchange for active sales support.
• Managed Package License (MPL) fees and annual partner programme fees: additional fixed costs, generally in the low thousands of dollars per year for the small partner tier and significantly higher for the strategic partner tier.
• Security review costs: the AppExchange security review process is mandatory for all listed apps, takes weeks to months on first submission, and frequently requires architectural rework to pass. The review covers OWASP-style application security, data isolation, and Salesforce platform best practices.

The trade-off the ISV signs up for is a meaningful platform tax (call it 15-30 percent depending on the deal) in exchange for distribution to the Salesforce customer base, integration with the platform’s identity and data layer, and the AppExchange brand association as a quality signal. For verticals where the Salesforce installed base is the addressable market (sales operations tooling, customer success platforms, CPQ, document generation), the trade-off is generally worth it. For verticals where the addressable market is broader, the platform tax can become a strategic problem if it constrains the ISV’s ability to compete outside the Salesforce ecosystem.

The pattern that emerged is one that every other major marketplace operator (Apple, Google Play, Shopify, Atlassian, Microsoft) replicated with different numbers. The standard tax is 15-30 percent. The standard exchange is distribution plus integration plus a quality signal. The standard friction is a review process that the ISV has to invest engineering time to satisfy. The 2026 founder weighing whether to list on a vertical marketplace is weighing approximately the same equation Salesforce ISVs weighed in 2007.

Lightning Component Framework 2014 + the modern App Builder

By 2014 the Visualforce-era developer experience was clearly past its peak. The web had moved to single-page applications, the mobile browser was driving real product traffic, and the Visualforce server-rendered model was generating UX friction. Salesforce announced the Lightning Component Framework at Dreamforce 2014 and started a multi-year rebuild of the platform UI.

Lightning was a client-side, component-based framework, initially built on a Salesforce-specific runtime called the Aura framework. In 2018 Salesforce announced Lightning Web Components (LWC), a re-platforming of Lightning onto the W3C Web Components standard. LWC has been the recommended way to build Lightning UI ever since, with a documented migration path away from Aura.

For ISVs the Lightning transition was disruptive. Visualforce applications continued to work (and many still do in 2026, with Salesforce maintaining backward compatibility) but no longer received feature investment. The path forward for any seriously-maintained AppExchange app was to rebuild the UI in Lightning components. The rebuild took years for large apps and was paid for partly by Salesforce co-investment programmes and partly by ISVs eating the migration cost.

Alongside Lightning, Salesforce shipped the Lightning App Builder, a drag-and-drop interface for assembling Lightning pages out of components. The App Builder lowered the barrier to creating custom layouts and home pages without writing code, and produced a meaningful expansion of what Salesforce admins (versus developers) could build. The component model also gave ISVs a new product surface: shipping individual Lightning components for sale on the AppExchange, rather than full managed-package applications.

The Lightning era also produced the Salesforce Mobile App, the Trailhead learning platform (launched 2014), and the long process of bringing the Salesforce UI to parity with modern web application expectations. The platform of 2018-2023 looked and behaved meaningfully different from the platform of 2007-2014, even if the underlying data model and security architecture were the same.

AppExchange 2024-2026: agentic apps, AI-native ISVs, the Agentforce ecosystem

The current phase of AppExchange started in late 2024, when Salesforce launched Agentforce as a productisation of agentic AI on top of the Salesforce platform. The shift is consequential for ISVs because the unit of value sold through the marketplace is changing.

The pre-2024 AppExchange sold configuration applications. An ISV shipped a managed package, the customer installed it, the package added objects, fields, workflows and UI components to the customer’s org, and the customer paid a subscription for the right to keep using it. The value capture was per-seat or per-org. The user interacted with the application through clicks.

The 2024-2026 AppExchange increasingly sells agentic applications. An ISV ships an Agentforce agent (or a topic, a skill, an action) that the customer’s users invoke through natural language, sometimes through the Salesforce UI, sometimes through Slack, sometimes through email or voice. The unit of value is the action the agent takes, not the click the user performs. The pricing model is shifting accordingly, with usage-based and outcome-based pricing becoming more common.

For ISVs the implications are significant:

• The product surface shifts from custom objects and Lightning components to agent topics, prompt templates, action definitions, and data integration patterns.
• The competitive advantage of having deep data inside Salesforce becomes larger, because the agent’s reasoning quality depends on the data it can reach. ISVs with proprietary data assets that they bring into the platform gain leverage.
• The security review process expands to cover agent behaviour, prompt injection risk, and data exposure through generated outputs.
• The revenue share model is being renegotiated for actions and outcomes rather than subscriptions. The exact economics of agentic AppExchange listings in 2026 are still being settled and vary by partner programme.

The broader question for the Salesforce ecosystem (covered in our Salesforce 2003-2026 retrospective) is whether the value capture stays at the platform layer or migrates to the agent layer. The AppExchange ISVs are the ecosystem’s most exposed constituency to that question. The 2026 ISV roadmap is, in many cases, a bet on which layer the customer will pay for over the next five years.

What the AppExchange pattern taught everyone else

The structural template AppExchange wrote down in 2005-2010 was copied, with variations, by essentially every major SaaS marketplace that came after. The variants worth noting:

• Apple iOS App Store (July 2008). The headline-grabbing one. Charged 30 percent revenue share initially, dropped to 15 percent for small developers under a $1 million annual cap in 2021, retained the security review and platform integration model. The cultural credit for “inventing” the app marketplace concept usually goes to Apple, despite Salesforce having shipped the same pattern three years earlier.
• Shopify App Store (2009). Closer to AppExchange in spirit than the iOS App Store, because the customer is a business operator buying apps to extend a SaaS platform. Revenue share is 0 percent on the first $1 million per developer per year (introduced 2021) and 15 percent after that, distinctly lower than AppExchange.
• Atlassian Marketplace (2012). The closest direct copy of AppExchange. Revenue share is 25 percent, the listing model is similar, the security review is similar, and the ISV economics are recognisable. Atlassian Marketplace passed $1 billion in lifetime ISV payouts in 2021.
• Slack App Directory (2014) and Microsoft Teams store (2017). Smaller in revenue terms but structurally identical: directory of apps that integrate with a SaaS platform, with the platform vendor taking a cut.
• Stripe App Marketplace (2022). The most recent canonical copy, launched 17 years after AppExchange, with mostly the same mechanics.

The AppExchange’s own data points, where Salesforce has published them: roughly 7,000 listed apps by 2024, about 10 million installs cumulatively, and a reported $7.7 billion in ecosystem revenue (the figure most commonly cited in Salesforce partner programme materials). The marketplace remains, in 2026, the gold-standard reference for any SaaS company considering whether to launch its own platform.

The five major SaaS marketplaces that copied the AppExchange template, compared on the same axes, make the structural pattern unambiguous:

What the 2003-2010 SaaS pioneers (covered separately in our pioneers playbook) figured out about distribution, viral growth and customer success applies to the marketplace operator question as much as it does to the standalone SaaS company. AppExchange’s twenty-year survival is one of the cleanest demonstrations that the patterns that worked in 2005 still mostly work in 2026, with the agentic AI overlay being the most consequential delta.

FAQ

When was AppExchange launched?

Salesforce AppExchange launched on 14 September 2005, at the Dreamforce 2005 conference in San Francisco. At launch the marketplace had roughly 70 partner applications. By 2024 it had crossed 7,000 listed apps and a reported $7.7 billion in ecosystem revenue, making it one of the largest commercial SaaS marketplaces in operation.

What is Force.com?

Force.com was the Salesforce platform-as-a-service, launched in September 2007 at Dreamforce, designed to let ISVs and customers build full applications on the Salesforce infrastructure rather than just integrating with the CRM. It included the Apex programming language, the Visualforce UI framework, the metadata API, and a shared multi-tenant database. The “Force.com” branding was retired in 2018 in favour of “Salesforce Platform”, but the underlying technology stack has continued to evolve under the new name.

What does ISV mean?

ISV stands for Independent Software Vendor. In the AppExchange context, an ISV is a third-party company that builds and sells software on top of the Salesforce platform, distributing it through the AppExchange marketplace. ISVs are distinct from system integrators (who customise Salesforce for end customers) and from consulting partners (who deliver services rather than packaged software). The ISV partner programme has multiple tiers, each with different revenue share terms, support entitlements, and certification requirements.

How much does Salesforce take from AppExchange apps?

AppExchange revenue share has shifted over the years and depends on the partner programme tier and the type of listing. The headline numbers reported in industry surveys range from 15 percent for some legacy and consulting partner programmes to 25 percent for the standard ISV revenue share on managed packages. The exact percentage depends on the contract, the listing type, and whether the app is sold through the AppExchange checkout or co-sold through the Salesforce field. For comparison, the iOS App Store charges 30 percent (or 15 percent for small developers), the Atlassian Marketplace charges 25 percent, and the Shopify App Store charges 0 percent up to $1 million in annual developer revenue.