Get through Security Review the first time.

Building for the AppExchange is not org work with a namespace on it. Packaging tier, namespace, edition compatibility and subscriber lifecycle are all expensive to reverse, and Security Review is where the unprepared lose a quarter. We have shipped managed packages through it, and we know which of those decisions bite.

Shape
Project, then retainer at launch
Typical length
12–24 weeks
Priced
Per phase
Starts with
A packaging decision
You keep
Package, CI pipeline, submission record
Proven by
Pledgivo

Twenty-four weeks to a listing, then it keeps going.

Drawn to scale
01Packaging decisionWeeks 1–21GP or 2GP, namespace registration, and how the package splits — settled before the first commit.
02BuildWeeks 3–16Multi-edition patterns, CRUD/FLS on every query and DML, scratch-org CI from day one.
03Review preparationWeeks 17–19PMD static analysis on an AppExchange-tuned ruleset, then a manual pass for XSS and SOQL injection.
04SubmissionWeeks 20–24We fill out the form, answer the reviewer, and coordinate resubmission if it comes back.
05Listing & licensingFrom week 22, ongoingLMA, trials that expire gracefully, seat enforcement, and the listing copy buyers respond to.
Drawn at the long end: twenty-four weeks. Security Review is the one stage whose length is not ours to set — the range on it is the queue, not the work. Packaging is decided in week one, because it is the decision that is expensive to reverse.

Everything a managed package needs.

Five areas

A package touches all five of these before it lists. The first one constrains the other four, which is why it is settled in week one rather than discovered in week twelve.

Packaging architecture

Choosing the right packaging strategy before writing code saves months of painful refactoring:

  • 1GP (First-Generation Packaging) — Namespace management, patch release process, push upgrades to subscribers, and component visibility settings
  • 2GP (Second-Generation Packaging) — Unlocked and managed packages, scratch org-based CI/CD, dependency management, and source-driven development
  • Namespace strategy — Selecting, registering, and using a namespace that works across all packaging tiers
  • Package splitting — Separating core, UI, and optional modules into independent packages for faster iteration

Security review preparation

Salesforce’s Security Review is a known bottleneck. We prepare you thoroughly:

  • PMD static analysis — Automated scanning with CloudAlgo-tuned ruleset for AppExchange requirements
  • Manual code review — Pattern-by-pattern review against the Salesforce Security Review Checklist
  • CRUD/FLS enforcement — Ensuring every SOQL query and DML respects object- and field-level security
  • XSS & SOQL injection — Identifying and remediating vulnerabilities in Visualforce, LWC, and Apex
  • Submission support — Filling out the submission form, responding to Salesforce reviewer feedback, and resubmission coordination

ISV licensing & entitlements

Monetizing your product through the marketplace requires LMA integration:

  • License Management App (LMA) — Setup, subscriber record management, and automated license checking in your Apex
  • Trial experiences — Time-limited trials with graceful expiry UX rather than hard errors
  • Seat-based licensing — Per-user license enforcement patterns that don’t break during renewals
  • Pricing tiers — Multiple edition architectures (Starter, Professional, Enterprise) with feature gating

AppExchange listing & go-to-market

A great product with a weak listing won’t convert:

  • Listing copy — Value proposition messaging, feature bullets, and category selection
  • Screenshot and demo video — Guidance on what Salesforce reviewers expect and what buyers respond to
  • Partner portal setup — Trailhead Partner Community, Environment Hub, and partner agreement navigation
  • Post-listing support — Subscriber onboarding flows, in-app guided setup, and support ticketing process

Ongoing product maintenance

AppExchange products require ongoing investment after launch:

  • Version management and backward compatibility across subscriber orgs
  • Salesforce release readiness testing (Spring/Summer/Winter releases)
  • Subscriber issue triage and resolution with namespace-aware debugging
  • Feature development and roadmap planning on a retainer basis

At launch

What you are left holding.

The package is yours. So is the pipeline that builds it, the record of what the reviewer asked, and the listing that sells it.

  1. The packageNamespace, metadata and version history in your own Dev Hub. We do not hold the keys to your product.
  2. The CI pipelineScratch-org creation, test runs and packaging on every commit, in your git, ready for the next release.
  3. The submission recordEvery question the reviewer asked and the answer that satisfied them. The document that makes resubmission cheap.
  4. The listingCopy, screenshots, trial flow and licensing set up in the Partner Console, under your account.