Redefining OOTB vs Custom in an AI World [New Decision Criteria]

How does AI change the OOTB vs custom decision in Salesforce? AI-assisted development makes targeted custom solutions faster to build and easier to maintain, shifting the threshold where custom work becomes justifiable. The deciding factor is time-to-market: if Salesforce’s roadmap won’t deliver what you need for six months, and you can build it in two weeks, the answer is often clear. But this doesn’t mean “go custom everywhere.” It means the trade-off calculation has changed, and architects need to recalibrate.

The case for staying close to Out-of-the-Box and low-code in Salesforce still makes sense. You get license value: new features, roadmap alignment, products designed to work together. Point-and-click has real strengths. Faster iteration. Changes closer to the business. Admin teams that can own large parts of the lifecycle without waiting for developer sprints.

I’m not here to argue against any of that.

Where It Gets Interesting

The edge cases are where this conversation matters.

Business processes that don’t quite fit the product’s standard model. Areas where a pure low-code approach starts bending under complexity. Teams stuck between “almost fits” and “we simply can’t support this requirement.”

I’ve seen the workarounds. The screen flow with 47 decision branches that nobody can debug. The formula field that’s actually three formula fields chained together because you hit the character limit. The integration that exists only because Flow couldn’t handle the error scenarios. The custom object that mirrors a standard object because the standard one didn’t allow the field types you needed.

These aren’t failures of low-code. They’re symptoms of forcing a solution into a shape it wasn’t designed for.

AI Changes the Math

Here’s what shifted.

AI-assisted development has made custom work dramatically faster. Not marginally faster. Dramatically. The effort required to build a clean LWC component with proper Apex backing is now comparable to configuring a complex Flow. Sometimes less.

At Tucario, we’re building ISV-grade products with AI assistance. Features that would have required weeks of development now take days. The same discipline applies to internal custom development. Architecture review, testing strategy, documentation. None of that disappears. But the development velocity has changed the equation.

This matters because the traditional argument was: “Custom costs more to build and maintain. OOTB might not be perfect, but the lower total cost justifies the compromises.”

That argument assumed certain effort ratios that no longer hold.

The Time-to-Market Question

Here’s the question CTOs and architects need to ask themselves.

Salesforce has a feature on their roadmap that would solve your problem. It’s coming in two or three releases. Maybe six months. Maybe a year. The business needs the capability now.

Do you wait? Or do you build?

The calculus has changed because “build it in one or two weeks” is actually achievable now. Two years ago, that timeline meant cutting corners. Today, with AI assistance, you can build properly and still ship fast.

What the Skeptics Are Thinking

I can hear the objections.

“This sounds like an architect advocating for more custom work. More billable hours. More job security.”

Let me address three concerns directly.

Maintainability

AI-generated code still needs ownership. Someone has to test it, document it, and maintain it when things break. “More custom” isn’t the goal. Deliberate custom is. If your team can’t explain how the solution works or extend it when requirements change, you haven’t built a solution. You’ve built a liability.

The maintainability bar doesn’t lower just because development got faster. If anything, it matters more. When you can generate code quickly, the discipline to review, refactor, and document is what separates sustainable solutions from technical debt factories.

Total Cost of Ownership

Monster Flow workarounds often cost more than clean custom solutions. I’ve audited implementations where the admin team spent more time maintaining a complex declarative solution than a developer would have spent maintaining equivalent Apex.

The hidden costs of OOTB workarounds include:

• Debugging time when something breaks and the logic is spread across five Flows
• Training cost when new team members can’t understand the solution
• Opportunity cost when changes take weeks instead of days because nobody wants to touch the fragile configuration

When you compare honestly, custom isn’t always the expensive option.

Platform Roadmap Risk

This is the real concern. What happens when Salesforce releases an OOTB feature that overlaps your custom solution?

The answer: check the roadmap before you build. Don’t build what’s coming in six months. But if Salesforce isn’t planning to solve your problem, don’t wait forever hoping they will.

The New Question

“OOTB or custom?” is the wrong framing now.

The better question: How do we combine the strengths of the platform and low-code with AI-assisted enhancements, in a way that remains maintainable and under control over the long term?

The boundary between “justifiable custom” and “unnecessary complexity” has moved. AI didn’t eliminate the trade-offs. It changed them. Recognizing where that line sits now is part of the architect’s job.

Where I Land

Time-to-market matters more than ideology. If staying OOTB means waiting six months for a feature the business needs now, and you can build a maintainable solution in two weeks, build it.

But know the roadmap first. Check what Salesforce is releasing. Check their Idea Exchange. Read the release notes. Don’t duplicate what’s coming soon. And don’t wait indefinitely for something that might never arrive.

AI makes building faster. It doesn’t make building well automatic. Ownership, testing, architecture discipline: none of that goes away just because the code writes itself faster now.

The effort doesn’t disappear. The threshold has shifted.

---

This article expands on a LinkedIn post. The original: