Skip to content
SF CTA Study Hub

Solution Architecture Trade-Offs

Architecture is the art of making trade-offs. Every decision involves giving up something to gain something else. The CTA review board specifically evaluates whether candidates can articulate trade-offs — not just what they chose, but what they gave up and why the trade-off was acceptable.

The Trade-Off Framework

For every architectural decision, articulate:

  1. What you chose — the recommended approach
  2. What you gave up — the benefits of the alternative
  3. Why the trade-off is acceptable — the specific context that makes your choice the right one
  4. When this trade-off would flip — what conditions would make the other choice better
flowchart TD
    A[Architectural Decision] --> B[Identify Options]
    B --> C[Option A]
    B --> D[Option B]
    C --> E[What you gain]
    C --> F[What you sacrifice]
    D --> G[What you gain]
    D --> H[What you sacrifice]
    E --> I{Scenario context<br/>favors which?}
    F --> I
    G --> I
    H --> I
    I --> J[Recommend with justification]
    J --> K[State when trade-off flips]
    J --> L[Define mitigation for sacrifice]

Declarative vs Programmatic

Choosing Declarative (Flow)

You GainYou Give Up
Admin maintainabilityFine-grained control over execution
Lower deployment riskAutomated testing capabilities
Faster initial developmentPerformance optimization options
Visual documentation (the Flow itself)Debuggability with stack traces
No code review neededVersion control with meaningful diffs
Accessible to a larger teamComplex error handling patterns

When this trade-off is right: The customer’s team is admin-heavy, the logic is straightforward, and long-term maintainability by non-developers is a priority.

When this trade-off flips: The logic involves complex data transformations, the volume exceeds Flow’s comfortable range (50K+ records), or the customer has a strong development team and CI/CD pipeline.

Choosing Programmatic (Apex)

You GainYou Give Up
Full control over executionAdmin accessibility
Automated, CI/CD-ready testingQuick iteration by admins
Performance optimizationVisual representation of logic
Complex error handlingLow deployment risk
Meaningful version control diffsBroader team participation
Debuggability with IDE toolsSpeed of initial development

When this trade-off is right: The logic is complex, the team is developer-centric, the CI/CD pipeline is mature, and the solution needs to handle high volumes or complex transactions.

When this trade-off flips: The customer lacks developers for ongoing maintenance, the logic is simple enough that Apex is over-engineering, or rapid iteration by business users is a priority.

Native vs AppExchange

Choosing Native (Custom Build)

You GainYou Give Up
Full control over functionalityVendor-maintained updates and features
No per-user licensing costsOut-of-box functionality from day one
No namespace/governor limit conflictsProven, market-tested solution
Complete ownership of IPCommunity of users and documentation
Flexibility to change directionVendor support and SLAs

When this trade-off is right: The capability is core to competitive advantage, the team has the skills to build and maintain it, and the requirements are unique enough that no package fits well.

When this trade-off flips: The capability is commoditized (e-signature, CPQ, document generation), the team lacks development capacity, or speed-to-market is critical.

Choosing AppExchange

You GainYou Give Up
Immediate functionalityFull control over the roadmap
Vendor-maintained upgradesCustomization flexibility
Proven at scaleNamespace and governor limit overhead
Support and documentationOwnership of the solution
Security-reviewed codeExit strategy complexity

When this trade-off is right: The capability is non-differentiating, speed-to-market matters, and the vendor has a strong track record with a clear upgrade path.

When this trade-off flips: The package meets less than 80% of requirements, the vendor shows financial instability, or the governor limit impact is unacceptable.

Configuration vs Customization

Choosing Configuration

You GainYou Give Up
Upgrade-safe changesUnlimited flexibility
Admin-deployableComplex UI/UX patterns
Faster implementationPerformance tuning
Standard Salesforce patternsUnique competitive features

When this trade-off is right: The requirements align with standard Salesforce capabilities. The customer wants to stay close to the platform standard to minimize upgrade risk.

When this trade-off flips: The customer’s business process is truly unique and cannot be reasonably mapped to standard Salesforce workflows, or the UX requirements demand custom components.

Choosing Customization

You GainYou Give Up
Exact fit to requirementsUpgrade safety
Differentiated UXBroad team maintainability
Performance optimizationRapid deployment
Competitive advantageStandard documentation

When this trade-off is right: The feature directly impacts revenue or customer experience, the team can maintain it, and the investment is justified by the business value.

When this trade-off flips: The custom solution does the same thing standard Salesforce does, just differently. If you cannot articulate a clear business reason for the customization, it is over-engineering.

LWC vs Aura (Migration Decision)

Migrating to LWC

You GainYou Give Up
Modern web standardsExisting component stability
Better performanceDeveloper time for rewrite
Growing community/talentTested, production-proven code
Future platform alignmentLow-risk status quo

Keeping Aura

You GainYou Give Up
Stability and proven behaviorPerformance improvements
No migration riskModern development experience
Zero rewrite costFuture platform alignment
Existing test coverageGrowing talent pool

The Pragmatic CTA Answer

“Keep existing stable Aura, write all new components in LWC, migrate Aura to LWC opportunistically when you are modifying the component anyway.” This shows the review board that you understand both the value of modernization and the cost of unnecessary rewrites.

Cross-Cutting Trade-Off: Speed vs Quality

This trade-off appears in almost every CTA scenario. The customer wants to go fast. The architect knows shortcuts create debt.

FactorOptimize for SpeedOptimize for Quality
TestingManual testing, UAT onlyAutomated tests, CI/CD pipeline
DocumentationMinimal, code-is-documentationComprehensive ADRs, runbooks
Error handlingBasic fault pathsFull retry logic, dead-letter queues
Data modelQuick fields on existing objectsProper object model with relationships
IntegrationPoint-to-point calloutsMiddleware with monitoring

The CTA answer: Phase the approach. Deliver an MVP with acceptable shortcuts (documented as technical debt), then harden in subsequent phases. This shows pragmatism without sacrificing architectural integrity.

How to Present Trade-Offs to the Review Board

Structure your trade-off discussion as:

  1. State the decision: “For document generation, I recommend Conga Composer over a custom solution.”
  2. State what you gain: “This gives us immediate functionality, vendor support, and proven templates.”
  3. State what you give up: “We give up full customization control and take on a per-user license cost.”
  4. State why the trade-off is acceptable: “Because document generation is not this company’s competitive advantage, and the TCO is favorable over 3 years.”
  5. State when this would change: “If their template requirements become highly dynamic or they scale beyond 10,000 documents per day, we would revisit with a custom solution.”
flowchart LR
    subgraph Presentation["Trade-Off Presentation Flow"]
        direction TB
        S1["1. State the decision"] --> S2["2. What you gain"]
        S2 --> S3["3. What you give up"]
        S3 --> S4["4. Why trade-off is acceptable<br/>(scenario-specific reason)"]
        S4 --> S5["5. When this would change"]
    end

Sources