Build a Salesforce Managed Package Without a Salesforce Developer

You can ship a Salesforce managed package without hiring a Salesforce developer, as long as someone who has already shipped one does the platform work and your company owns the accounts the package lives in. The hire is rarely the real requirement. What a SaaS company needs is a builder who knows second-generation packaging and the security review, and a setup where the namespace, Dev Hub and listing stay yours if that builder changes.

Most B2B SaaS teams that sell into Salesforce customers have product engineers, not Salesforce developers. The native app matters because enterprise buyers ask for it, and it often sits between your team and a signed deal. At Appnigma, our marketplace apps team of ex-Salesforce engineers builds the app, prepares it for review and keeps shipping versions, so your engineers stay on your product. If you only need the definition first, start with what a managed package is.

Updated October 2026. Checked against Salesforce's second-generation packaging guide, the ISVforce Guide security review pages and the secure coding guide. This version adds the ownership setup to insist on, the code coverage and review timing Salesforce documents, and a list of questions for any builder. AppExchange is now part of the unified AgentExchange storefront, so this post uses both names.

What building a managed package actually involves

Before comparing who builds it, it helps to know the work, because it is more than writing Apex. A managed package is the upgradeable, namespaced bundle customers install into their own Salesforce org, and Salesforce says "we recommend that everyone use managed 2GPs to create new apps" in Use Managed Packages to Develop Your Solution. Second-generation packaging (2GP) is source-driven, which means your version control repository, not an org, is the source of truth.

The partner program, PBO and namespace rows are yours to set up whoever builds. The Partner Business Org (PBO) is the internal Salesforce org Salesforce provisions when you join the Partner Community, per Salesforce Partner Business Org. The coverage rule comes from Code Coverage for Second-Generation Managed Packages, which also says "every Apex Trigger in a package needs test coverage." The rest is the engineering you are deciding how to staff.

Hire, agency or done for you

There are three realistic ways to get the engineering rows done when nobody on your team writes Apex today.

Hiring makes sense when the Salesforce app is a product line you will grow for years. It is the slowest start and the most expensive per month. The Salesforce Ben developer salary guide surveyed 2,316 respondents across 76 countries. It puts the US median at $94,500 for juniors and $140,000 for seniors. Intermediate developers sit at $120,000. And 91.3% felt the market had become more challenging. Packaging and review experience is a narrower skill than general Salesforce development, so check for it specifically. Our guide to hiring an AppExchange developer covers rates and vetting if you go this way.

An agency fits a fixed spec. Ask in writing who prepares the review submission, who answers findings, and what each change costs after launch.

A done-for-you build gives you a named engineer who builds, ships and maintains the app with you as a scoped project. It fits when a deal is waiting on the app and you don't want a Salesforce team on payroll yet.

What your company must own, whoever builds it

Ownership is the decision most SaaS teams skip, and it is the hardest one to undo. In 2GP, the Dev Hub that creates a package owns it. Salesforce says the Dev Hub "becomes the owner of every managed 2GP package you create," per Enable Dev Hub and Second-Generation Managed Packaging, and partners "should designate their Partner Business Org (PBO) as their Dev Hub org."

The namespace is just as permanent. "After you associate a namespace with an org, you can't change it or reuse it," per Link a Namespace to a Dev Hub Org. Every component in the package carries that prefix in every customer org.

So set it up this way from day one. Your company joins the partner program, holds the listing and enables Dev Hub in its own PBO. Register the namespace in a Developer Edition org your company controls, and keep the source in your own GitHub or GitLab organization, because with 2GP the repository is the package.

The builder then works inside your Dev Hub. A PBO includes 100 Salesforce Limited Access - Free licenses meant for people who "build customizations or applications," per Limited Access License for Package Developers, so adding an outside engineer costs no license.

If a builder creates the package in its own Dev Hub instead, getting it back means a transfer. Salesforce says transfers "are only available for managed 2GP packages that have passed AgentExchange security review," per Transfer a 2GP to a Different Dev Hub, so a package stuck before review can't move at all.

What a done-for-you build looks like at Appnigma

A done-for-you project runs in five steps, inside your own PBO and Dev Hub.

1. Scope the app. Agree what it does inside Salesforce, the objects and fields, permissions, customer field mappings and any backend changes on your side.
2. Approve the technical plan. Nothing gets built until you sign off. Our done-for-you page sets the target at "one to three weeks after approval of the technical plan," with complexity, access and backend dependencies affecting timing.
3. Build and test. The engineer builds the 2GP package. That covers the data model, Apex and Lightning Web Components, plus permission sets and the connection to your API. Testing runs in scratch orgs and sandboxes, and changes to your codebase arrive as pull requests for your review.
4. Prepare the security review. Code Analyzer reports, documentation, the test org, listing materials and responses to any findings.
5. Launch and maintain. Install docs for your customers' admins, then new versions as your product and Salesforce change, under a separate maintenance retainer.

Your team's share stays small. Warmly's total engineering involvement was 40 hours, "mostly in requirements calls," and Salesbricks reported no engineering sprints diverted to the Salesforce package, both per the marketplace apps page.

How long it takes from kickoff to listing

A managed package has two clocks, and only one of them is the build. Salesforce's security review runs on its own estimate. How the AgentExchange Security Review Works lists 1 to 2 weeks for verification and 3 to 4 weeks for the first test, and Act on Security Review Results says the review is complete approximately 4 to 6 weeks after you submit.

Here is the arithmetic from those published estimates. A build of 1 to 3 weeks plus a first review of about 4 to 6 weeks puts a first-pass listing roughly 5 to 9 weeks after the plan is approved. A failed first round adds a resubmission test, which Salesforce estimates at 2 to 3 weeks on the same page, plus your fix time. That is why the review is where experience pays.

Warmly is one real example. Its native Salesforce app took two weeks to build, and the launch took eight weeks from kickoff, "including six weeks of Salesforce security review," per Warmly's story and the marketplace apps page. Salesforce controls queue time and approval, so treat it as an example, not a promise.

Two timing details catch teams out. Beta versions "can be installed in only scratch orgs and sandboxes," per Get Ready to Promote and Release, so a prospect can't run a beta in production. And "your PADA must be signed before you can submit your solution for Security Review," per the ISV onboarding guide, so start the partner paperwork during the build, not after it.

Can a Salesforce admin build a managed package?

Yes, for a first-generation (1GP) package. An admin can create one in Setup through Package Manager, per Create a First-Generation Managed Package Using a UI, and a package of objects, fields and flows needs no Apex. For a new commercial listing, though, the recommended path is 2GP. It runs on Salesforce CLI and version control, with Apex tests behind every version. And a SaaS integration almost always needs Apex to call your API and handle errors and retries.

The admin is still valuable. Someone who knows how your customers use Salesforce is the right person to scope the objects, fields and permissions, and to test the app the way a customer's admin will. Pair that knowledge with an engineer who has shipped packages and you have the whole team.

Mistakes that send a package back from security review

Salesforce's own ranking of failure reasons, in The Top 20 Vulnerabilities Found in the AppExchange Security Review, puts object and field-level security first "by a significant margin." The patterns below come from that list and the current secure coding guide.

• Queries that skip the user's permissions. Apex runs "in system mode with full CRUD access" by default, per Protect Your Application from CRUD/FLS Vulnerabilities. Salesforce suggests WITH USER_MODE, and "WITH SECURITY_ENFORCED isn't allowed in AppExchange packages."
• Old JavaScript libraries. An outdated library, most often jQuery, is the second most common finding.
• Sharing violations. Apex classes that ignore record sharing come third.
• Secrets in code. The post says to make sure "there are no secrets hardcoded into the source code, even if it's a managed package."
• Weak TLS on your own endpoints. If your API endpoints don't get an A grade for SSL/TLS, the review is not approved.
• Submitting without scanning first. Code Analyzer reports are required, though Salesforce says "it's not necessary for the scans to be 100% passing," per Produce Code Analyzer Reports. Explain each remaining finding instead.

Most of these are access control and input handling applied the same way in every class. Our security review checklist goes deeper.

Questions to ask any builder before you sign

Whichever route you pick, these questions separate a builder who has shipped packages from one who has built inside a single company's org.

• Will you build in our Dev Hub and our repository, under a namespace registered in our Developer Edition org?
• How many 2GP packages have you taken through the security review, and how many passed on the first submission?
• Who writes the Code Analyzer false-positive explanations and answers the review team's findings?
• How do you test against the editions and settings our customers run, not just one developer org?
• Who ships the next version when Salesforce releases an update or our API changes, and on what terms?

If the answers are vague on the first or last question, the cost shows up after launch, when you need a change and don't control the package.

Frequently Asked Questions

Can I build a managed package if no one on my team writes Apex?

Yes. An experienced Salesforce engineer writes the Apex, Lightning Web Components and tests inside your Dev Hub, and your team supplies requirements, access and reviews.

Do I need to be a Salesforce partner to publish a managed package?

For a public listing, yes. Salesforce says "you must be a Salesforce partner" to make a solution publicly available, joining is free, and a solution that doesn't pass the security review can't be listed or distributed.

Does the security review care who wrote the code?

No. The review tests the package against the same requirements whoever built it, so access control, sharing and secure storage have to be right in every component.

How much does the security review cost?

Salesforce charges a review fee for paid solutions and none for free ones, and there's a fee to retest a remediated solution. Check the current amount in your Partner Console before you budget.

Can Appnigma build and maintain our managed package?

Yes. Appnigma's marketplace apps team builds the native app, prepares the listing and review, and covers ongoing fixes and upgrades under a separate maintenance retainer agreed upfront.

Ship the package without building a Salesforce team

You don't need a Salesforce developer on payroll to ship a managed package. You need the package owned by your company, a builder who has taken 2GP packages through the security review, and a plan for every release after launch. If an enterprise deal is waiting on a Salesforce app, book a demo and bring the buyer's requirements.

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Related Articles

• What Is a Managed Package in Salesforce?
• How to Create a Salesforce Managed Package (2GP)
• Salesforce Security Review Checklist
• How Long the Salesforce Security Review Takes
• Salesforce App Development Cost

Sources

1. Salesforce Developers, ISVforce Guide, Use Managed Packages to Develop Your Solution
2. Salesforce Developers, ISVforce Guide, Salesforce Partner Business Org
3. Salesforce Developers, Second-Generation Managed Packaging, Code Coverage
4. Salesforce Developers, Enable Dev Hub and Second-Generation Managed Packaging
5. Salesforce Developers, Link a Namespace to a Dev Hub Org
6. Salesforce Developers, Limited Access License for Package Developers
7. Salesforce Developers, Transfer a 2GP to a Different Dev Hub
8. Salesforce Developers, How the AgentExchange Security Review Works
9. Salesforce Developers, Act on Security Review Results
10. Salesforce Developers, Get Ready to Promote and Release a 2GP Version
11. Salesforce, ISV Onboarding Guide
12. Salesforce Developers, Create a First-Generation Managed Package Using a UI
13. Salesforce Developers Blog, The Top 20 Vulnerabilities Found in the AppExchange Security Review, 2023
14. Salesforce Developers, Protect Your Application from CRUD/FLS Vulnerabilities
15. Salesforce Developers, Produce Code Analyzer Reports for AppExchange Security Review
16. Salesforce Ben, Salesforce Developer Salary Guide 2026
17. Salesforce Developers, Request a Follow-Up Security Review for a Managed Package