Every Salesforce engagement eventually faces the same question: should we build this with configuration, or do we need to drop into Apex and custom code? Get the answer wrong in either direction and you will pay for it in technical debt for years.
Both directions are mistakes
The custom-versus-configuration debate usually gets framed as if code is the risky choice and clicks are the safe one. That is only half right. Over-customizing is a real and well-known failure mode: you end up with Apex doing what a Flow could have done, code that only one departed contractor understood, and an org that fights every upgrade. But under-customizing is a failure mode too, and a quieter one. Teams contort themselves into fragile chains of Flows to avoid writing fifty lines of clean, testable Apex, and the result is harder to maintain than the code they were avoiding.
The goal is not to minimize code, and it is not to minimize clicks. It is to match the implementation approach to the actual complexity and lifecycle of the requirement. Salesforce gives you a spectrum, from pure declarative configuration to full custom development, and the skill is choosing the right point on that spectrum for each problem rather than applying one philosophy to everything.
The decision framework
Work through these questions in order. The first yes that fits usually tells you what to do, and writing the reasoning down is what keeps the next person from second-guessing it.
- Step 1: Can Flow or declarative tools do this cleanly? If yes, use them.
- Step 2: Will declarative work but only just barely, with awkward workarounds? Build it declaratively anyway if it is simple, but document the boundary you are pushing against.
- Step 3: Is this a one-off business process or a reusable pattern that will appear in many places?
- Step 4: How often will this change? Configuration is far cheaper to change than custom code.
- Step 5: Who will maintain this in three years, and will that person know Apex?
Notice that only two of these five questions are about technical capability. The rest are about reuse, rate of change, and ownership, because those are what actually determine long-term cost. A piece of logic that is technically buildable in Flow but will change monthly and be owned by an admin is a very different decision from logic that is complex, stable, and owned by an engineering team. Same platform, opposite answers.
When to use Apex and LWC
Reach for custom code when the situation genuinely calls for it. You are building a reusable component that will be used in many places, where the cost of building it well is amortized across all of them. The logic is genuinely complex, spanning multiple objects and steps with branching that does not fit comfortably into Flow. You need performance that declarative tools cannot deliver at your data volumes. Or you need integrations with external systems that require explicit, robust error handling.
When you do go custom, treat it like the software it is. Apex deserves test coverage, version control, and code review, the same as any production codebase. Custom that is built and maintained with engineering discipline is an asset. Custom that is dropped into the org once and never tended becomes the technical debt everyone warns you about. The code itself is rarely the problem. The lack of ownership around it is.
When to stay declarative
Stay declarative for the large category of work that is exactly what the clicks-not-code tools were built for. Single-object automation. Simple field updates. Approval processes. Most validation rules. The workflows your admins will edit regularly as the business shifts. Anything where the honest answer to "who will own this in two years" is an admin rather than a developer belongs in configuration, where that admin can actually maintain it.
The deciding factor is usually ownership and rate of change, not raw capability. If the requirement will be tweaked often by the people closest to the business, keep it in tools they can touch without a deployment. The right call is rarely about what is possible, since almost everything is possible both ways on Salesforce. It is about what will still be maintainable, by the people who will actually own it, years after the project that created it has wrapped.