TL;DR: Choose a managed package when the problem is common, the vendor’s roadmap matches yours, and you would rather pay a subscription than maintain code. Choose a custom app when the process is specific to your business, when you need to see and change every line, or when upgrade surprises are costing you more than the build would. Custom apps delivered as unlocked packages keep source control and deployment discipline without the vendor lock. React apps built on the Salesforce Platform SDK add a modern interface option, though packaging them is still on Salesforce’s roadmap.
A vendor upgrade that changes behavior your users depend on is usually what starts this conversation. The question is not whether managed packages are good or bad. It is which parts of your org you want to rent and which you want to own.
What is the real difference between a custom app and a managed package?
A managed package is software you subscribe to. The vendor owns the code, ships upgrades on its schedule, and protects most components in its namespace so you cannot edit them. A custom app is software you own. Your team, or a partner on your behalf, writes it, and you control every change.
| Factor | Managed package | Custom app |
|---|---|---|
| Fit to your process | The vendor’s model of the problem | Built around your process |
| Code visibility | Protected Apex and components you cannot edit | Full source in your repository |
| Upgrades | Vendor schedule, tested by you | Your schedule |
| Security review | Audit someone else’s code paths | Review your own code |
| Cost shape | Recurring subscription | Upfront build plus ongoing upkeep |
| Who maintains it | The vendor | Your team or a partner |
When does a managed package make sense?
- The problem is common. E-signature, document generation, and CPQ add-ons are solved problems with mature vendors.
- The roadmap matches. If the vendor is building what you will need next year, you get those features without funding them.
- No one will own the code. A package is safer than a custom app nobody maintains.
When does a custom app make sense?
- The process is your advantage. Generic software flattens the workflows that differentiate you.
- Upgrades keep breaking things. When each release means regression testing someone else’s changes, ownership starts to pay off.
- Security needs full visibility. Your team can enforce field-level security and sharing in code it can read, and pass reviews without waiting on a vendor.
- The license line keeps growing. Per-user subscriptions scale with headcount. A custom app’s cost scales with change, not users.
How should you deliver a custom app?
Deliver it as an unlocked package rather than loose metadata changes. Salesforce describes unlocked packages as especially suited for internal business apps, with your version control system, not the org, as the source of truth. You get versioned, upgradable releases without the code protection of a managed package.
Keep business logic in Apex and Flow, behind clear service boundaries, so the interface can change without touching core processes.
Where do React and the Platform SDK fit?
Salesforce Multi-Framework reached general availability on July 16, 2026, so a custom app can now have a React interface running natively on the platform. The Salesforce Platform SDK gives React components queries, mutations, and Apex calls in the signed-in user’s context, so sharing rules and field-level security still apply. We walk through the setup in building Salesforce React apps.
One limit to plan around: Salesforce’s setup guide says packaging is not supported for external Multi-Framework apps yet, and managed packages for Multi-Framework appear on Salesforce’s published roadmap. Today, deploy React UI bundles through your source-driven pipeline, and package the Apex and data model underneath them.
How do you compare the cost of ownership?
Compare the same time horizon for both. For a managed package, add the subscription for every user who needs it, the admin time spent testing upgrades, and the workarounds you maintain where the package does not fit. For a custom app, add the build, hosting if any, and the ongoing effort to maintain and extend it. Neither is cheaper in the abstract; the answer depends on user count, how much the package must bend, and how often your process changes. Our custom app development cost comparison breaks down the cost drivers.
How Funnelists approaches the decision as your AI advisor
We look at where AI will act in the process before choosing. An agent that has to read and update records needs clean, permission-aware services, and those are far easier to provide in code you own than in a package you cannot see inside. When a mature package fits, we recommend it. When the process is yours to own, our headless Salesforce service builds custom React apps on the platform and delivers them on our App Kit foundation, with source your team owns after handoff.
The honest limitations
- Custom means upkeep. Plan who maintains the app after launch, or the advantage disappears.
- React packaging is not ready. Distribution as a package, especially for customer-facing React apps, is still on Salesforce’s roadmap.
- Packages are not all equal. A well-run vendor with a stable roadmap can beat a custom build for a common problem.
Decision framework
Choose a managed package when:
- The problem is common and a mature vendor solves it well.
- The vendor’s roadmap matches your needs.
- Nobody will own a codebase after launch.
Choose a custom app when:
- The process is specific to your business or a competitive difference.
- Upgrade conflicts or security reviews keep costing you time.
- Per-user subscription costs outgrow the cost of owning the code.
Combine them when:
- A package covers a common capability and a custom app covers the process around it.
FAQ
What is the difference between a custom Salesforce app and a managed package?
A managed package is vendor-owned software with protected code and vendor-scheduled upgrades. A custom app is software you own, with full source control and your own release schedule.
Are custom Salesforce apps more secure than managed packages?
Not automatically. Custom apps let your team see and enforce every security control in code it owns, but they are only as secure as the code your team writes and maintains.
Can a React app built with Multi-Framework be distributed as a managed package?
Not yet. Salesforce lists managed packages on its Multi-Framework roadmap, and packaging is not supported for external Multi-Framework apps today.
Should a custom app be delivered as an unlocked package?
Usually, yes. Salesforce recommends unlocked packages for internal business apps, and they give you versioned, upgradable releases with your repository as the source of truth.
The takeaway
Rent what is common and own what makes you different. Use managed packages where a mature vendor solves a standard problem, build custom apps where the process is yours, and deliver them with package discipline so ownership does not turn into disorder.
Headless Salesforce
Build the frontend in React. Keep the data, security model, and business logic on Salesforce.
Read Next

How Do SF Platform Architects Build Headless Salesforce Experiences with Multiple Frameworks?
Headless Salesforce lets a React front end run on the platform while Salesforce keeps enforcing identity, sharing, and business logic. Here is the four-layer architecture, what Multi-Framework and Headless 360 add, and when the approach fits.

How Do SF Platform Architects Implement Salesforce Micro Frontends Without Framework Lock-In?
Salesforce UI Embedding is now generally available, replacing the developer-preview shell. Here is how Platform Architects place independently deployed apps in Lightning pages, the two patterns to choose between, and how to avoid lock-in.

Building Salesforce React Apps and Multi-Framework UIs: What's Possible and Practical
React apps now run natively on Salesforce through Multi-Framework. Here is what a dev lead needs to know: prerequisites, how a UI bundle is structured, how data access works through the Platform SDK, and the limits to plan around.

