Debunking the 4 Myths of Building vs. Buying a RetEx Platform

Has your IT team considered building your retail execution or field team management platform rather than buying one from a software vendor? All we can say is WAIT! There may be some hidden costs to consider before undertaking a project of that scale.

In this blog, Repsly’s CEO, Mat Brogie, and Chief Product Officer, Peter Billante, help break down some of the most common myths about building vs. buying a platform they’ve heard over their years of experience in the industry.

4 Myths of Building vs. Buying a RetEx Platform

The reality is, most brands and merchandisers who chose to build technology instead of buying, don’t have the full picture of the journey they're about to embark upon. And its a hard journey to map out. Building a retail execution platform comes with a number of large hidden costs of upkeep and maintenance that most teams are unaware of when scoping out the build of a new platform.

Myth #1. Our brand or merchandising team can build a cheaper platform than buying one.

While you’ve probably heard that mobile applications can be simple to build, a mission-critical application that needs to support hundreds to thousands of field reps around the world every day requires much more support and constant attention. And with so many different platforms of choice available, it’s much easier and cheaper to use an existing platform and mobile application that will almost certainly come with dedicated support. This is namely because when you partner with a software vendor, you’re typically also buying their performance aspects, security aspects, and external support as well.

“Ongoing support costs for packaged solutions can be very predictable, while support and maintenance of homegrown solutions involve factoring developer focus, mobile-specific build environment, mobile support infrastructure, and rapidly changing device landscape,” Mat Brogie says.

When calculating the cost of your build, you should also consider the technical complexity of your business. Mat explains that enterprise solutions differ from consumer applications in that they often incorporate technology extensions such as barcode or RFID scanners, significant on-board data management, enhanced security measures, and synchronization complexities, all of which create additional work and expenses for the company.

Myth #2. There is no existing retail execution platform that meets our CPG field or merchandising team’s needs.

This is a very common myth in the thought process of building vs. buying a tech solution.

Some IT teams feel that they’ve gathered the proper requirements from their business stakeholders, and then look into the market, and find no one vendor does exactly these 10 to 100 things they need to fit the bill. 

However, the reality is that many companies including ones like Repsly, SAP, Oracle, and Salesforce.com have built flexible solutions for exactly this – i.e. a platform built on a standard set of functionality that almost every company in the industry needs. These software vendors have spent decades perfecting their products with industry best practices and customer feedback. Our experience is that it is almost never worth your company paying for the nth level of customization to build a homegrown solution.

It’s worth considering how different your company operates from others in the industry. At the end of the day, most companies don’t say yes, I’m that different. Pete Billante explains that most CPG companies end up looking at their requirements, and boil them down to what is most important for key use cases, and choosing the path to tailor a pre-built platform to meet their needs. “Good software companies know that they need to handle a wide variety of use cases, that customers can then make configurable to their operations,” Pete says.

Ultimately - you should consider adapting some of your requirements to conform to the best-in-class applications on the market, as opposed to building an application to meet your exact, nuanced requirements.

Myth #3. Our  team has the competencies to build the platform and continue to support it after it’s been built.

This is the last checkpoint before a company ultimately decides to go the homegrown route. Once a company has decided there is no platform in the market for them, and they have the technical competencies to build their own, they begin the long process of a build.

Pete Billante explains that when companies decide to go through with a build process, it generally starts off with excitement and buzz around the potential build. And if they’re in luck, the initial product is launched with ease and satisfaction, on schedule. It’s important to note this moment in the process because this is typically the peak of satisfaction amongst the entire team. “We’ve learned over the years from our customers that from this point on, satisfaction for the homegrown solution generally takes a steady decline because once everyone goes back to their regular day jobs, hundreds of requests and updates from business stakeholders inevitably come in,” Pete says.

There's a new version of iOS? You have to test it out. A new Android was released? You’ll have to test that too for no bugs. Requests, updates, new security requirements, etc. are unavoidable when building and supporting a technology solution. Unless you’re a dedicated software company with full-time dedicated engineering resources, these aspects are easy to overlook and can put your teams in a bind when they realize they need to continually invest in the platform for the long haul. And hiring a chief architect of security, or a dedicated support team that can focus exclusively on your platform will be incredibly expensive.

Myth #4. Our CPG brand or merchandising team can launch the product in a reasonable timeframe. 

When examining the timeframe of an application build, there are several considerations to take in. Mat explains that implementing an ‘Out of the Box’ solution doesn’t mean ‘click this link and run install’, and getting to production in a ‘self-built’ environment isn’t congruous to the development timeline. For a purchased solution, the timeline has to include environment set-up, integration, customization, test, and training. For homegrown solutions, there is typically a longer upfront design period, as well as extended test cycles that must be accounted for. Additionally, purchased software likely have existing online or in-person training and enablement processes, while all of this must be created net new for in-house developed software.

As a product manufacturer, your company's core competency is in making a great product for your consumers, and getting it to market. It's very difficult to develop the core competencies of an industry-leading software company, including UX design, software development, customer support, and technical support. This is why industry-leading brands look for the best solutions they can buy off-the-shelf to run their business, so they can focus all their energy on making and selling the best products on the market.