There are four ways to get a Salesforce managed package built: hire a Salesforce developer, contract a PDO or agency, buy a done-for-you engineering service, or build it declaratively with an admin. The right one depends on three things: whether the package is a one-off or a product you will keep shipping, who needs to own the intellectual property, and who carries the security review when it fails the first time.
This page compares the four routes on cost model, timeline, IP ownership and maintenance burden. If you want the definition of a managed package first, our guide to what a managed package is covers 1GP versus 2GP, namespaces and upgrade behaviour in full.
Every team that ships on AppExchange hits the same wall: the distribution format is a managed package, and building one is Salesforce engineering work whether or not you have Salesforce engineers.
The question that actually decides your timeline is not what a managed package is. It is who is going to build yours.
Below: what you are commissioning, the four routes with their real trade-offs, and the three obligations none of them removes.
What you are actually commissioning
A Salesforce Managed Package is a bundle of Salesforce metadata, like objects, fields, Apex classes, and Lightning components, that's packaged up for distribution.
Think of it as the Salesforce version of a ZIP file that contains your app, ready to install.
Managed packages are:
- Version-controlled
- Namespace-protected
- Required for AppExchange listing
If you're building for customers, partners, or end users outside your own org, you'll need a managed package.
Why Managed Packages Matter
- Distribute your app with one install link
- Protect your codebase with namespaces
- Enable upgrades and patches
- List on the Salesforce AppExchange
Whether you're building internal tools for scale or commercial apps for distribution, managed packages are the standard.
The four routes, compared
| Route | Cost model | Typical timeline | Who owns the IP | Who carries the security review |
|---|---|---|---|---|
| Hire in-house | Salary, ongoing | Slowest to start, you have to recruit a packaging specialist | You | Your employee |
| PDO or agency contract | Project fee, often milestone-based, change requests billed | Months, set by their queue as much as your scope | Read the contract, it varies | Usually shared, remediation often billed separately |
| Done-for-you engineering service | Fixed price for a defined outcome | Weeks | Yours, if the agreement says so | The provider |
| Declarative build by an admin | Existing headcount | Fast for simple scope, then it stalls | You | You, with no specialist to call |
The column that surprises people is the last one. The security review is not a formality you pass once. Most teams clear it on the second attempt, so the question of who fixes the findings and who pays for that cycle belongs in the contract, not in a conversation you have after the rejection arrives.
Route 1: hire a Salesforce developer in-house
Historically, this involved:
- Setting up a Developer Hub and Scratch Orgs
- Writing Apex code and Lightning Web Components
- Registering a namespace
- Manually creating the package in Salesforce CLI
- Testing upgrades, handling permission sets, etc.
Hiring for it means a Salesforce developer who knows packaging specifically, not just Apex. Packaging, namespace strategy and upgrade paths are a specialism inside a specialism, which is why this route is slow to staff and expensive to keep once the package is stable and the work drops to maintenance.
Route 2: a PDO or agency contract
The traditional answer, and still the right one for genuinely complex builds with unusual architecture. Two things to check before signing. First, IP assignment: some agreements leave the agency owning components you assumed were yours. Second, what happens on a security review rejection, because remediation is frequently a separate line item and it lands exactly when your launch date is already committed.
Route 3: a done-for-you engineering service
Appnigma is a done-for-you engineering service, built by ex-Salesforce AppExchange engineers, that designs and ships the managed package for you. One kickoff call, one flat price, and the IP stays yours.
What that covers: a native Salesforce app built to your spec, the data model and flows, a 2GP managed package produced from it, an install link for your customers, and the artifacts the security review asks for.
The trade is control for speed. You are not staffing a Salesforce team, and you are depending on a partner for changes.
For the packaging mechanics themselves, see our complete guide to Salesforce managed package implementation.
Route 4: build it declaratively with an admin
Viable for a narrow, simple package: custom objects, fields, flows, page layouts, no Apex. It stops working the moment you need Apex, callouts to an external service, or anything the security review scrutinises at code level. Teams that start here often finish somewhere else, having spent a quarter finding the ceiling.
Which route fits which team
- Product teams launching Salesforce integrations
- RevOps teams building internal tools
- Alliances and GTM teams distributing partner packages
What none of the routes removes
Three obligations survive whoever builds the package. Budget for them regardless of the route you pick.
| Obligation | Why it does not go away |
|---|---|
| The security review | Every paid AppExchange listing is reviewed. CRUD and field-level security enforcement is the most common failure by a significant margin, and the scan artifacts (Checkmarx, Salesforce Code Analyzer, plus your own DAST report since Chimera was retired in June 2025) have to come from someone |
| The namespace decision | A namespace is permanently tied to the Partner Business Org that registered it and cannot be changed or reused once you have released with it. Whoever builds the package, this choice is yours and it is irreversible |
| Upgrades, forever | A managed package is upgradeable by design, which means subscribers expect you to ship fixes. Someone has to own version 2, and that is a standing commitment rather than a project |
If a route leaves any of the three unassigned, that is the gap that will cost you the launch date.
- Startups trying to get listed on the Salesforce AppExchange
The short version
A managed package is how you bundle and distribute a Salesforce app, and it is mandatory for paid AppExchange distribution. What varies is who builds it.
Pick the route by permanence. A one-off integration rarely justifies a hire. A product you will version for years rarely justifies outsourcing forever.
Getting your managed package built
Appnigma is a done-for-you engineering service built by ex-Salesforce AppExchange engineers. One kickoff call, one flat price, never hourly, and the IP is yours. Book a call.
Frequently asked questions
Do I need a Salesforce developer to build a managed package?
You need Salesforce packaging expertise, which is not the same as needing it on your payroll. A simple declarative package can be assembled by a strong admin. Anything involving Apex, external callouts or a paid AppExchange listing needs someone who has taken a package through the security review before, whether that is an employee, an agency or a service provider.
How long does it take to build a managed package?
The build itself varies with scope, but the fixed cost is the review. Plan roughly 4 to 6 weeks of actual security review, and 6 to 9 weeks of wall-clock time once queue waits are counted, with a resubmission adding 2 to 3 weeks. Any timeline that does not budget for a second submission is optimistic.
Can I build a managed package without writing code?
Partly. Custom objects, fields, flows and layouts are declarative and package cleanly. The limits arrive with Apex, external integrations and anything the security review inspects at code level. In practice most commercial packages contain some Apex, so the realistic question is who writes it rather than whether it exists.
Who owns the IP if an agency builds my managed package?
Whatever the agreement says, which is why it is worth reading before signing. Assignment of the built components is not automatic, and the namespace is registered to a Partner Business Org that should be yours rather than the builder's. Confirm both in writing.
What happens if the package fails the security review?
You get a findings report, you fix the root cause across the codebase rather than the flagged line, and you request a re-review, which is faster than the first pass. The commercial question is who does that work. Under a fixed-price service it is included; under a project contract it is often a change request.
Is a managed package required to list on AppExchange?
For paid distribution, yes. A managed package is the only type eligible for paid AppExchange listing, the only one supporting Salesforce licence management, and the only one that keeps your Apex source hidden from subscribers.
