Your Salesforce Developer Is Not an AppExchange Developer, and the Gap Costs About Six Weeks

Everyone who has ever cooked a great dinner party has, at some point, been told they should open a restaurant.

It is a compliment, and it is also terrible advice. The cooking is maybe a quarter of a restaurant. The rest is a health inspection, food that survives being made two hundred times a night, a supply chain, and someone whose entire job is the paperwork. A person can be genuinely excellent at the cooking part and still be nowhere near ready for the other thing.

That is more or less the exact gap between a Salesforce developer and an AppExchange developer, and it is the single most expensive misunderstanding in the ISV world. The code looks the same. Apex is Apex. But one person is building inside one org that they can see, log into, and hotfix on a Tuesday afternoon. The other is shipping a sealed package into orgs they will never lay eyes on, with a namespace they cannot rename, an upgrade path they cannot break, and a mandatory Salesforce security review standing between them and the marketplace.

Anyway. If you are about to hire for this, here is what the job actually involves, what it costs in 2026, and the questions that tell you within ten minutes whether the person across the table has ever shipped one.

What the marketplace asks for that org work never does

Custom org development is a real skill, and none of the following shows up in it.

Second generation packaging. 2GP is the current standard. Source driven, CI friendly, no packaging org required. If a candidate still reaches for 1GP by default, they have not shipped anything recently. It is a fine tell.

Namespaces you are married to. Pick one, and every object, field, and class in your package wears it forever. There is no rename. There is barely a divorce.

Upgrade paths. Ask any candidate what happens to an existing customer when you rename a field in a released package. In an org, the answer is "not much". In a managed package, the honest answer involves a version, a deprecation, and a small amount of praying. If they say nothing happens, they are thinking in orgs.

The security review. This is the health inspection. It is mandatory, it is thorough, and roughly half of first submissions come back with findings. That last number is the one that quietly runs your budget, and I will come back to it.

Three releases a year, forever. Spring, Summer, Winter. Each one can break your package after everyone has gone home. Someone owns the release calendar or nobody does, and "nobody does" tends to be discovered by a customer.

What it costs in 2026

Rate ranges move more by geography than by skill, and more by security review experience than by either.

The hourly figure is the misleading one, though, and here is why. About half of first security review submissions get sent back. A remediation cycle runs six to nine weeks, and those weeks are billable. So a cheaper rate that needs two passes at the review is not actually a cheaper rate, it is the same money spread over a worse quarter. There is a fuller cost and vetting breakdown if you want to hire AppExchange developers with the review risk priced in rather than discovered later.

Price the cycles, not the rate. That is the whole trick.

Six questions that sort the shippers from the org developers

You do not need a technical panel for this. You need six questions and the patience to listen to how they answer.

1. Show me a live listing you packaged. Not a portfolio. Not a deck of org screenshots. A listing on the marketplace, with a namespace, that you can go and look at yourself right now. A good answer names both. A vague one talks about orgs they have worked in.

2. What is your first attempt security review pass rate? Anyone who has shipped a few knows their own number and can tell you what they failed on. Anyone claiming a spotless record has probably submitted once. The story matters more than the number, honestly. Someone who says "we got sent back on session ID storage and CRUD checks, took five weeks" has been there.

3. 2GP or 1GP, and why for my case? You are not testing whether they know the acronyms. You are testing whether they can explain a tradeoff instead of naming the one they are comfortable with.

4. Who replies to Salesforce? Some contracts stop at code and hand you the review correspondence, which is the hardest part of the whole thing. The queue moves at the speed of your slowest reply, so find out whose inbox it lands in and how fast they answer.

5. Who owns the package, the namespace, and the source when this ends? Cheap to agree at the start, brutal to argue at the end. The namespace is the line everyone forgets until they try to leave. Put it in the contract, not on the call.

6. What happens in February? Meaning the next seasonal release. Who tests against the preview, who fixes it when a package breaks, and what that costs. Agency maintenance retainers tend to land somewhere around $22K to $45K a year, which is worth knowing before launch rather than after.

If someone answers four of these well, you are probably fine. If they answer all six with specifics and a slightly weary tone, hire them immediately, because that tone only comes from having been through a review.

Where these people actually are

Consulting partners are the safest and priciest route, but partner status says a firm does Salesforce work, not that it has ever packaged and listed an app. The listed app question still applies, every time.

Freelance marketplaces have the deepest pool and the widest spread. The filters can surface Salesforce skill. They cannot surface packaging experience, so you will sort.

Referrals from other ISVs are the highest signal available anywhere, because someone with a live listing has already run the exact experiment you are about to run. Ask them what their first submission failed on and who fixed it. Two questions, enormous return.

And the community, meaning user groups, Dreamforce hallways, the Trailblazer crowd, is generally better as a route to a referral than as a route to a hire.

When hiring is right, and when it is not

Hiring is genuinely the correct call in three situations. When the AppExchange is your product strategy rather than one launch, because in-house capability compounds across apps. When the app is deeply bespoke, with heavy custom UI or unusual data models, because the daily judgement calls matter more the further you get from a standard shape. And when you already have Salesforce depth in-house to brief and review the work.

That third one is the quiet condition on the other two. Without someone who can grade the output, you are buying work you cannot evaluate, and that evaluation gap is where a surprising share of first time review failures actually begin. It does not close by hiring faster.

If none of those three describe you, the honest answer is that hiring may be solving the wrong problem. A B2B SaaS company that needs one solid native app on the marketplace, and does not want a permanent Salesforce team attached to it, has other routes. Done-for-you AppExchange development delivers the managed package, carries the security review, and hands over the source and the namespace, which for a lot of teams is the actual goal rather than owning the capability.

Both routes end with a listing. They just cost different things, and the thing they cost most is not always money.

The one line to take away

Before you sign anything, ask for a live listing and a first attempt review number. Two questions, about ninety seconds, and they will tell you more than any portfolio ever will.

Great home cook, great restaurant, wonderful things. Just not automatically the same person.