How do you make a build-vs-buy decision at architect level?

Architect-level build-vs-buy is the recurring question for any non-trivial capability.

Three options:

1. Salesforce native — out-of-box features.
2. AppExchange — third-party packaged apps.
3. Custom build — your team creates.

Default order: native > AppExchange > custom.

When to buy (AppExchange):

• Common problem — many companies have it; vendors solve it.
• Solid vendor — established, financially stable, good reviews, security-reviewed.
• Customisability — package allows what you'll need.
• Cost over time — total cost of ownership beats build.

When to build:

• Specific business logic — generic solutions don't fit.
• Tight integration with custom data model.
• Compliance / security requires code your team controls.
• Performance critical — packages can't deliver.
• Customisation depth needed — beyond what packages support.

Hidden costs of buying:

• Licensing — recurring; can grow with usage.
• Lock-in — switching costs after adoption.
• Customisation limits — vendor's roadmap, not yours.
• Upgrade pain — vendor's release cadence.
• Knowledge concentration — fewer people understand the package.

Hidden costs of building:

• Maintenance — ongoing forever.
• Salesforce platform updates — code may need updates.
• Talent risk — knowledge walks if developer leaves.
• Security obligation — your team owns security.
• Time to market — slower than buying.

Architect-level evaluation framework:

For each candidate package or custom build:

1. Functional fit — % of needs covered.
2. Customisability — what can you configure, what's locked.
3. Integration — APIs, extension points.
4. Performance — at scale.
5. Vendor health — financial, roadmap, support.
6. Security review status — Salesforce-vetted?
7. Reference customers — comparable orgs using successfully.
8. Pricing TCO — 3-5 year analysis.
9. Exit cost — switch later if needed.
10. Talent availability — internal + market for required skills.

Build-vs-buy bias check:

Engineers naturally prefer building. Buyers naturally prefer not paying. Both biases distort.

Senior architect insight: bias toward buy unless build is clearly justified. Each line of custom code is a long-term liability. Each AppExchange package is a long-term dependency. Both have costs; choose deliberately.

The most senior framing: this isn't a one-time decision. Build today; replace with package later is valid. Buy today; rebuild custom later is valid. Architecture should accommodate evolution.