When does a developer recommend a managed package? 

Here at ProvenWorks you’re going to find some of the biggest advocates for buying a solution off the shelf, or what we call a ‘managed package’. We’re fully aware that when it comes to the Build versus Buy debate, we’re pretty biased. We’re a Salesforce ISV (Independent Software Vendor) so we make a living off creating managed packages that businesses using Salesforce CRM can find on the AppExchange.

This is why we look to get other people into the debate too. We’ve done a number of sessions working with developers to raise awareness over the debate around Build Versus Buy – just watch this session we ran with Bitwise Industries at CenCal Dreamin’ 2022.

You will find an endless amount of content from Salesforce ISVs advocating the choice to buy a managed package. You will also find the same number of developers in favour of developing a custom solution. 

What takes us by surprise is when developers speak out in favour of managed packages. And this happened to us recently. 

helpfulbits, a German Salesforce consultancy who implements custom software and delivers training, recently wrote an in-depth review of our data import solution SimpleImport. 

As a system integrator that writes custom software, but also offers a prebuilt standard solution, helpfulbits are the perfect case study for understanding better the choice between build versus buy.

An interview with a developer on managed packages

We sat down with David Felkel, Salesforce Developer / Architect at helpfulbits to ask for his perspective on build versus buy.

As software developers (who typically fall into the “build” side of the build versus buy argument), what’s your 1-minute elevator pitch for choosing custom development?

Well, if your business has very complex processes that are unique to your segment or industry, it can be difficult to find a software that fits your company off the shelf. The larger your company is, the more likely this will be. Moreover, the larger your userbase is, the higher the return of investment of custom software. For example, it does make a lot of sense to develop a custom software for support agents if you can shave off 1 minute of processing time for hundreds or even thousands of agents – that’s a huge ROI.

Using data imports as an example, we typically choose custom development when there is business logic or any kind of data transformation involved. For example, a customer might have an excel layout that does not directly translate to records in Salesforce. Other clients might need to join data from multiple sheets into single records.

That said, a lot of the time, service providers and their clients internally simply shy away from the process and the bureaucracy involved in procurement, even if there is a good standard solution, because the developers have already been hired.

On the flip side of that, can you share the story of what led you to develop your own out-of-the-box solution, helpful sync?

I’ll gladly do that! Basically, my buddy and me were having a beer and thinking hard about a product that would solve a real-world problem. We figured that we’d need an easy way to push complex data around Salesforce Orgs and Sandboxes, to debug errors in production for example. The situation escalated quickly and we built a sandbox seeder and anonymizer that we and our clients like to use. Back when we started, we didn’t even know such tools already existed and that there was competition. Had we known, we probably wouldn’t have done it. However, we tried some of the existing software and most solutions were not to our liking, as they were either too complicated and cumbersome or too narrow in their scope.

In your review of our solution SimpleImport, you mention that “custom code is not always economical”. What do you mean by that? When do you find that custom development is not the right decision?

Custom software basically has two price tags. One for the solution itself and the other one for maintenance. Custom development is expensive. For the price of a custom solution, you can probably pay the license fees of something like SimpleImport for a few years. Moreover, it is likely that the custom solution will have to be modified and maintained every now and then, for example, when a new Salesforce release is published. Those costs can be comparable to license fees.

Personally I think custom development can only be justified when your business logic is really special and complex and, in the case of importing, the data has to be transformed before it is imported into Salesforce. The latter can often simply be done with an additional excel sheet, though.

Is there anything you think customers don’t give enough consideration to during the build versus buy argument?

I think most customers are already working with their development teams and rely on their opinions and counsel. However, developers in general often don’t like to look for existing solutions. There’s even a name for it, the so called “Not invented here” syndrome. I am guilty of that myself! Most of the time, when it comes to standard tasks, there are off-the-shelf solutions that simply are better and less expensive.

Looking towards ISVs like ProvenWorks, what do you want managed package providers to know? What do you want to tell them?

Pitch your products more to consultants and developers! They are the ones who implement the solution for the customer and who will receive the user story requesting the “Excel Import” for implementation. If they know about your product and like it, they will recommend it during backlog refinements and the like.

About helpfulbits

helpful bits has been pioneering software development in Salesforce since its inception. They are specialized in making large and complex Salesforce orgs easy to maintain, extend and administer.

About SimpleImport

SimpleImport is our spreadsheet data import solution for Salesforce. It’s designed to empower your Salesforce users to import so your business can scale. Learn more about our managed package and get a free trial.

Leave a Reply