Salesforce Build vs. Buy: What Actually Decides an AppExchange Call

A managed package that's passed Salesforce's AppExchange security review gets its own governor limit allocation - its own 150 DML statements, its own 100 synchronous SOQL queries, separate from your org's native code. That's close to the opposite of what most teams assume when they're deciding whether to build or buy: the package is actually better protected from limit contention than two features your own team built are from each other. Every trigger, class, and integration your own developers have written, across every team, draws from one shared native-code limit pool in the same transaction, no matter how unrelated the features are. That single fact rarely makes it into generic Salesforce build vs. buy AppExchange advice, which tends to stop at license cost and skip the part where the code actually has to share a runtime.

The short answer

In brief: buy the commodity, build the differentiator, and don't let the decision rest on cost alone or on the governor-limit myth above. Four checks settle most real cases: whether a competitor could buy the same capability off the shelf without losing anything customers actually notice, who controls the upgrade cadence once you're on the package, who owns the data model if you ever have to leave it, and how much of your own native Apex will run in the same transaction as whatever you choose. Calls like this are exactly the kind most orgs face a handful of times a year, not weekly - see our take on who actually makes that call if the bigger question is who in your org should be deciding, not just how.

Why "default to buying" is bad advice

A lot of build-vs-buy content lands on a rule like: default to buying, and only build when the process is core to competitive differentiation. That's directionally right and practically useless on its own - it names the shape of the answer without giving a way to tell, for your specific requirement, which side of the line it sits on. Contract generation, e-signature, and document workflow are commodity functions for almost any company that isn't in legal tech; a quoting engine that encodes pricing logic unique to how your business actually sells is not. The rule doesn't fail because it's wrong - it fails because deciding what's genuinely a differentiator is the actual judgment call, and no percentage answers that for you. It's also exactly the kind of decision worth a second opinion from outside architectural experience before a purchase order or a sprint commitment makes it harder to reverse.

The governor-limit myth, corrected

Here's the mechanism behind the opening claim, and why it changes the calculus. A managed package that's passed Salesforce's mandatory AppExchange security review - a four-to-six week process that scans the package with Salesforce Code Analyzer before it can be listed - runs in a certified namespace, and certified namespaces get their own per-transaction governor limit allocation: their own DML statements, their own synchronous SOQL queries, on top of whatever your org's native code already has. There's a ceiling on that generosity - combined operations across every certified namespace touched in one transaction cap out at roughly eleven times a single namespace's limit - but a well-built certified package is, by design, harder to blame for a limit exception than most teams assume. Your own native Apex doesn't get that protection. Every custom trigger, class, and integration your team has written over the years, regardless of which feature it belongs to, draws from one shared limit pool the moment two of them fire in the same transaction. The governor-limit exception that actually derails a release is far more often caused by your own code colliding with itself than by a package colliding with you.

The cost on the other side: who maintains it in three years

Buying isn't the only side with a hidden bill. Custom Apex and Lightning Web Components carry no per-seat license line that grows every time you add a user, no publisher deciding when your next breaking change lands, and no vendor to negotiate with when a feature doesn't quite fit - genuine advantages. What they don't have is anyone else's roadmap absorbing the cost of keeping up with the platform. Every major Salesforce release is a validation pass against custom code that a serious package vendor already ran against their own; a custom build pushes that work permanently onto whoever owns the org, and that person is not guaranteed to be whoever originally wrote it. The realistic comparison isn't license cost versus zero - it's license cost plus a smaller, more predictable maintenance tail, against build cost plus an open-ended one that depends entirely on who's still around to carry it.

Four questions that actually decide it

These map loosely onto how Salesforce's own Well-Architected framework asks architects to evaluate trade-offs - its Resource and Cost Optimization pillar is this exact kind of analysis, just not scoped to any one decision. Applied to a specific requirement, it comes down to four checks:

• Is this commodity or differentiator? Could a competitor buy the same capability without losing anything customers actually notice? If yes, buying costs nothing competitively; building just means maintaining commodity logic indefinitely.
• Who controls the upgrade cadence once you're on it? A package vendor decides when a breaking change ships - that's a second release calendar layered on top of your own. Ask a vendor directly how they handled backward compatibility on their last major version, not just what the SLA promises.
• Who owns the data model if you leave? Packages routinely create their own custom objects and fields under their namespace. Uninstalling can remove data with it or leave orphaned records behind - check this before go-live, not during an exit.
• How much of your own native code will share the transaction? A certified package protects itself with its own limit allocation; your own multiple custom features sharing one native pool are the more likely contention risk - test the transaction your automation actually creates, not the new component in isolation.

The Salesforce build vs. buy AppExchange framework, as a table

Questions worth asking before you decide

Does buying always reduce technical debt?

Not automatically. A package bent to cover a requirement it wasn't designed for creates a different kind of debt - configuration workarounds and undocumented customisation on top of a data model you don't own, which can be harder to unwind than custom code because the source isn't yours to change. Buying reduces technical debt when the fit is genuinely good; it relocates the debt when the fit is forced.

What if we've already outgrown a package we bought?

That's a smaller-scale version of a fix-vs-rebuild decision, and the same audit applies: is the underlying requirement still commodity, or has it become differentiated as the business grew around it? If it's the latter, replacing the package with something custom - or a hybrid where the package still handles the commodity core while custom logic covers what's grown past it - is often more realistic than either living with the mismatch or ripping the package out entirely. A structured health check is a cheaper way to find out which situation you're actually in than guessing.

Is buying part of a process and building the rest normal?

It's the more common pattern in mature orgs, not the exception - the DocuSign CLM example above is exactly this: bought the commodity function, built the integration and the business logic around it. Treating build-vs-buy as one decision per project, rather than one decision per capability inside the project, is one of the more common ways teams end up over-committed to whichever option they picked first.

The bottom line

Treat every build-or-buy question as two questions, not one: is this commodity or differentiated, and what does sharing a runtime or a data model with someone else's code actually cost you technically, not just financially. Most teams get the first question roughly right on instinct. It's the second one - governor limits, upgrade cadence, data ownership on exit - that gets skipped, because it's less visible at decision time than the license quote. If you're mid-decision on a specific requirement and want a technically grounded second opinion before you commit either way, that conversation is worth having early, not after the package is already live in production.