When to Build a Custom Salesforce App Instead of Configuring

Short answer: configure first, every time. Build custom when the logic is a genuine differentiator, when it must run outside a single record's lifecycle, or when you are rebuilding the same workaround for the third time. The trigger for building is not complexity, it is repetition and ownership: complexity you configure once is fine, complexity you re-explain every quarter is not.

What is the difference between configuring, extending and building?

• Configure: standard objects, page layouts, validation rules, Flow. No deployable code, and it upgrades with the platform.
• Extend: custom objects and fields plus a little Apex or a Lightning Web Component around a mostly standard process. Still Salesforce-shaped.
• Build: a designed application. Its own data model, services, tests and release cycle, whether that ships as Apex and LWC in your org or as a packaged product.

Most arguments about "build versus configure" are really arguments about the middle one, where the honest answer is usually to extend rather than to start a project.

Why is configure-first still the right default?

Salesforce's own guidance has been consistent for a decade: evaluate the native and declarative features before you write code. Declarative work carries no test code, no repository and no upgrade tax, and it moves forward automatically with each release. The limits also behave differently. Declarative work runs into design limits, such as how many rules you can put on an object, while code runs into execution governor limits like SOQL query counts, which are much harder to design around (Salesforce Developers).

The floor also keeps rising. Workflow Rules and Process Builder are no longer supported after 31 December 2025, new ones cannot be created, and Salesforce points teams at the Migrate to Flow tool (Salesforce Ben). Anything you build today competes with what the platform will absorb tomorrow, which is an argument for building less, not for building nothing.

Where does configuration stop paying off?

These are the five trip-wires we use. One of them is a conversation. Two or more is a decision.

1. The flow has become a program. If nobody can predict the outcome by reading it, and a change needs a careful afternoon, you already have software. You just have it in a format with no tests, no code review and no diff worth reading.
2. The requirement is a data model, not a screen. Reporting that needs three unrelated objects joined, or a hierarchy the standard model cannot express, is a design problem. Configuration will produce a shape you have to work around forever.
3. The behaviour lives outside one record's lifecycle. Scheduled work, high-volume event ingestion, cross-system reconciliation, retry and idempotency. Declarative automation is triggered by records; these things are not.
4. The logic is your competitive difference and it changes often. Pricing rules, routing intelligence, entitlement logic. Anything where being 10% better than a competitor matters deserves tests, versioning and an owner.
5. You are paying for it three times. The same workaround rebuilt in a second country, a second business unit, a third client org. That is not configuration any more, it is an unpackaged product.

How do you compare the real cost honestly?

Not build cost against configuration cost. Compare three years of ownership on both sides.

• Configuration carries: admin time per change, regression risk nobody measures, onboarding cost for each new admin who has to learn the workaround, and a cap on what you can ever automate.
• Custom carries: initial engineering, test coverage, code review, an upgrade path across three releases a year, and the risk that the platform ships your feature for free next year.

The comparison usually turns on one number that nobody writes down: how many times per year the process changes. Frequent change favours code with tests, because tests are how you change something safely. Rare change favours configuration, because nobody has to maintain the muscle.

What does "build" actually mean now?

Rarely a from-scratch application. In practice it is one of four shapes: Apex and Lightning Web Components inside the org; a packaged component you install into several orgs; a managed package on the AppExchange; or a service outside Salesforce that the org calls through an API or an MCP server, with an agent action in front of it.

The packaged options matter more than teams expect. Building as a package forces the versioning, the upgrade path and the isolation you would otherwise skip, and it makes the second and third deployment nearly free. This is the discipline we brought from product work into implementation: because Tekunda builds and ships AppExchange products as a PDO, our implementation work inherits reusable, tested components rather than rebuilding each one.

How do you keep a custom build from becoming the next mess?

1. Give it an owner and a deprecation plan on day one. Code without an owner becomes configuration nobody can read.
2. Keep configuration values in custom metadata, not in the code. The whole point is that the business can change them without you.
3. Write the tests as the specification, not as a coverage tax.
4. Re-check each release whether the platform has caught up. Deleting your own code is a legitimate result.

Done well, the payoff is not an elegant architecture, it is operational. For ASSA ABLOY we took weekly cases from 3,000 to 350, a 93% reduction across 11,000 connected devices and up to 2.5 million events a week, in three markets and with no added support staff. That volume was never going to be a Flow. If you are weighing the same decision, talk to us before the build, not during the rescue.

FAQ

Is custom code always more expensive than configuration?

No. It is more expensive to start and often cheaper to change. Compare three years of ownership, including the admin hours and regression risk configuration quietly consumes.

How complex is too complex for Flow?

Use a human test rather than an element count: if a competent admin cannot predict what it does by reading it, or cannot change it safely in an hour, it has become software.

Should we build it or buy it from the AppExchange?

Buy when the capability is a commodity and a listed app covers most of the requirement. Build when the logic is the reason customers choose you.

Does going custom lock us out of platform upgrades?

Not if it is built as a package with a version and a test suite. What blocks upgrades is undocumented code with no owner, and that happens to configuration too.