Here’s a number worth sitting with before you write a line of code: roughly half of first-time security review submissions fail.
Not half of the bad ones. Half of all of them. Products built by capable teams, tested, working, ready to sell. They arrive at Salesforce’s front door and get turned away, then wait weeks in the queue to try again.
If you’re an ISV founder with your eye on the AppExchange, none of that should put you off. The marketplace is real. More than 150,000 Salesforce customers browse it, and they arrive with budget and intent. A listing there is one of the fastest routes to enterprise buyers an Australian software company can find. But the path from “we have a product idea” to “we’re live on the AppExchange” is longer and stranger than most founders expect, and the guides that gloss over the hard parts do nobody any favours.
So here’s the honest version. As Australia’s longest-running certified PDO, we’ve walked this road with enough product teams to know where people trip.
Step one: you’re joining a partner program, not uploading an app
The mental model most founders bring is the App Store. Build the thing, submit the thing, wait for approval. The AppExchange doesn’t work like that.
Before Salesforce looks at your product, you become a Salesforce partner. That means signing up for the Partner Community, accepting the Salesforce Partner Program Agreement, and submitting a business plan for review. Salesforce is deciding whether it wants a commercial relationship with your company, not just whether your app compiles.
Then comes the commercial agreement itself. For most paid apps, Salesforce takes a revenue share, typically 15% of what you earn through the platform. You’ll negotiate and execute a Partner Application Distribution Agreement (PADA) before you can sell anything. You’re only officially an AppExchange ISV once that agreement is fully signed.
Founders regularly budget zero weeks for this stage. Budget several. The ISV onboarding guide walks through every milestone, and it’s worth reading before you commit to a launch date.
Step two: your product has to become a managed package
This is where AppExchange development stops being ordinary software development.
You can’t list a folder of code. Your product needs to be built as a managed package, Salesforce’s format for distributable, upgradeable, IP-protected applications. That decision shapes your architecture from day one. How you handle namespaces, how you structure upgrades, how your app behaves inside a customer’s org alongside whatever chaos already lives there. These aren’t things you bolt on at the end. They’re foundations.
We’ve met teams who built a genuinely good product on the platform, then discovered that restructuring it as a managed package meant rebuilding a third of it. The product worked. It just wasn’t built the way a distributable product has to be built. That’s an expensive lesson, and it’s completely avoidable if someone who’s shipped managed packages before is in the room when the architecture gets decided.
There’s also a quieter question hiding in here: which ISV technologies does your commercial model need? License management, feature management, channel order handling. Getting these right early is the difference between a product you can actually sell at scale and one where every new customer means manual admin.
Step three: the security review. The famous one.
Every managed package on the AppExchange passes through Salesforce’s security review. It’s a genuine code and behavioural audit run by Salesforce’s Product Security team, and it’s the single biggest reason launch dates slip.
The practical facts, current as of 2026:
The fee is US$999 per submission attempt for paid apps. Free apps pay nothing. And “per attempt” is doing real work in that sentence. Fail, fix, resubmit, and you pay again. Salesforce’s own training materials note that most submissions pass on the second attempt, which is a diplomatic way of saying most fail the first.
Timelines run about four to six weeks for the initial review once you’re in the queue, longer during busy periods, plus a few more weeks for each resubmission. If your go-to-market plan assumes you’ll be live next month, the review alone will break it.
What do they check? Injection vulnerabilities, insecure data access, missing CRUD and field-level security enforcement, weak session handling, how your external endpoints behave. If your app touches AI, expect scrutiny there too. The reviewers assume a hostile actor will one day probe your app for a way into a customer’s data, because one day, one will.
The uncomfortable pattern we’ve seen: the review doesn’t fail products because they’re insecure in some dramatic, headline way. It fails them on discipline. A SOQL query without a bind variable here. A controller that skips a sharing check there. Small things, individually. Collectively, a failed review, a US$999 resubmission and a six-week delay while your sales pipeline waits.
The teams that pass first time aren’t lucky. They wrote secure code from the first sprint because someone on the team knew exactly what the review looks for and treated it as the spec, not an exam to cram for.
Step four: the listing itself, which is a marketing job
Passing security review earns you the right to publish. It doesn’t earn you customers.
Your AppExchange listing is a sales page competing with thousands of others. Category selection, screenshots, demo videos, pricing display, the first sentence of your description. This is where product companies suddenly need marketing muscle, often at the exact moment the engineering budget is exhausted.
And pricing brings its own homework. You’ll define your pricing model in the Partner Console, and if you want customers to buy directly through the listing, there’s payment infrastructure to connect and plans to sync. None of it is hard. All of it takes time nobody scheduled.
Step five: the part nobody tells you about, which is that you’re never done
An AppExchange listing isn’t a certificate you frame. Salesforce typically re-reviews solutions annually, and the Product Security team can request a review at any time. Every major release needs to hold the same security standard. The platform itself moves three times a year, and your product has to move with it.
Which means the real question isn’t “can we get listed?” It’s “can we run a product business on this platform for the next five years?” The AppExchange rewards companies who answer that honestly before they start.
So what does the whole journey look like?
Realistically, for a well-run team with platform experience: a few weeks of partner onboarding and commercial negotiation, a build phase measured in months, four to six weeks minimum for security review (double it if you fail once), then listing setup and launch. For a team learning the platform’s rules as they go, stretch every one of those numbers.
That gap between the two versions is exactly why the PDO model exists. A Product Development Outsourcer is a partner certified by Salesforce specifically to build commercial products on the platform, which is a different discipline to building internal Salesforce solutions. There are only a handful of certified PDOs in Australia. We’re the longest-running one, and the reason ISVs come to us usually isn’t that they can’t build. It’s that they can’t afford to learn the AppExchange’s rules by breaking them, one US$999 resubmission at a time.
If you’re weighing up an AppExchange product, the cheapest conversation you’ll ever have is the one before the architecture is locked in. Talk to our PDO team and we’ll give you a straight read on what your path to listing actually looks like, including the parts you won’t enjoy hearing.
