Build vs Buy & AppExchange Strategy

The build vs buy decision is one of the most strategically impactful choices in a CTA scenario. It is rarely a clean binary — most enterprise architectures involve a blend of custom-built components, AppExchange packages, and platform-native features. The CTA must evaluate each option through the lens of total cost, risk, maintainability, and strategic alignment.

The Build vs Buy Spectrum

This is not a binary decision. There are five positions on the spectrum:

Approach	Description	Example
Platform Native	Use standard Salesforce features out-of-the-box	Standard Approval Processes, Reports
Configure	Customize standard features declaratively	Custom objects, validation rules, flows
Extend with AppExchange	Install managed/unmanaged packages	CPQ, DocuSign, Conga
Build Custom	Develop custom Apex, LWC, integrations	Custom pricing engine, portal
External System	Use a separate product integrated with SF	ERP, data warehouse, marketing platform

CTA Exam Signal

The review board values nuanced thinking. Do not default to “build everything custom” or “buy everything from AppExchange.” Show that you evaluated multiple options for each capability and chose based on specific criteria.

AppExchange Evaluation Framework

Step 1: Define the Capability Gap

Before evaluating solutions, precisely define what you need:

• Functional requirements: What must the solution do?
• Non-functional requirements: Performance, scalability, security, compliance
• Integration requirements: How must it interact with other systems?
• User experience requirements: How will users interact with it?
• Data requirements: What data does it need access to? What data does it create?

Step 2: Evaluate AppExchange Options

flowchart TD
    A[Identify Capability Gap] --> B{Does Salesforce<br/>provide this natively?}
    B -->|Yes| C[Use Platform Native]
    B -->|No| D{Is this a common<br/>business capability?}
    D -->|Yes| E[Search AppExchange]
    D -->|No| F{Is this core to<br/>competitive advantage?}
    F -->|Yes| G[Build Custom]
    F -->|No| H{Is there an established<br/>market leader?}
    H -->|Yes| I[Evaluate External Product]
    H -->|No| G
    E --> J{Found viable<br/>packages?}
    J -->|Yes| K[Apply Vendor Scorecard]
    J -->|No| G
    K --> L{Score > 70%?}
    L -->|Yes| M[Recommend AppExchange Package]
    L -->|No| G

    style C fill:#2d6a4f,stroke:#1b4332,color:#fff
    style M fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style G fill:#e76f51,stroke:#c45a3f,color:#fff
    style I fill:#f4a261,stroke:#d4823e,color:#000

Vendor Evaluation Scorecard

Use this scorecard to evaluate AppExchange packages objectively. Each criterion is scored 1-5:

Category	Criterion	Weight	Questions to Ask
Functionality	Feature completeness	15%	Does it meet 80%+ of requirements out-of-box?
Functionality	Configurability	10%	Can it be adapted without vendor involvement?
Technical	Architecture quality	10%	Namespace conflicts? Governor limit consumption?
Technical	API availability	5%	Can we integrate with it programmatically?
Technical	Performance impact	10%	Additional SOQL queries? Package limit consumption?
Vendor	Market position	5%	Gartner/Forrester positioning? Customer count?
Vendor	Financial stability	5%	Revenue trajectory? Funding? Acquisition risk?
Vendor	Support quality	10%	SLA? Support hours? Escalation path?
Operational	Upgrade path	10%	Push vs pull upgrades? Breaking changes history?
Operational	Exit strategy	10%	Data portability? What happens if we leave?
Compliance	Security review status	5%	Passed Salesforce security review? SOC 2?
Compliance	Data residency	5%	Where is data stored? GDPR/CCPA compliance?

Scoring Guide

5 = Exceeds expectations. 4 = Meets expectations. 3 = Acceptable with caveats. 2 = Significant concerns. 1 = Does not meet requirements. A weighted score below 70% suggests building custom may be less risky than buying.

Managed Package Considerations

What CTAs Must Understand About Managed Packages

Managed packages are the most common AppExchange delivery mechanism. They have architectural implications that affect your entire org:

Namespace Isolation:

• Every managed package gets a namespace prefix (e.g., SBQQ__ for Salesforce CPQ)
• Custom objects, fields, Apex classes, and Visualforce pages are namespaced
• Namespaced components have their own governor limit allocation for some limits
• Cross-namespace queries count against the calling context’s limits

Governor Limit Impact:

• Managed packages share SOQL, DML, and CPU limits with your code in the same transaction
• Some limits (like Apex heap) have separate allocations for managed packages
• Triggers in managed packages fire alongside your triggers — order of execution applies
• Complex packages (CPQ, Vlocity/OmniStudio) can consume a significant portion of available limits

Upgrade Path:

• Push upgrades: Vendor pushes updates to all subscribers (you cannot prevent them)
• Pull upgrades: You choose when to install new versions
• Major version changes may include breaking changes to APIs
• Regression testing is essential after any upgrade — budget for it
• Some packages modify your data model during upgrades (new fields, changed picklist values)

Data Model Implications:

• Managed packages create objects and fields in your org
• These objects count against your org’s custom object limits
• Data in managed package objects may be difficult to migrate if you leave the package
• Some packages create relationships to standard objects that affect your data model

First-Generation (1GP) vs Second-Generation (2GP) Packages

Salesforce is investing in 2GP as the future of packaging. CTAs must understand both because many existing AppExchange products still use 1GP, while new ISV development should target 2GP.

flowchart LR
    subgraph GP1["1GP Architecture"]
        direction TB
        A1["Packaging Org<br/>(source of truth)"] --> A2["Single Monolithic Package<br/>(all features bundled)"]
        A2 --> A3["Namespace tied to<br/>one package only"]
        A3 --> A4["Manual dependency<br/>management"]
        A4 --> A5["Push/Pull upgrades<br/>via Subscriber Console"]
        A5 --> A6["Patch orgs for<br/>patch versions"]
    end

    subgraph GP2["2GP Architecture"]
        direction TB
        B1["Version Control (Git)<br/>(source of truth)"] --> B2["Modular Packages<br/>(features split into packages)"]
        B2 --> B3["Shared namespace<br/>across all packages"]
        B3 --> B4["Declared dependencies<br/>in sfdx-project.json"]
        B4 --> B5["CLI-driven versioning<br/>and CI/CD pipeline"]
        B5 --> B6["Flexible ancestor<br/>versioning"]
    end

    style GP1 fill:#fce4e4,stroke:#e76f51
    style GP2 fill:#e6f5f0,stroke:#2d6a4f

Factor	1GP	2GP
Source of truth	Packaging org	Version control (Git)
Development model	Org-based (changes made in org)	Source-driven (CLI + scratch orgs)
Package structure	Monolithic (one large package)	Modular (multiple small packages)
Namespace	One namespace per package	One namespace across all packages
Dependencies	Manual tracking	Declared in config, CLI-enforced
CI/CD	Limited (manual uploads)	Full support (CLI + DevHub)
Versioning	Sequential, patch orgs required	Flexible, no patch orgs needed
Push upgrades	Supported	Supported
Scratch org testing	Limited	Native support
Future investment	Maintenance mode	Active development by Salesforce

CTA Evaluation Point

When evaluating an AppExchange package, check whether it uses 1GP or 2GP. A 2GP package signals a vendor invested in modern DevOps practices. A 1GP package is not inherently bad, but ask about their migration plans — Salesforce recommends all ISVs move to 2GP.

Security Review Status

Every managed package on AppExchange must pass Salesforce’s security review, but CTAs should understand the scope:

• Security review checks for CRUD/FLS enforcement, SOQL injection, XSS, CSRF
• It does not guarantee performance, scalability, or data handling quality
• Review is point-in-time — subsequent versions may introduce issues
• Partners can lose their security review status if violations are found

Total Cost of Ownership (TCO) Analysis

TCO is where the build vs buy decision gets real. A package that costs $10/user/month may be cheaper or more expensive than building custom, depending on the full picture.

Build Custom TCO Components

Cost Category	Year 1	Year 2	Year 3	Year 4-5
Development	High	Low	Low	Low
Testing	High	Medium	Medium	Medium
Deployment	Medium	Low	Low	Low
Maintenance	Low	Medium	Medium	Medium
Bug fixes	Low	Medium	Medium	High
Feature enhancements	-	Medium	Medium	High
Developer retention	Ongoing	Ongoing	Ongoing	Ongoing
Technical debt	Low	Growing	Growing	High

Buy (AppExchange) TCO Components

Cost Category	Year 1	Year 2	Year 3	Year 4-5
License fees	Ongoing	Ongoing	Ongoing	Ongoing (may increase)
Implementation	High	-	-	-
Configuration	Medium	Low	Low	Low
Integration	Medium	Low	Low	Low
Training	Medium	Low	Low	Low
Upgrade testing	Low	Medium	Medium	Medium
Vendor management	Low	Low	Low	Low
Customization gaps	Low	Medium	Medium	Growing

The 3-Year Crossover

Custom solutions often become more expensive than AppExchange packages after 3 years due to accumulated technical debt, developer turnover, and the ongoing cost of feature development that the vendor would otherwise provide. Factor this into your TCO analysis.

TCO Analysis Framework

Use this framework to visualize the full cost picture. License fees are often less than 50% of the true 5-year cost for both build and buy options.

flowchart TD
    subgraph BuildTCO["BUILD TCO (5-Year)"]
        direction TB
        B1["Initial Development<br/>40-60% of Year 1 cost"] --> B2["Testing & QA<br/>15-20% of dev cost"]
        B2 --> B3["Deployment & Training<br/>10-15% of dev cost"]
        B3 --> B4["Annual Maintenance<br/>15-25% of dev cost per year"]
        B4 --> B5["Enhancement Requests<br/>Growing year over year"]
        B5 --> B6["Developer Retention<br/>Ongoing salary/contractor cost"]
        B6 --> B7["Technical Debt<br/>Compounds 10-20% annually"]
        B7 --> B8["Risk Premium<br/>Add 20-40% buffer"]
    end

    subgraph BuyTCO["BUY TCO (5-Year)"]
        direction TB
        Y1["License Fees<br/>Per-user/month, escalates annually"] --> Y2["Implementation Partner<br/>Often 1-3x license Year 1 cost"]
        Y2 --> Y3["Integration Development<br/>Connect to existing systems"]
        Y3 --> Y4["Configuration & Customization<br/>Gap-fill for unmet requirements"]
        Y4 --> Y5["Upgrade Regression Testing<br/>Each vendor release"]
        Y5 --> Y6["Vendor Management<br/>Contract negotiation, SLAs"]
        Y6 --> Y7["Training & Change Management<br/>Initial + ongoing"]
        Y7 --> Y8["Exit Strategy Reserve<br/>Budget for potential migration"]
    end

    subgraph Crossover["3-5 Year Crossover Analysis"]
        direction TB
        C1{"Year 1-2:<br/>Build costs more"} --> C2{"Year 3:<br/>Crossover point"}
        C2 --> C3{"Year 4-5:<br/>Build tech debt<br/>may exceed buy cost"}
    end

    style BuildTCO fill:#fce4e4,stroke:#e76f51
    style BuyTCO fill:#e6f5f0,stroke:#2d6a4f
    style Crossover fill:#fef3e6,stroke:#f4a261

TCO Comparison Formula

Build TCO = Initial Dev + (Annual Maintenance x Years) + Enhancement Cost + Risk Premium
Buy TCO  = (License Cost x Users x Years) + Implementation + Integration + Upgrade Testing

Risk Premium for Build: Add 20-40% to account for scope creep, developer turnover, and unforeseen complexity.

License Escalation for Buy: Most vendors increase prices 5-8% annually. Factor this into the 5-year projection, not just the current rate.

Common AppExchange Categories for CTA Scenarios

Category	Leading Products	When to Buy	When to Build
CPQ	Salesforce CPQ (SBQQ), Conga CPQ	Complex pricing, bundling, approvals	Simple price books with basic discounting
Document Generation	Conga Composer, Nintex DocGen, Formstack	Complex templates, merge fields, compliance	Simple email templates or basic PDF generation
E-Signature	DocuSign, Adobe Sign, Conga Sign	Legal compliance, audit trail, high volume	Internal-only acknowledgments
Telephony/CTI	Five9, RingCentral, Amazon Connect	Full call center, IVR, recording	Basic click-to-dial with Open CTI
Data Quality	Duplicate Check, RingLead, DemandTools	Ongoing dedup, enrichment, governance	One-time cleanup or simple matching rules
Analytics	Tableau, CRM Analytics (TCRM)	Advanced viz, ML, cross-source	Standard reports and dashboards suffice
Mapping/Geo	Geopointe, MapAnything	Territory management, route optimization	Simple address validation
Payment Processing	Stripe, PayPal, Chargent	PCI compliance, payment gateway	Not applicable — never build this

Exit Strategy Planning

Every buy decision should include an exit plan. The CTA must consider what happens if the vendor is acquired, raises prices, or the business needs change.

Exit Strategy Checklist

1. Data portability: Can you export all data in a standard format (CSV, JSON)?
2. Process documentation: Are business processes documented independently of the tool?
3. Integration decoupling: Are integrations built against standard APIs or vendor-specific ones?
4. Contractual terms: What are the termination clauses? Data retention post-termination?
5. Alternative identification: Have you identified at least one alternative solution?
6. Migration effort estimate: How long would it take to migrate? 3 months? 12 months?

Vendor Lock-In Red Flags

• Proprietary data formats with no export capability
• Custom objects that replace standard Salesforce objects (you lose standard functionality)
• Deep integration that bypasses Salesforce sharing model
• No API access to data stored in the package
• Vendor requires exclusive admin access to your org

Decision Framework for CTA Scenarios

When facing a build vs buy decision in a CTA scenario, present your analysis in this structure:

1. Capability Gap: What specific problem are you solving?
2. Options Evaluated: What did you consider? (minimum 3 options)
3. Evaluation Criteria: What mattered most for this customer?
4. Recommendation: What did you choose and why?
5. Trade-Offs: What are you giving up?
6. Risk Mitigation: How do you address the risks of your choice?
7. Exit Strategy: What happens if this choice does not work out?

Related Topics

• Declarative vs Programmatic — Understanding what can be built with platform tools
• Modern Platform Features — Native platform capabilities that reduce the need to buy
• Decision Guides — Visual flowcharts for build vs buy decisions
• Trade-Offs — Native vs AppExchange trade-off analysis
• Governance Model — How governance affects vendor management

Sources

• Salesforce Architects: Build vs Buy Decision Guide
• Salesforce AppExchange: Security Review Process
• Salesforce Developer Documentation: Managed Packages
• Salesforce Developer Documentation: 1GP vs 2GP Comparison
• Salesforce Trailhead: Second-Generation Managed Packages
• EPAM: Salesforce Total Cost of Ownership Framework
• Gartner: Total Cost of Ownership Analysis Framework
• Salesforce Ben: AppExchange Evaluation Best Practices
• CTA Study Groups: Community patterns for build vs buy analysis