Why Free is Not Free. The true cost of free

YOU HAVE A NEED

Many of the tools required to manage any complex (i.e. most) Salesforce implementations are not provided as part of the platform; requirements capture, process mapping, metadata dictionary, impact analysis, release management, governance, training, feedback and backup.

BUT WE CAN ONLY AFFORD FREE

Rarely is free ever free. There is ALWAYS a cost, even if it is not a financial cost to purchase an app. So, you should evaluate that cost and be able to build a business case or justification for the approach you have chosen.

Many just opt for a “free option” because it is “easy” or “we don’t have any budget”. But maybe spending time building a business case is easier than struggling with “free” especially you add up all the costs.

The costs are

• Financial — Buying the app, so the license costs per editor, user or Org
• Time — The effort required to build, support, enhance and document. The effort to learn and use it. The effort to work around the limitations.
• Risk — The risks which could be operational, technical or security

Costs of risk

• Operational; Is it slowing down the ability to deliver apps quickly? Does it support the implementation lifecycle properly? Are we missing opportunities? Is this app strategic and if it stopped being available / working is that an issue?
• Technical; Does it fulfill the requirements in terms of functionality, architecture and scalability?
• Security; What does the approach expose us to in terms risk or liability?

OPTIONS AND HIDDEN COSTS

Let’s look at the options and (hidden) costs of each “free” approach:

• Existing office tools: DOC, XLS, Quip; you already have licenses for tools like MSOffice, GoogleDocs or Quip. But these are not apps. There will be manual effort to work around their functionality and security limitations.
• Build your own: You have the skills to build anything in Salesforce. But there is the effort to support and enhance. Oh — and document.
• Non-ISV developer: An app built, supported and maintained by someone in their free time. How do you rely on this? What happens when their circumstances change so they no longer have as much free time? What is the roadmap and how quickly will they respond when changes are made to other apps they integrate with i.e. Salesforce changes APIs? How do they support customers?
• ISV Open source: An app built, supported and maintained by a collective in their free time or a company who make money out of support. This has some of the issues with the previous point, and/or it is like a paid app, but with a different pricing structure.
• ISV Freemium: The free app is a teaser to get you to pay for the full functionality which has a cost. Or to buy another app from the company. Be clear, freemium is a marketing technique.
• ISV Ads: Rare in enterprise apps because of the limited number of eyeballs.
• ISV “Free not Free”: There are apps on the AppExchange listed as free where free means freemium or free 14 day trial. Clearly not FREE. The AppExchange are starting to make sure that the true cost is clear, but there are a lot out of apps listed as free.

Question: Why not build your own CRM using free tools like XLS rather than invest in Salesforce? Surely the same arguments apply? Answer: We need more functionality than a simple XLS.

Question: If there is an ISV with team of developers building and maintaining an app which has a roadmap of enhancements from customers, then why do you think you can build something yourself alongside everything else you are doing Answer: You may have far simpler requirements or you have underestimated the effort/cost/risk.

The going in assumption should be that if there are ISVs that have a paid product that customers are using, then there must be a good reason. When you look at a free app and think “this this too good to be true” then you are probably right.

SOME EXAMPLES

Backup: The issue is not actually backup, but restore. The backup only becomes important when you have lost data and then you want to restore it. How easy is that from the daily or weekly CSV file export you take? How much time will be wasted by you, but also the sales team, who are waiting for the data to be restored. Will all the data be restored — what about file attachments to records? Factor this into the evaluation of a product like OwnBackup and others.

Org Impact analysis: Your field deletion or metadata update decisions need to be based on valid, complete and up to date where used / field trip data. If you get this wrong, what is the time, cost and risk of fixing the ensuing chaos? You could build metadata dictionary using an export or the MetadataAPI and then use free field analysis apps or the DependencyAPI to build a where used picture. How much time will this take to put together? How do you keep this in sync with Prod and Sandboxes? I recently wrote a blog with the key requirements for a metadata dictionary: spoiler alert. XLS is a really bad idea. Which is why Elements.cloud exists.

Release management: How much time do you waste wrestling Change Sets with no understanding of the risk impact of any metadata item change? How often do you push a change through your deployment pipeline (Sandboxes to Production)? And then you may need to roll back? Ideally this is tied back to user stories. Add this effort up over time and at some point there will be an ROI to buy a release management app like Copado and others.

BUILDING A BUSINESS CASE

Just because you don’t have financial budget you shouldn’t just put up with office tools or just look for free apps. You may be able to build a business case for purchase, based on the effort taken to use free apps and the opportunity cost.

How to build a business case to buy an app:

• Be clear about your requirements BEFORE you start looking for apps. What are must haves? What compromises will you make?
• Understand and quantify the time savings, reduction in risk effort, lost opportunity cost of using an app vs free.
• Run a pilot/trial to validate the app vs your requirements and the value
• Phase the roll out. Start small with a tightly scoped pilot to minimize license costs from which you can get the data to build a bigger business case for roll-out.

We created an ROI calculator which can be downloaded here