Ask any consultancy about its delivery methodology and you will hear a version of the same principle. Use out-of-the-box functionality first. Configure before you build. Go custom only when the platform genuinely cannot do the thing you need. 

I understand why that became the rule, and for most of my career it was the right one. Custom was slow to build, expensive to maintain, and it was usually the reason upgrades hurt. Configuration was the safer bet almost every time, so making it the default saved a lot of projects from themselves. 

I still consider out-of-the-box seriously on every build, and I am not arguing that anyone should stop. What has changed is that it is no longer the automatic answer. I now expect to have the conversation properly rather than reach for the rule and move on. 

The rule rests on an assumption about cost, and the cost moved. 

We can build a custom solution with AI considerably faster and cheaply than we could two years ago, whether that sits inside Salesforce or alongside it. What I find more interesting is what that does to the cost of being wrong. Something produced quickly can also be thrown away and rebuilt a year later without significant investment. A build decision used to be something you lived with for the life of the platform. It is closer now to something you can revisit. 

There is a second debate hiding inside the word custom, and it is worth naming. A good deal of what these tools now produce inside Salesforce is a flow or a screen flow, assembled with AI, and plenty of people would not call that custom at all. So part of what I am describing is a line that has moved. The old rule was written when configure and build sat much further apart than they do today.

What a client wants from a business system is a streamlined experience for the people who sit in front of it every day. That is what the project gets judged on twelve months later, long after everyone has forgotten which approach we took. 

The trade you make going out-of-the-box is that you stay tightly coupled to the vendor’s frameworks and their ways of working. Sometimes that trade is a fair one. Sometimes the person doing the job pays for it in clicks and workarounds for years, and nobody ever goes back to reopen the decision.

This is part of why our discovery looks different than it used to. A discovery once ended in a level 3 process map: activity boxes, swim lanes, a black and white picture of a future state that does not become real to the client until a showcase weeks or months later. We have changed our delivery methodology at J4RVIS so that the client sees a working prototype in week one, down to the individual field, and we edit it live in the workshop with them in the room. You find out what the experience needs to be while it is still cheap to change your mind about it. 

Every one of those four is a question about what you will be living with afterwards, and all four are answerable in an afternoon. 

In April, Salesforce announced Headless 360 and put the question plainly: why should you ever log into Salesforce again. Everything on the platform is now an API, an MCP tool, or a command, and agents can use all of it. 

When I read that, my heart sank a little. If the experience increasingly sits somewhere other than the platform’s own interface, a great deal of what implementation partners have built their craft around changes, ours included. I am not the person to tell you where Salesforce goes next; I am too far into delivery to make that call. I can tell you how it landed with someone who builds on it. 

It also makes the out-of-the-box question sharper. If the interface is going to be assembled rather than inherited, then working out what the experience needs to be stops being a nice question and becomes most of the design.

I have not swapped the old rule for a new one, and I would be wary of anyone who has. 

What I have done is stop letting the rule answer the question on its own. Before we settle an approach I want to know what the person’s day looks like, what the platform underneath will genuinely support, what it would cost us to change our minds in a year, and whether the people testing and training on it are set up to succeed. When those four have honest answers the decision usually makes itself, and it lands on out-of-the-box more often than this article probably makes it sound. 

If you run delivery, or you own a platform somebody is about to build on, I would like to know how you are making this call now. Specifically, what you have started asking in the rule’s place.