Utility Software Development: Build or Buy? Our Comparative Guide Can Help, Part 2

As we finish our two-part blog series about the build vs. buy debate around utilities software, we summarize the pros and cons of each option and consider the benefits of a blended approach.

---

In part one of our series, we explored the considerations a utility company should examine when approaching the build vs. buy decision. Now, we will look at the typical pros and cons associated with each approach, as well as explore a real-world example of a utility company contemplating whether to buy or build a marketplace solution.

You now understand the problem you want to solve, and you may be leaning in one direction or the other based on the answer to some of the eight critical consideration questions explored in part one. To fully understand your options, you’ll want a high-level understanding of the pros and cons associated with each method.

 

Is There a Middle Ground for Utility Software Development?

It is important to note that sometimes the best solution combines build and buy. Let’s take, for example, a typical utility customer My Account solution implementation.

The utility may build a custom customer interface while buying software to support common, though complex, My Account features, including the billing and payment platform, usage insights and widgets, outage map, and so on. This allows the organization to use the best software to support their needs rather than committing to one monolithic vendor solution.

We find this model is becoming increasingly common in the energy and utility industry. In this case, bought software forms the reliable base for common business functions such as billing, work management and CRM while allowing for the flexibility to plug and play as the organization evolves.

The key is ensuring the end user doesn’t feel as though they are using multiple systems, instead having one seamless digital experience.

Building Utility Software in Practice

Utility X, a large electric utility company with multiple subsidiaries, wants to provide customers with an engaging marketplace to purchase smart thermostats, water-saving products, EV chargers and other related products.

They already have an enterprise-approved hosting environment and billing solution but are open to alternatives. They will use a third party for order fulfillment and management. They have considered both building their own front-end web solution or using existing all-in-one platforms, including industry-tailored solutions or popular eCommerce platforms such as Shopify.

 If we approach this scenario from the build approach, here are a few of the common pros and cons: 

Pros

• The utility company will have full control over the marketplace’s features, content strategy, and the desired customer journey through the platform’s design and user experience. They can seamlessly integrate the user experience into their existing customer platform and user interactions rather than having the user go to a separate URL.
• The utility will own the code, allowing them to make feature additions and changes as needs arise rather than relying on a third party.
• The platform can align more closely with existing utility infrastructure, enabling features like single sign-on, using saved bill payment preferences for purchases, and more.
• The marketplace platform can use existing customer data and insights, such as information about their past billing history, usage and home profile. This platform can also deliver personalized recommendations to help guide customers to the right products.
• There are no ongoing platform license costs with this model. However, there will be costs associated with hosting, payment processing, inventory management and fulfillment.
• The organization has multiple subsidiaries, each requiring its own marketplace with slight differentiations based on product offerings and branding, there is an economy of scale in sharing the design and development costs. In the SaaS model, vendors would traditionally treat each marketplace separately, incurring high licensing costs, though they may offer contract discounts.

Cons

• Existing marketplace solutions have perfected workflows and invested heavily in their platform designs, allowing the utility company to benefit from their research and understanding of customer needs. As this is outside the traditional service delivery model within utilities, they may not have the required eCommerce background to successfully execute a marketplace solution.
• With a custom solution, they will go through the traditional project phases, including discovery, design, development and testing. All of these steps will add up to an overall longer project timeline and, in many cases, cost over an off-the-shelf offering.
• The organization will need to support the application through ongoing maintenance and feature development, requiring the use of an external support vendor or the allocation of internal team members to the project. Utility X may not have the budget and bandwidth to support this approach.

While it would be simple to say one approach is better than the other, in this case, that would be incorrect. In this situation, both options have valid pros and cons. The best approach for Utility X will depend on the findings from the discovery phase of the project, whereby they will uncover factors such as success criteria, feature requirements, resource availability, vendor evaluation and so forth.

Conclusion

 Whether to build or buy software is a complex decision that requires considering numerous factors.  While building software provides you with the highest level of flexibility and control, it requires investing in planning, time and budget. While buying software may save time and expense, it can limit your platform’s scalability and features.

Before making any decisions, start with the eight questions we provided in part one, and do a full discovery phase to weigh the pros and cons of each option against your needs. We recommend bringing in an advisor to help you determine the best path for your utility software development.