AppExchange vs Custom Build: When to Buy, When to Build

The AppExchange vs custom build decision gets made on a spreadsheet with two columns — subscription cost on one side, developer hours on the other — and the spreadsheet is wrong. Not because the numbers are wrong, but because the column that decides the outcome three years from now isn’t on it. My position: buy when the app is the entire job, and build when the app is most of the job, because the gap between “most” and “all” is precisely where a managed package stops being a shortcut and starts being a constraint you can’t edit.

The comparison everyone runs

It goes like this. There’s a thing your org needs. Someone finds a listing that does roughly that thing for a per-seat monthly fee. Someone else prices out building it and gets a number with a comma in it. Buy wins, obviously — it’s cheaper this quarter, it’s live next week, and nobody has to be hired.

That reasoning is sound as far as it goes. AppExchange exists because most orgs genuinely should not be building their own DocuSign integration or their own email-tracking layer. Buying commodity functionality is not a failure of nerve; it’s the correct call, most of the time.

The problem is that the comparison is run once, at purchase, on the version of the requirement that exists that week. Requirements don’t hold still. And the two options age in completely different directions.

What you’re actually buying

A managed package is not a set of components dropped into your org that you then own. It’s a sealed unit that lives in your org under someone else’s namespace, and Salesforce’s own packaging documentation is blunt about the boundary.

Apex class code is developer-only. When the vendor updates the code in a packaged Apex class, you receive those changes during your package upgrade — you don’t author them, and you can’t override them. The API names of packaged components are locked and can’t be edited after the package version is released. Some surface-level properties are shared: help text on a custom field, the page layout on a custom object. The logic underneath is not yours.

This is by design, and it’s the right design for a vendor shipping to thousands of orgs. It’s just worth saying out loud what it means for you: the part of your org that handles this process is the one part of your org your admin cannot change.

The exit cost nobody prices

Here’s the column missing from the spreadsheet.

When you uninstall a managed package, Salesforce removes all package components — and any customizations you’ve made to the package. Custom fields, validation rules, buttons and links, workflow rules, approval processes that hang off a packaged custom object all go with it. You can ask for an export of the package data on the way out; that file is emailed to you and stays available for two days.

And you may not be able to leave at all on the schedule you want. Salesforce blocks the uninstall whenever a component outside the package references a component inside it. Which is to say: the more thoroughly you integrate the thing you bought — the more of your own formulas, reports, flows and Apex that point at its objects — the more work it becomes to remove. Successful adoption is the lock-in mechanism. Nobody markets it that way, and it isn’t sinister, but it is how it works.

None of this makes buying wrong. It makes buying a decision with a real switching cost that should be named at purchase, while you still have leverage, rather than discovered in year three when the vendor changes their pricing model or gets acquired.

Where AppExchange genuinely wins

I want to be fair to the buy side, because the flank position here is not “never buy.”

Buy when the app is the whole job and the job is not yours. Payment processing. E-signature. Phone systems. Data enrichment. Anything where the vendor’s actual product is a network, a dataset, or a regulatory relationship you have no business reproducing — you’re not buying code there, you’re buying the thing behind the code.

Buy when the domain has real compliance surface and someone else is carrying it. Buy when the app is genuinely standalone: it owns its objects, nothing of yours points into it, and you could rip it out on a Tuesday without touching your reporting.

Buy, honestly, when nobody in the building wants to own this forever. That’s a legitimate reason and it doesn’t need dressing up.

Where it stops winning

The failure mode isn’t the app that does nothing. It’s the app that does 80% of what you need.

You buy it, it works, everyone’s pleased. Then the requests start. Can it use our stage names. Can it look at the child records instead of the parent. Can it not fire for the partner accounts. Can it write back to the field the finance team actually reports on. Each request is small. Each one is downstream of a namespace you can’t edit.

So the workarounds start — a shadow field next to the packaged one, a flow that copies values across, a monthly export that someone reconciles by hand, a rule everyone knows but nobody wrote down. The app still “works.” Your team is now doing the last 20% manually, forever, and paying a subscription for the privilege of the first 80%.

This is the same ceiling that no-code tools hit when the requirement gets one clause too specific, arriving from a different direction. A vendor’s product is shaped by the average of their customer base. Your process isn’t average — if it were, it wouldn’t be worth much.

Why “build” used to lose automatically

Now the part that has actually changed.

For twenty years, “build it” meant one of three things: hire a developer, retain a consultancy, or convince someone who already has a full-time job to do it in the margins. All three are expensive, and two of them are slow. The salary math on a Salesforce developer makes it obvious why buy kept winning — no single 30-hour build justifies a six-figure hire, so the whole class of 30-hour builds never happened, and buying was the only door that opened.

That’s not a fact about custom software. It’s a fact about labor supply. And it’s the input that moved.

When your AI can develop directly against your org — read the schema, write the Apex, run the tests, deploy sandbox-first — the fixed cost that made “build” lose stops being a salary and starts being a subscription. Small Salesforce projects that never cleared the bar for a hire now clear it easily. That doesn’t make every buy decision wrong. It makes every buy decision worth re-running, because one column of the comparison changed by an order of magnitude and the other didn’t.

The honest test

Three questions, in order. They resolve most of these decisions in about ten minutes.

Is this our process, or everyone’s process? Invoicing, e-signature and dialers are everyone’s process — buy them. The object model your operation actually runs on is yours. Nobody sells it, because nobody else needs it.

How much of the requirement does the app cover, honestly? Not “could we adapt” — how much does it cover as shipped. Above 95%, buy. Below 80%, build. Between the two, the deciding factor is whether the gap sits in configuration or in logic, because configuration you can layer on and logic you cannot.

What does leaving cost? Count what would point into the package after twelve months of successful use. If the honest answer is “our reporting, three flows and the renewal process,” you’re not evaluating a subscription — you’re evaluating a dependency.

What building looks like when it isn’t a hire

Concretely: you describe the process to your AI, it reads your org’s actual schema, it builds the objects and the logic against your stage names and your edge cases, it deploys to sandbox with tests before anything reaches production. What you get back is metadata in your own namespace — editable by your admin, visible in your change history, and yours to change when the process changes.

That last part is the whole argument. Not that custom is better than bought — often it isn’t. It’s that when you build it, the next requirement is a change request instead of a support ticket, and the one after that is too.

The safety story here is honest rather than absolute: every change is logged and every deploy is snapshotted first, so what your AI does is visible and recoverable. It’s not a system that prevents you from breaking things — it’s a system where breaking something is a five-minute problem instead of a Friday.

Sentinel is $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel. Whether that beats a given subscription is arithmetic you can do against your own list. The reason to do it is that your AI can now do the CRM development work that used to require the hire that never got approved.

How to decide this week

Open your installed packages list. For each one, ask what percentage of its job it actually does, and what would break if you removed it tomorrow.

The ones at 95% and standalone — leave them alone, they’re doing their job. The ones at 80% with four workarounds bolted on and half your reporting pointing into their namespace — those aren’t purchases any more. Those are the decisions worth re-running now that building doesn’t mean hiring.

---

Sitting on a package that does most of the job? Get a Sentinel for your Salesforce org and find out what the last 20% actually takes to build.

Sources: Salesforce Developers, Editable Properties After Package Promotion or Installation and After Installing a Package; Salesforce Help, Uninstall a Managed Package. ORG Endgame is not affiliated with Salesforce.