Every Salesforce org eventually reaches the same fork in the road. Your Salesforce org needs new functionality that does not exist out of the box, and the team must decide whether to build it directly inside the production environment or bundle it as a managed package. The decision affects maintenance load, upgrade paths, and how easily the solution can reach other teams or customers.
Custom app development means creating objects, flows, Apex classes, Lightning Web Components, and reports straight inside your Salesforce org. You gain complete control over every detail and can edit anything at any time. The trade-off is that every component counts against your org limits, and every future update requires manual work across environments.
Managed packages take a different route. Developers bundle the same metadata into a versioned unit that installs through the AgentExchange or direct links. The package carries its own namespace, supports automated upgrades, and hides source code from subscribers. This structure reduces the burden on the installing org while giving the publisher control over releases.
Current State of Custom Development
Most teams start with the custom route because it feels fastest at the beginning. A developer opens Flow Builder or the Developer Console, creates the required objects and logic, and deploys changes through change sets or the Salesforce CLI. The solution matches the exact process the business described.
Over time the same solution becomes harder to maintain. Each new Salesforce release can affect custom Apex or Lightning components. Testing falls on the internal team. When multiple sandboxes and the production org all need the same fix, the work multiplies. Limits on flows, Apex methods, and custom objects become real constraints once several of these solutions coexist.
The Case for Managed Packages
A lighter approach uses second-generation managed packages, known as 2GP. Salesforce now recommends 2GP for all new development because it treats Git as the source of truth and removes the need for a dedicated packaging org. The package installs cleanly, receives push upgrades when the publisher publishes a new version, and carries licensing through the License Management App.
This model reduces the long-term ownership cost for the installing organization. The vendor handles bug fixes and feature additions. The subscriber still controls their own data and can extend the package with custom objects or permitted fields, yet the core logic stays protected and consistent across every customer org.
How It Works in Practice
Start by registering a namespace in a Developer Edition org and connecting a Dev Hub. Use scratch orgs and the Salesforce CLI to create package versions. Promote a beta version to released status once testing passes. Generate an install URL or push the upgrade to subscriber orgs.
For teams that only need internal modularity without marketplace distribution, unlocked packages offer a middle path. They support versioning and Git-driven development but remain fully editable after install. Many enterprises now manage internal components this way to keep code organized without the overhead of full managed packaging.
Recent platform updates support this direction. The Spring ’26 ISVforce Guide explicitly positions 2GP as the standard, while older first-generation packages are treated as legacy. AgentExchange now unifies listing, billing, and analytics for both apps and agents, making distribution simpler for publishers who meet the security review requirements.
Honest Limitations
Managed packages are not free of constraints. Subscribers cannot edit the packaged Apex or locked components. Some complex integrations that touch private algorithms or deeply proprietary workflows may not fit inside a package structure. Pricing also shifts from one-time internal development cost to ongoing subscription fees set by the vendor.
Custom development carries its own ongoing expenses. Upfront build cost, often cited between $50,000 and $500,000 for complex internal projects source, is only the start. Internal teams then absorb the cost of testing, limit monitoring, and upgrade compatibility every release cycle.
Decision Framework
Choose managed packages when the functionality solves a common need that multiple teams or external customers will use. The solution should meet at least 80 percent of requirements without heavy modification. Push upgrades and licensing management become clear advantages in this scenario.
Stay with custom development when the process contains unique intellectual property, complex proprietary algorithms, or integrations that no existing package supports. In these cases the control and editability outweigh the maintenance burden because no off-the-shelf option exists.
Unlocked packages fit internal teams that want Git-driven modularity and easier promotion between environments without exposing the work to external customers. They provide upgrade paths while keeping full edit rights inside the org.
The Bottom Line
The choice is less about technology than about who will own the solution after it ships. Package what many teams or customers will share, keep custom what is truly unique to your business, and use unlocked packages when you want version control without giving up edit rights. Decide that up front, and the maintenance bill stops being a surprise.
App Kit
Custom apps on a proven foundation — one UI, any backend.
Read Next
How Salesforce LWC Limits React Development for Modern Frontends
Salesforce solution architects often hit walls trying to bring React into LWC. This post explains the historical limits, the new native path with Multi-Framework, and clear criteria for choosing between the two.
Decouple Salesforce Frontend: Replace Experience Cloud with Your Own React Stack
Solution architects and Salesforce admins can now run full React apps natively on the platform. Learn how Multi-Framework removes Experience Cloud constraints while keeping data, security, and governance inside Salesforce.
How Do SF Platform Architects Implement Salesforce Micro Frontends Without Framework Lock-In?
SF Platform Architects implement Salesforce micro frontends with Multi-Framework and MFE Developer Preview using sandboxed iframes and the Platform SDK to avoid framework lock-in.
