Custom vs Out of the Box in Salesforce

Part 103: Custom vs Out of the Box in Salesforce

If there is one hill I will die on in the Salesforce ecosystem, it is this: use what the platform gives you before you write a single line of code. I have watched teams spend six months building custom solutions that Salesforce already shipped for free in a recent release. I have watched orgs drown in technical debt because someone decided that the standard Lead conversion process was “not quite right” and rebuilt the entire thing in Apex. I have watched consultants bill hundreds of thousands of dollars for custom Lightning components that duplicate what a Screen Flow could do in an afternoon.

The custom vs out-of-the-box (OOTB) decision is arguably the most consequential architectural choice you will make on the Salesforce platform. Get it right, and your org stays maintainable, upgradeable, and affordable. Get it wrong, and you are signing up for years of pain.

Let me be blunt: the default answer should always be OOTB. You should have to argue your way into custom development, not argue your way out of it.

Why OOTB Should Be Your First Instinct

Salesforce invests billions of dollars every year in R&D. Three releases per year. Thousands of engineers working on features that you get automatically — no deployment, no regression testing, no maintenance on your end. When you choose an OOTB feature, you are essentially getting a team of hundreds of engineers maintaining your solution for you, forever, at no additional cost.

Here is what OOTB gives you that custom development does not:

• Automatic upgrades. When Salesforce ships an improvement to Approval Processes or Flow, you get it. Your custom Apex approval engine? You get to maintain that yourself.
• Documentation and community support. Standard features have Trailhead modules, help articles, and thousands of community forum posts. Your custom solution has whatever your developer remembered to write in the README.
• Ecosystem compatibility. AppExchange packages, third-party integrations, and consulting partners all assume you are using standard features. The moment you go custom, you are on your own for compatibility.
• Admin-friendly management. OOTB features can typically be managed by admins through point-and-click configuration. Custom code requires developers for every change, no matter how small.
• Built-in security and compliance. Standard features respect sharing rules, field-level security, and audit trails by default. Custom code? Only if the developer remembered to enforce them — and I have seen far too many orgs where they did not.

The True Cost of Custom Development

Here is the part that most teams get catastrophically wrong: they calculate the cost of custom development as “developer hours to build it” and stop there. That is maybe 20% of the real cost. The true cost looks more like this:

Initial development — The obvious part. Let us say 200 hours of developer time.

Code reviews and QA — Someone needs to review that code, write test classes (and not the garbage “just hit 75% coverage” kind — real tests). Add another 40-60 hours.

Deployment and change management — CI/CD pipeline setup, sandbox management, release coordination. Ongoing overhead every time you touch it.

Documentation — If you are lucky, someone writes it. If you are realistic, nobody does, and then that developer leaves, and now you have an undocumented black box running a critical business process.

Maintenance — Salesforce ships three releases per year. Each one can break your custom code. Each one requires regression testing. Each one requires a developer to investigate, fix, and redeploy. This cost never stops. It compounds.

Opportunity cost — Every hour your developer spends maintaining custom code is an hour they are not spending on genuinely valuable work that the platform cannot handle.

Technical debt accumulation — Custom solutions attract more custom solutions. Once you have a custom Apex trigger handling Lead assignment, the next team says “well, we already have custom code there, let us just add to it.” Before you know it, you have a 2,000-line trigger that nobody fully understands and everyone is afraid to touch.

Knowledge dependency — Custom code creates hero dependencies. When the developer who built it leaves — and they will leave — you are left paying a new developer to reverse-engineer the old developer’s work. I have seen this add 3-5x to the ongoing cost of a custom solution.

I have personally worked on orgs where the annual maintenance cost of custom code exceeded $200,000 — for features that could have been handled by standard Flows and configuration. That is not an exaggeration. That is a Tuesday in enterprise Salesforce consulting.

The Decision Framework

Not every customization is a mistake. Sometimes custom development is exactly the right call. The key is having a rigorous framework for making that decision instead of defaulting to “let us just build it.”

Here is the framework I use, in order of preference:

Tier 1: Use OOTB As-Is

When to apply: The standard feature does 100% of what you need, or it does 90% and the missing 10% is not actually a business requirement — it is a preference.

This is where brutal honesty matters. I cannot tell you how many times a stakeholder has said “we need a custom solution because the standard feature does not do X” and X turns out to be a cosmetic preference, not a business need. The standard Lead conversion does not send a custom email in the exact format you want? Use a Flow to send the email after conversion. You do not need to rebuild Lead conversion.

Real example: A financial services company wanted to replace the standard Opportunity Close process because they needed five custom fields populated at close. The proposed solution was a custom Lightning component with Apex backend. The actual solution? Five required fields on the page layout and a validation rule. Total development time: 30 minutes. The custom component would have cost $40,000 to build and $15,000 per year to maintain.

Tier 2: Extend OOTB with Declarative Tools

When to apply: The standard feature gets you 70-80% of the way there, and the gap can be closed with Flows, formulas, validation rules, or other declarative tools.

This is the sweet spot that too many teams skip over. Salesforce’s declarative tools are absurdly powerful now. Screen Flows can build multi-step guided processes. Record-Triggered Flows can handle most automation. Dynamic Forms and Dynamic Actions let you customize the UI without code. Platform Events enable event-driven architecture declaratively.

Real example: A healthcare company needed a patient intake process that involved creating records across five objects with conditional logic and external system notifications. The initial estimate for a custom Apex and LWC solution was 600 development hours. The team ultimately built it as a Screen Flow with Flow Orchestration, calling a single Invocable Apex class for the one external API callout that Flows could not handle natively. Total effort: 120 hours, and the admins could modify the business logic themselves going forward.

Tier 3: Extend OOTB with Targeted Code

When to apply: The standard feature is the right foundation, but you need code to fill a specific gap — not replace the feature, but augment it.

This is where Invocable Apex methods, small LWC components embedded in standard pages, and Apex triggers with narrow responsibilities live. The key distinction: the custom code is a small extension of a standard feature, not a replacement for it.

Real example: A manufacturing company used standard Salesforce CPQ for quoting but needed a complex pricing calculation that involved real-time API calls to their ERP system. Instead of replacing CPQ, they wrote a single Invocable Apex class that CPQ’s quote calculator plugin called during the pricing phase. The standard CPQ process remained intact — the custom code was a surgical addition, not a rewrite.

Tier 4: Fully Custom Solution

When to apply: There is genuinely no standard feature or reasonable extension that meets the business requirement. This should be rare.

Legitimate reasons for fully custom solutions include: highly specialized UI requirements that LWC standard components cannot achieve, complex algorithmic processing that would be impractical in Flow, real-time integrations with non-standard protocols, and genuinely unique business processes that have no Salesforce analog.

Real example: A logistics company needed a real-time route optimization engine that processed thousands of delivery points with geographic calculations, traffic data integration, and constraint-based scheduling. No standard Salesforce feature or AppExchange package could handle this. A custom Apex service backed by LWC visualization components was the right call. Critically, this was a genuinely unique capability — not a reinvention of something Salesforce already offered.

The 80/20 Rule of Salesforce Customization

Here is the principle I drill into every team I work with: 80% of your org should be standard configuration, and no more than 20% should be custom code. If your ratio is inverted, something has gone seriously wrong.

This is not an arbitrary number. It reflects a practical reality:

• 80% standard means your org can be maintained by admins, survives developer turnover, benefits from Salesforce releases automatically, and stays compatible with the broader ecosystem.
• 20% custom gives you room for the genuinely unique business logic, integrations, and UI requirements that justify the cost and complexity of code.

When I audit an org and find that ratio closer to 50/50 or worse, I almost always find the same patterns:

1. Custom code doing what Flows can do. This is the most common offender. Apex triggers and classes handling automation that Screen Flows and Record-Triggered Flows handle perfectly well. Often this code was written years ago before Flows matured, and nobody revisited it.

2. Custom Lightning components replacing standard UI. Teams building custom record detail pages, custom list views, or custom related lists instead of using Dynamic Forms, standard list views with filters, or standard related lists with custom actions.

3. Custom integrations where a middleware tool or AppExchange package exists. Building Apex REST callouts to Mailchimp when MuleSoft or a native AppExchange connector handles it with configuration.

4. Over-engineering for hypothetical requirements. Building a flexible, configurable, metadata-driven custom framework for a business process that has not changed in five years and probably will not change in the next five. YAGNI applies to Salesforce development just as much as it applies anywhere else.

The actionable version of the 80/20 rule: Before any development work begins, the team must answer one question: “Have we exhausted every declarative option?” If the answer is not a confident, documented “yes,” the work should not proceed to code.

Section Notes

The custom vs OOTB decision is not a technical decision — it is a business decision with massive long-term financial implications. Every line of custom code you write is a liability on your org’s balance sheet. It requires maintenance, creates knowledge dependencies, and reduces your ability to benefit from platform innovation.

This does not mean custom development is bad. It means custom development is expensive, and expensive things should be reserved for situations where the return justifies the investment. A custom route optimization engine for a logistics company? Absolutely worth it. A custom Lightning component that recreates the standard record detail page with slightly different field ordering? That is lighting money on fire.

The best Salesforce architects I have worked with share one trait: they are deeply skeptical of custom development. They treat every custom solution as a last resort, not a first instinct. They know the platform’s declarative capabilities inside and out, so they can confidently say “this genuinely requires code” instead of reaching for Apex out of habit or comfort.

If you take one thing from this post, let it be this: the most maintainable code is the code you never had to write. Salesforce gives you an enormous amount of functionality out of the box. Use it. Exhaust it. And only then, when you have genuinely hit a wall that no amount of configuration can solve, reach for the keyboard.

In the next section, we will look at multi-org vs single-org architecture strategies — another decision that has enormous long-term consequences and where the “obvious” answer is often wrong.