Buy vs. Build on Salesforce

The life of an IT manager is made of many decisions leading to long-term commitments:

  • Choice of technology (.Net vs. Java).
  • Choice of vendor (IBM vs. BMC).
  • Choice of architecture (on-premise vs. cloud).

And then, there’s the famous “Build vs. Buy” which is as much about computing as it is about business operations and risk management. In this post, I’m reviewing this IT classic in a Salesforce world…

Legacy Systems

Because it’s now an old age question, the advantages of both buy and build are well known. So, I’m just listing them as reminders below.


  • Fast implementation speed
    All capabilities being pre-built, the implementation time is reduced to installation and configuration.
  • Business process improvements
    The software business logic is built around best practices.
  • Benefits of scale savings
    The cost of each line of code is shared between customers. The vendor can invest more in security and innovation.
  • Resilience
    The software has been tested by many users and customers before you.
  • Support
    Support is available from both the vendor and the community.
  • Zero technical debt
    The vendor’s business model guarantees a high level of documentation and skills.


  • Feature granularity
    The solution can be tailor-made to exactly fit the current business process.
  • Short terms costs savings
    This is the easiest way to cut corners.
  • Business advantage
    Automates a company business process with a software which is not available off-the-shelf.
  • Keep IT busy
    The skills required to build are available and unused.


Although you can build on the Salesforce platform, it is essentially a member of the “Buy family”.


The Salesforce equivalent of buying is making the most of the components already available on the platform by favouring button-click configuration over code (say 80% code). Think of replacing most of the out-of-the-box business logic like approval processes with code to work around current feature limits. Although technically possible, I don’t recommend it for the main reason that it’s not part of the platform’s DNA, Salesforce started as a highly configurable on-demand CRM with the original strategy to reduce the need for IT involvement (click-no-code). Coding capabilities were rapidly added and, yes, using them all in the same project is possible and exciting for the nerd in you.

Unfortunately, this will also most certainly lead to technical debt. Still, this is what big SIs, coming from the world of J2EE bespoke apps, tend to favour and rarely think twice before building complex, unmaintainable systems.

Also, custom code doesn’t benefit as much from Salesforce constant innovation as much as standard features do.

Your Choice

Think again, you either go with Salesforce, or you go alone…

Don’t Do It

Not doing it is the new kid on the block of enterprise application design, sadly not a popular one though. In the old days, upgrading software was a multi-month long project and IT was often reluctant to upgrade a production environment for the sake of adding new features. As a result, there was quite a lot of pressure on implementation teams to squeeze in as many features as possible on v1 because nobody knew when will they get a v2. As a result, building often was an attractive option.
Now, here is the game changer:

  1. All Salesforce tenants run on the latest version.
  2. There are three new releases every year.
  3. Salesforce is quite an innovative company.

These three facts remove the pressure on feature richness and, instead, offer new capabilities you’ve never dreamt of (mobile, AI, IoT, …). In my post “The million dollars picklist“, I’m telling the story of a customization which has gone too far the custom build way!

When blocked by a feature’s current limitation, don’t start coding, start thinking… Align your application roadmap to Salesforce’s own one. For the bits you don’t know about, the best way to remain compliant with future releases is to stay as standard as possible (buy, don’t build too much). You’re not obliged to say “yes” to all requests from your stakeholders, but you’re obliged to provide good advice! Many businesses are doing great running on “non-perfect” lean apps, whereas others are struggling to grow trapped into technical debt issues of what’s become a bloated org.

Writing code is fun! Thing is, you’re not here to have fun but to leave behind a resilient enterprise class application.

Related Posts & Resources

I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.

Fab 🐸