Building your own product on SalesforcePackaging, security review, distribution, from a team that has done it.
Building an application on Salesforce is a different discipline from implementing one. Packaging, namespaces, security review and licensing all sit outside normal admin and development work, and most of the pain arrives late. We have taken our own products through it and can shorten the path considerably.
What we have shipped
- AppExchange managed package
- @SignAppExchange managed packageSalesforce and Zoho Sign e-signature, distributed as @Core plus @Sign packages
- OEM application
- FamkosoftOEM applicationA full childcare platform built natively on the Salesforce Platform
- Open source tooling
- ASFX ToolkitOpen source toolingDeveloper tooling we built for our own packaging and deployment work
The honest version
Security review is where most first attempts stall
Teams comfortable with Apex and LWC are often surprised by the security review. It is not a code-quality check. It is an adversarial assessment against a specific standard, and the feedback arrives as a list of findings you must remediate before you can list at all.
What the review actually looks for
The recurring findings are consistent, and nearly all of them are cheaper to design for than to retrofit.
CRUD and FLS enforcement
Every object and field access checked against the running user's permissions. Code that assumes the user can see what the query returns is the single most common failure.
Injection-safe queries
Dynamic SOQL and SQL built without proper escaping or binding. Static analysis finds these immediately, so they are worth eliminating before you ever submit.
Output encoding
Cross-site scripting through unescaped values rendered in Visualforce or Lightning components, including anything sourced from an external system.
Secrets and endpoints
Hardcoded credentials, tokens in code or metadata, and outbound callouts to endpoints that are not properly declared and secured.
The path
From working code to a listing
Where the effort actually goes, in the order it arrives.
- 1
Decide the distribution model
ISV, OEM or an internal package. This choice drives licensing, pricing and how much of Salesforce your customers need to own, and it is expensive to reverse later.
- 2
Namespace and packaging
Register a namespace, structure the package, and decide between first- and second-generation packaging. We use 2GP for our own products.
- 3
Harden before you submit
Run static analysis and fix findings while the code is still fresh. Remediating during review costs far more than designing for it.
- 4
Security review
Submission, automated scanning, manual assessment, then remediation and resubmission if findings come back. Plan for it to take longer than you expect.
- 5
Listing and licensing
The AppExchange listing itself, plus licence management so you can provision, track and expire customer access.
- 6
Life after launch
Upgrades pushed to customer orgs, backwards compatibility, and support across environments you do not control.
Distribution
ISV, OEM or neither
The right model depends on whether your customers already run Salesforce, and how much of the platform you want to be responsible for.
| ISV (AppExchange) | OEM (embedded) | Unmanaged / internal | |
|---|---|---|---|
| Customer needs their own Salesforce licences | Supported | Not supportedPlatform is embedded in your product | Supported |
| Security review required | Supported | Supported | Not supported |
| You set the pricing model | Partially supportedAlongside their existing licences | SupportedYou sell one product | Supported |
| Suits a vertical application | Partially supported | SupportedHow Famkosoft is distributed | Not supported |
| Listed publicly on AppExchange | SupportedHow @Sign is distributed | Partially supportedOptional | Not supported |
Questions we get
About the review and the process
Can you review our code before we submit?
Yes, and this is usually the highest-value moment to involve us. Findings identified before submission are ordinary development work; the same findings after submission come with a resubmission cycle attached.
We failed the security review. Can you help remediate?
Yes. Bring the findings report and we will work through it. Most reports cluster around a small number of root causes repeated across the codebase, so the list is usually shorter than it looks.
Should we choose ISV or OEM?
It depends mainly on whether your customers already use Salesforce. If they do, ISV lets you sell alongside their existing investment. If they do not, and you want to sell a complete product without asking them to buy Salesforce separately, OEM is likely the better fit. We have shipped both.
Do you take over the product, or work alongside our team?
Either. Some engagements are a review and a set of recommendations; others are hands-on development alongside an in-house team. We are comfortable handing back.
Next step
Planning a Salesforce product, or stuck in review?
Tell us where you are. If you are pre-submission we can usually save you a cycle; if you already have findings, we will work through them with you.