What they cost, how to evaluate one, and whether you need to hire at all.
Building a listed AppExchange app takes Apex, Lightning Web Components, managed-package experience, and a security review most first-time teams fail. Here is what hiring for that actually costs in 2026, and the alternative worth pricing against it.
Built by ex-Salesforce AppExchange engineers
Founded by a former member of Salesforce's AppExchange team
An AppExchange developer builds commercial Salesforce apps that are distributed as managed packages and listed on Salesforce's marketplace. The work is different from ordinary Salesforce development: it requires second-generation packaging, namespace management, upgrade paths, and passing Salesforce's mandatory security review, which roughly half of first submissions fail.
In 2026, hiring one costs about $90 to $125 an hour onshore through a consultancy, or $35 to $70 an hour offshore depending on region. A complete commercial AppExchange app typically lands between $50,000 and $150,000.
Rates vary more by location than by skill, and more by security review experience than by either. These are published 2026 ranges.
| Where you hire | Hourly rate | What you get |
|---|---|---|
| Onshore US or UK, via consultancy | $90 to $125 | Developer. Architects run $135 to $170 |
| Onshore US, broad market range | $120 to $250+ | Wide spread by seniority and firm |
| Eastern Europe | $45 to $70 | Strong overlap with EU hours |
| Latin America | $40 to $65 | Nearshore, US timezone overlap |
| India | $35 to $55 | Widest quality spread, verify packaging experience |
| Complete commercial app | $50,000 to $150,000+ | Architecture, build, security review, listing |
The hourly number is the misleading one. Roughly half of first security review submissions fail, and a remediation cycle adds six to nine weeks of billable time that no rate card shows you. Price the review risk, not just the rate.
Two quotes for the same brief can differ by 3x. These are the variables that explain it.
Where the work happens
Offshore roughly halves the rate, from $90 to $125 onshore down to $35 to $70. It also widens the quality spread, so the saving is real only if you can verify managed-package experience specifically.
Seniority, not headcount
A developer runs $90 to $125 through a consultancy; an architect runs $135 to $170. An AppExchange build needs architect judgement early and developer hours later, and quotes that price it all at one rate are usually hiding which.
How standard your data model is
A sync onto standard objects is a different job from one that needs custom objects, unusual sharing rules, and governor limit planning. This is decided before any code exists and it sets everything after it.
Security review cycles
The multiplier nobody quotes. About half of first submissions fail, and remediation adds six to nine weeks of billable time. A cheaper rate that needs two cycles is not cheaper.
Who does the listing work
Partner Console setup, listing metadata, screenshots, and a demo org are real hours. Contracts that stop at code leave them with you, and they still have to happen before anything is listed.
What happens after launch
Three Salesforce releases a year can break a package. Agency maintenance retainers run $22K to $45K per year, and the alternative is your own team owning regression testing forever.
Bars rank how far each variable tends to move a quote. They order the list; they are not a measurement.
- 01
Ask for a listed app, not a portfolio
Anyone can show custom org work. Ask for a live AppExchange listing they packaged, and check it on the marketplace yourself.
A good answer names the listing and the namespace. A vague one talks about orgs they have worked in.
- 02
Ask their first-attempt security review rate
About half of submissions fail first time. Someone who has shipped several will know their own number and explain what they failed on.
A good answer is a number and a story. Anyone claiming they have never failed one has probably submitted once.
- 03
Confirm 2GP, not 1GP
Second-generation packaging is the current standard. A developer still defaulting to 1GP has not shipped recently.
A good answer explains why they would pick one over the other for your case, not just which one they know.
- 04
Separate org development from packaging
Custom Salesforce skills do not transfer automatically. Namespaces, upgrade paths, and version management are a distinct discipline.
Ask what breaks for an existing customer when you rename a field. If the answer is nothing, they are thinking in orgs.
- 05
Get IP ownership in writing
Who owns the package, the namespace, and the source when the engagement ends. Ambiguity here is expensive later.
Get it in the contract, not the call. The namespace is the part people forget until they try to leave.
- 06
Ask who handles the review submission
Some contracts stop at code and leave you to face Salesforce's questions alone. That is the hardest part.
A good answer says who replies to Salesforce and how fast. The queue moves at the speed of your slowest reply.
- 07
Agree the post-listing plan
Three Salesforce releases a year can break a package. Decide who maintains it before you launch, not after.
A good answer covers who tests against a release preview, and what it costs when something does break.
Each channel trades cost against how much of the vetting falls back on you. The packaging question from the checklist above applies to all of them.
Salesforce consulting partners
The safest option and the most expensive. Partner status says a firm does Salesforce work; it does not say they have packaged and listed an app, so the listed-app question still applies.
Freelance marketplaces
Deepest pool and widest spread. Filters surface Salesforce skill, not managed-package experience, so expect to sort through org developers to find someone who has shipped a package.
Referrals from other ISVs
The highest signal available, because someone with a listed app has already run the experiment you are about to run. Ask what their first submission failed on and who fixed it.
The Salesforce community
Community events and groups are where people who actually ship packages tend to be. Slower than posting a role, and it works better as a route to a referral than to a hire.
Offshore and nearshore agencies
Where the $35 to $70 rates live. The saving is real when the packaging experience is real, which is exactly the thing an hourly rate tells you nothing about.
Specialist recruiters
Fastest to a shortlist and priced accordingly. Brief them on second-generation packaging and security review explicitly, or you get Salesforce developers who have never published anything.
None of these show up in week one. They show up after the money is spent.
You hired a Salesforce developer, not a packaging one
Custom org skills do not transfer automatically. Namespaces, upgrade paths, and version management are a distinct discipline, and the gap only becomes visible when the first customer needs an upgrade. By then the fix is usually a rebuild of the packaging layer rather than a patch.
Review arrives after the budget is gone
Security review is the last gate, so a build that ignored its criteria fails at the point where there is least money and least patience left to fix it. Budget the review as part of the build rather than as a formality after it.
Nobody owns the submission
Some contracts end at code. Salesforce then sends questions to you, and the queue moves at the speed of whoever answers, which by then is a team that has never read the review criteria. Agree in writing who replies and within how long, before anyone starts.
The IP question was never written down
Who owns the package, the namespace, and the source is cheap to agree at the start and expensive to argue at the end. The namespace is the part people forget until they try to leave. One paragraph in the contract prevents the entire argument.
The package breaks and nobody is on it
Seasonal releases keep coming after the engagement ends. A listing that breaks is delisted quietly, and the first signal is usually a customer telling you. Someone has to own the release calendar before you launch, not after.
You cannot grade the work
Without Salesforce depth in house you are buying output you cannot evaluate. That gap is where most first-time review failures actually start, and it does not close by hiring faster. It closes by bringing in someone who has already shipped, in whatever form that takes.
Hiring is one of four ways to end up with a listed app, and it is the right one for some of them. The cost column is what you pay to get to a listing, not a running total afterwards, and the time column assumes the security review passes first time, which for about half of submissions it does not.
| Route | Cost | Time to listed | Best when |
|---|---|---|---|
| Hire in-house | $150K+ per year | 6 to 12 months | AppExchange is core to your roadmap long term |
| Freelance or contract developer | $35 to $125 per hour | Varies widely | You have Salesforce knowledge in-house to direct them |
| Agency or ISV partner | $50K to $150K+ | 6 to 12 months | Highly bespoke, complex multi-quarter builds |
| Done-for-you build partner | Flat quoted price | About 8 weeks | You need a listed native app without building a Salesforce team |
"We had zero Salesforce development experience, but still launched a fully functional managed package within a week."
Maximus Greenwald
CEO, Warmly.ai
- Engineers hired
- Engineers hired
- Spent on consultants
- Spent on consultants
- Build to done
- Build to done
- First-try review pass
- First-try review pass
Hiring is genuinely the right call in these situations. A page that pretended otherwise would not be worth the time it takes to read.
AppExchange is your product strategy
If the marketplace is a permanent channel rather than one launch, in-house capability pays for itself. A team that ships four apps learns things a build partner cannot hand over in a document.
The app is deeply bespoke
Heavy custom UI, unusual data models, or complex multi-cloud logic benefit from a dedicated team. The further you get from a standard integration shape, the more the daily judgement calls matter.
You already have Salesforce depth
If someone in-house can brief and review platform work, a contractor is efficient. Without that, you are buying work you cannot evaluate. That evaluation gap is where most first-time security review failures actually start.
"I spent years on Salesforce's AppExchange team, sitting across the table from more than 300 SaaS companies. I watched them fail security review over and over, for the same handful of reasons."
Co-founder and CEO. Previously Salesforce AppExchange team, and Salesforce Developer at Zennify.
Onshore through a consultancy, roughly $90 to $125 an hour for a developer and $135 to $170 for an architect. Offshore runs $35 to $70 depending on region. A complete commercial AppExchange app usually costs $50,000 to $150,000 once architecture, build, security review, and listing are included.
No. A done-for-you build partner delivers the managed package, handles the security review, and gets the app listed, with the source and IP handed to you. Warmly launched a fully functional managed package in a week with zero engineers hired and no consultants.
A Salesforce developer builds inside one customer's org. An AppExchange developer builds a distributable managed package for many customers, which adds namespace and packaging constraints, upgrade paths, and a mandatory security review that org work never faces. The skills do not transfer automatically.
Hiring itself takes weeks, and the build that follows runs 6 to 12 months for an agency engagement. The largest hidden variable is the security review: about half of first submissions fail, and remediation adds six to nine weeks that rate cards never show.
Offshore saves roughly half on rate but widens the quality spread, so verify managed-package experience specifically rather than general Salesforce skill. Nearshore in Latin America at $40 to $65 balances cost against timezone overlap. Onshore is worth it when you need tight collaboration and cannot direct the work yourself.
Yes, and it works when you have Salesforce knowledge in-house to brief and review the work. Without that, you are buying output you cannot evaluate, which is precisely where security review failures come from. Ask any freelancer for a live listing they packaged themselves.