How do you architect Apex code for a multi-tenant managed package?

Building for an unknown set of subscribing orgs imposes design constraints beyond a single-org build.

Key considerations:

1. Namespace awareness — all custom objects/fields/classes carry your namespace. Cross-namespace references require dynamic SOQL.
2. Bulkified by default — subscribers can have wildly different data volumes.
3. Sharing model neutral — default to with sharing; opt out only for legitimate system tasks.
4. Governor limits leave room for subscriber — aim to use ~30% or less of limits; the customer's own automation also consumes them.
5. No dependencies on subscriber-specific metadata — use Schema.describeSObjects for dynamic field access.
6. Test data factory inside package — subscribers may have validation rules that break naive test setup.
7. Forward compatibility — subscribers will be on different versions. Avoid breaking changes; deprecate, don't remove.
8. `global` is permanent — once exposed, you can't change the signature. Be deliberate.
9. Trigger handler discipline — one trigger per object.
10. Error handling — throw custom exceptions; subscribers need to debug your package.
11. Configurable behaviour — Custom Metadata Types let subscribers tune without forking.
12. Performance budgets — each method completes well under CPU limit.
13. Test in subscriber-like orgs — partner orgs that mimic real customer configurations.
14. Logging — log to a custom object so subscribers can troubleshoot.
15. Deprecation strategy — announce, deprecate, remove across multiple versions.

Multi-tenant constraints feel restrictive but make Salesforce ISV apps reliable across thousands of customer orgs.