Sarah's team had spent 18 months building what they thought would be their breakthrough Salesforce app. They'd written 50,000 lines of code, created beautiful Lightning components, and secured $500K in pre-orders from eager customers.

On Friday afternoon before their Monday launch, their technical lead dropped a bombshell: "We can't deploy this. We never registered a namespace."

Sarah's stomach dropped. "What does that mean?"

"It means we can't create a managed package. We can't protect our code. We can't version it properly. We can't sell it on AppExchange."

The entire 18-month project was unsellable.

They had to rebuild from scratch in a new org with a namespace. The delay cost them $280,000 in additional development, six lost customers who bought competitor solutions, and nine months of market opportunity.

Today, I'm going to make sure you never make Sarah's mistake.

Think of a managed package as a shipping container for your Salesforce app. It bundles all your code, custom objects, fields, workflows, and configurations into a single deployable unit that can be installed in thousands of customer orgs.

But unlike a simple .zip file, managed packages have superpowers. They protect your intellectual property by obfuscating your code so customers can't see or modify it. They enable automatic upgrades, so when you fix bugs or add features, every customer gets the update. They include license management so you can control who uses what features. And they prevent naming conflicts through namespace isolation.

A managed package can contain Apex classes and triggers, Lightning Web Components, Visualforce pages, custom objects and fields, flows and workflows, permission sets, tabs and apps, reports and dashboards, and almost any other Salesforce metadata. What it doesn't include is actual data records, user accounts, or org-wide settings.

Choosing between managed and unmanaged packages is like choosing between selling compiled software versus selling your source code.

Managed packages require a namespace (a permanent 3-15 character prefix on all your components), protect your intellectual property through code obfuscation, support automatic upgrades to all customers, include license management for controlling features, and are eligible for AppExchange listing. However, you cannot delete components in upgrades, everything gets a namespace prefix, and customers have limited customization options.

Unmanaged packages require no namespace, are fully customizable by customers, and are easy to create. But they offer zero IP protection (all code is visible), have no upgrade path (it's a one-time install), include no license management, can cause naming conflicts, and aren't suitable for commercial AppExchange sales.

Use managed packages when building commercial products for AppExchange, when you need IP protection, when you want to push automatic updates, or when building for multiple customer organizations. Use unmanaged packages for open-source projects, templates, sample code, or internal org-to-org deployment where customers need full customization.

Salesforce introduced Second Generation Managed Packages (2GP) in 2019. By 2026, both are fully supported, but the industry is shifting toward 2GP for new projects.

First Generation (1GP) packages are battle-tested with 15+ years in production, have mature tooling and extensive documentation, work with change sets and metadata API, and require no DevHub for basic operations. They're simpler for small teams already familiar with traditional Salesforce development.

Second Generation (2GP) packages offer source-driven development with native Git integration, better dependency management, modular architecture support, improved CLI tooling, faster build times, and scratch org compatibility. They're ideal for teams embracing modern DevOps practices.

Should you migrate from 1GP to 2GP? Not necessarily. If you have a large established package serving thousands of customers, the migration cost may exceed the benefits. One client calculated it would take six months and $300,000 to migrate their 2,000-component package. They stayed on 1GP because everything worked well.

Meanwhile, startups building their first package should choose 2GP immediately. They'll ship 40% faster with better code quality and modern development workflows.

The namespace is the most critical decision you'll make. It's permanent. Forever. You can never change it.

A namespace is a 3-15 character prefix applied to all components in your managed package. Without namespaces, if your package has Account__c and a customer creates Account__c, installation fails. With namespaces, your package has ACME__Account__c and customers can create Account__c with no conflict.

Good namespaces are clean and branded: stripe, docusign, zuora. Mediocre namespaces have unnecessary suffixes or numbers: acmeinc, acme01. Bad namespaces are meaningless or unprofessional: xyz, temp, test123.

Choose based on your company name if you plan multiple products under one brand, or use your product name if it will become its own brand. Research thoroughly before registering because there's no going back.

Before registering, verify company branding alignment, check for trademark conflicts, ensure it's memorable and professional, confirm it's easy to type and pronounce, and align it with long-term strategy. One company registered "tmp" thinking they could change it later. They couldn't. They launched with tmp__ prefixes everywhere, damaging their professional credibility forever.

For First Generation packages, sign up for a dedicated Developer Edition org at developer.salesforce.com. This becomes your packaging org forever. Don't develop in it. Register your namespace in Setup, Packages, Package Manager. Develop in a separate Developer Edition org, then deploy to your packaging org using change sets or metadata API. Add components to your package, upload the first version, and test thoroughly before distribution.

For Second Generation packages, enable Dev Hub in your production org or dedicated Dev Hub org. Create an SFDX project, configure your sfdx-project.json file with package details and namespace, create the managed package in Dev Hub using CLI commands, develop using scratch orgs for testing, create package versions when ready, test extensively, and promote to released status.

Here's a simple example of creating a 2GP package:

bash

sfdx force:project:create -n ProjectManager cd ProjectManager

Configure your sfdx-project.json:

json

{ "packageDirectories": [{ "path": "force-app", "package": "Project Manager", "versionName": "Spring '26", "versionNumber": "1.0.0.NEXT" }], "namespace": "acme", "sourceApiVersion": "59.0" }

Create the package:

bash

sfdx force:package:create --name "Project Manager" --packagetype Managed --namespace acme

Create your first version:

bash

sfdx force:package:version:create --package "Project Manager" --wait 10

Salesforce uses semantic versioning: Major.Minor.Patch (like 2.3.5). Increment the major version for breaking changes that aren't backward compatible. Increment the minor version for new features that are backward compatible. Increment the patch version for bug fixes and small improvements.

Here's the crucial limitation: you cannot delete components from managed packages. You cannot remove custom objects, fields, or global/public Apex classes. You cannot rename components or change field types. Instead, mark components as deprecated and hide them from layouts and apps.

Always include data migration scripts in your upgrade handlers. If you change from a single Phone__c field to separate Office_Phone__c, Mobile_Phone__c, and Fax__c fields, you need code to migrate existing data. Otherwise, customer data remains stuck in the old field structure.

Implement license checks in your code to control feature access. Store license configuration in protected custom settings that only your package code can access. Check licenses before expensive operations or premium features.

For simple org-based licensing, verify the org has purchased your package. For user-based licensing, track licensed users in a custom object and enforce seat limits. For tiered licensing, gate features based on the customer's subscription level.

Popular pricing models in 2026 include freemium with basic free tier and paid premium features, tiered pricing with Starter/Professional/Enterprise levels, usage-based pricing charging for API calls or records processed, and per-feature pricing with add-on modules.

Most successful ISVs use AppExchange for distribution with built-in payment processing, though Salesforce takes a 25% fee. You can also distribute directly with custom contracts, but you lose the AppExchange discoverability and must handle payments yourself.

Minimum 75% code coverage is required, but aim higher for production quality. Test unit functionality, integration between components, package installation in fresh orgs, upgrades from previous versions, performance with large data volumes, and security with different user profiles.

Run a beta program before general availability. Start with internal alpha testing for 2-3 weeks in your own org. Run private beta with 5-10 friendly customers under NDA for 4-6 weeks. Expand to public beta with 50-100 orgs for 4-8 weeks while monitoring support tickets carefully. Then launch general availability with full support commitment.

Never start development without registering your namespace first. Even if unsure about the final name, register something. Starting without a namespace means rebuilding everything later.

Don't use hard deletes in managed packages. Implement soft delete with a status field instead, allowing customers to recover data. Schedule a cleanup job to purge old deleted records after a retention period.

Always plan for data migration between versions. Include post-install scripts that detect upgrades and migrate data structures automatically.

Bulkify all your code to avoid governor limits. Never put queries inside loops. Always fetch related data in single queries and map them for processing.

Never make breaking changes in minor version updates. Use method overloading to maintain backward compatibility when adding new parameters to global methods.

Test upgrade paths extensively, not just fresh installs. Install old versions, create test data, upgrade to new versions, and verify everything still works correctly.

Sarah's $280,000 mistake came down to one missing decision: registering a namespace on day one.

Managed packages are unforgiving of mistakes but incredibly powerful when done right. Get the fundamentals correct upfront. Register your namespace before writing code. Choose the right package type for your use case. Plan for versioning from version 1.0. Build security and licensing into your architecture. Test exhaustively before each release.

Do these things, and you unlock extraordinary leverage: one codebase serving thousands of customer orgs, one update automatically deployed everywhere, one package generating recurring revenue across multiple pricing tiers and customer segments, one architecture protecting your IP while scaling globally.

Start your managed package journey with the right foundation. Register that namespace today, set up your packaging org properly, and build something that can scale to thousands of customers without breaking. Your future customers and your bank account will thank you.