The Build vs Buy Decision
for Salesforce Customisation

The Question Nobody Asks Clearly Enough

Salesforce programmes generate requirements. Requirements generate decisions: should we configure this in the platform, buy a packaged solution from the AppExchange, or build it ourselves with Apex and Lightning Web Components? These decisions happen constantly during implementations — often quickly, often informally, and often with consequences that outlast the implementation team by years.

The failure mode is not always building when you should have bought. It is also buying when you should have configured, and configuring when you should have done neither — because the requirement was actually a reflection of an unmapped business process that needed to be simplified, not automated. The best outcome sometimes is to challenge the requirement itself.

With that caveat established, the configure–buy–build decision is consequential and worth a clear framework. Let us build one.

The Spectrum: Configure, Buy, Build

Configure. Use what Salesforce already provides — flows, validation rules, page layouts, custom objects, formula fields, record types, OWD and sharing rules, approval processes. Configuration lives in metadata, deploys cleanly with Salesforce's release management tools, and upgrades automatically with every Salesforce release. It is the lowest-maintenance, lowest-risk approach to meeting a requirement.

Configuration has limits. It cannot perform complex data transformations at scale. It cannot implement custom UI patterns that deviate significantly from Salesforce's standard page model. It cannot maintain system-of-record integrations with real-time bidirectional sync at high volume. When configuration reaches its limits, you move to the next option.

Buy (AppExchange). Over 6,000 applications on the Salesforce AppExchange cover an enormous range of requirements — from CPQ and contract lifecycle management to document generation, advanced scheduling, telephony integration, address validation, and electronic signature. Many of these represent tens of thousands of development hours that would be expensive to replicate. AppExchange solutions are typically built by companies whose entire business model depends on them working well on the Salesforce platform — which means they are tested at scale across many orgs and maintained through Salesforce releases.

Build. Custom development — Apex classes and triggers, Lightning Web Components, custom REST APIs, custom platform events, integration code. Building gives you complete control over behaviour, user experience, and integration patterns. It also creates a permanent maintenance obligation. Every line of Apex code, every LWC component, every custom API must be maintained through every Salesforce release, every org migration, every team change, and every security review.

When Custom Development Is Right

Custom development is the right answer in genuinely specific scenarios:

Unique competitive differentiator. If the business process you are automating is genuinely proprietary — a unique pricing algorithm, a proprietary risk model, a competitive workflow that you do not want to share with any ISV or AppExchange partner — then building custom preserves that uniqueness. The test: would it disadvantage the business if a competitor could licence the same solution from AppExchange? If yes, build.

Complex integrations without off-the-shelf solutions. Real-time bidirectional integration with legacy systems using custom protocols, bespoke data transformation logic, or proprietary APIs that no iPaaS connector covers. This is genuinely an area where custom development earns its cost.

Performance-critical, high-volume processing. Certain automation requirements — bulk data processing at millions of records, time-critical calculation logic that must run synchronously within governor limits — may require custom Apex that optimises specifically for your data volume and structure.

No AppExchange solution meets 80%+ of the requirement. If you have evaluated the relevant AppExchange solutions and the best-fit option requires so much customisation of its own that you would effectively be building on top of a package rather than using it, building native may be more maintainable.

Evaluating AppExchange Solutions

AppExchange evaluations are often done poorly — a demo watched, a few reviews read, a free trial installed. This is insufficient for any package that will become a dependency in a production org. A rigorous evaluation covers five dimensions:

Functional fit. Does the solution meet 80%+ of the requirement out of the box? Map your requirements explicitly to the solution's features — not to its marketing claims, but to its documented capabilities. A gap analysis against the top 2-3 contenders produces a defensible decision.

ISV stability. How long has the ISV been in business? How many customers does the package have? Is this ISV's primary product — or a side project? A package abandoned by its developer becomes an expensive migration. AppExchange reviews, Salesforce partner tier (Navigator, Crest, Summit), and customer reference calls all provide signal.

Managed package architecture. Managed packages introduce namespace prefixes into every field, object, and class they create. If the package is uninstalled, those namespaced elements require cleanup. Some packages add significant metadata complexity to an org. Assess what the package installs, what it modifies, and what you inherit if you later want to remove it.

Commercial model. Per-user pricing, flat fee, consumption-based, or value-based? Understand the commercial model before installing. A package that is affordable at 50 users may be prohibitively expensive at 500. True-up clauses, renewal terms, and exit costs (data export, migration assistance) should be assessed as part of the commercial evaluation.

Security review status. Has the package passed Salesforce's Security Review? All paid AppExchange packages must pass it — but free packages and trial versions may not have been reviewed for production use. Check review status and date, and assess whether the package requests permissions (Connected App scopes, Apex class access) that are broader than necessary.

The Hidden Cost of Custom Code

The build decision is evaluated on the cost to build. It should be evaluated on the total cost of ownership over the expected lifespan of the feature — typically 5-10 years in a production org. The ongoing costs are significant and systematically underestimated.

Release management. Every Salesforce major release (three per year) can affect custom code through API version deprecations, platform behaviour changes, and governor limit adjustments. Someone must test every custom component against every release — in a sandbox before the release hits production. This is not optional; it is how you prevent production incidents.

Code debt accumulation. Custom code that is not actively maintained accumulates debt. Workarounds built on workarounds, undocumented interdependencies, deprecated API versions, and test classes that no longer fully cover the code base. This debt eventually has to be paid — usually at the worst possible time, during a platform upgrade or a critical release.

Knowledge dependency. The developer who wrote the custom Apex understands how it works. When that developer leaves — and they will leave — the knowledge goes with them unless exceptional documentation exists. Rebuilding understanding of complex custom code is expensive. Organisations with high developer turnover have particularly acute problems with custom code debt.

Security exposure. Every Apex class is a potential attack surface. SOQL injection, insecure DML, insufficient FLS enforcement, and improper sharing model usage are all common security issues in custom Apex. AppExchange packages that have passed Salesforce Security Review have been assessed for these issues. Custom code that has not been security reviewed carries unquantified risk.

Building a Build vs Buy Policy

Organisations with mature Salesforce governance document their build vs buy policy explicitly. This prevents individual developers or delivery leads making ad hoc decisions that accumulate into an inconsistent, unmaintainable org.

A useful policy establishes:

• The configuration-first presumption: All requirements must be assessed against native Salesforce configuration before AppExchange or custom code is considered
• AppExchange evaluation criteria: Minimum functional fit threshold (e.g., 75%), ISV assessment checklist, mandatory security review status requirement
• Custom development triggers: The specific conditions under which custom development is approved (competitive differentiation, no AppExchange fit, performance requirements)
• Approval authority: Who approves the decision to build? For any significant custom development, this should require sign-off at architect level — not just developer preference
• Technical debt review: A periodic review (quarterly or semi-annually) of the custom code estate to identify code that can be replaced with improved native functionality or an AppExchange solution