There’s always the temptation to build large software projects, like pricing and forecasting solutions, in-house. You can build exactly what you need if all the right resources are available, and maybe even save on total cost. But the reality rarely lives up to the dream. Project issues are plentiful and even if you get your project over the line, retailers face siloed teams and expertise, extensive maintenance, and greater total cost of ownership (TCO). There’s a reason energy retailers globally are turning to Gorilla.

As the Australian energy sector grapples with rapid change, market volatility, and the transition to renewables, many companies find themselves at a crossroads: adapt quickly with new technology solutions or risk falling behind competitors in an increasingly complex National Electricity Market.

While in-house development offers the allure of tailor-made systems, it comes with its own set of hurdles. From resource allocation and technical debt to compliance with the Australian Energy Regulator, integration with legacy systems, and the Australian Energy Market Operator, energy retailers face a complex landscape when embarking on internal software projects.

This blog will explore the key difficulties Australian energy retailers encounter when developing software in-house, and highlight why so many are turning to industry specific pre-built solutions. Whether you're considering a major in-house project or looking to improve current development processes, understanding these obstacles is crucial for success in today's dynamic energy market, from Queensland to Victoria and beyond.

The dream of in-house development

It’s easy to understand why companies are tempted to build their own solutions. Create exactly what you need for your customer management, or billing, or pricing, or forecasting, with no unnecessary features or wasted resources. Yes, previous major IT projects have been incredibly difficult and expensive, but maybe things will work out this time?

The world of software development has certainly become a lot more streamlined. Very little is being built from scratch; as soon as you start a new project you’re grabbing every code library and suitable service you can find. AWS alone can provide practically all the scaffolding needed, from Athena to WAF (not that many analytics apps need web security, but you get the idea…). The problem is that all these extras are better described as “necessities” rather than “simplicities”. No one is using Docker because they love how user friendly it is. Containerization has become a fact of modern software development, which means you add Docker or K8s or both, and all the associated work that comes with. 

An alternative is to take a mid-step and use a Platform as a Service. Let SAP or Oracle handle the grunt work and build your application in their walled garden. You won’t have total freedom nor access to the world of open-source, but a PaaS can take away a lot of hassle - for a price.

The reality of in-house nightmares

In dreamland, you find the money and the skills, build a timeline and set up project management, create a realistic scope with the majority of features needed, and get started. In reality, you desperately try to avoid ending up on the list of “Great Software Failures” alongside Queensland Health, Myki and Myer.

Budgeting for an in-house development is complicated, but not impossible. As long as things don’t go catastrophically wrong, a retailer could put together a project that beats any third-party vendor on price, but this will last right up until the first expert leaves or the platform goes down. Hidden costs are the silent killer of in-house projects. When you purchase a SaaS solution, you can be safe in the knowledge of a certain service-level agreement and a large, dedicated team for maintenance and upgrades. You know precisely what you are getting and how much you will pay for it. If your own platform goes down, there is no one to blame or costs to recover. You will need to keep a full maintenance team staffed. The loss of internal expertise can be particularly crippling, taking years to replace.

And this is assuming that things don’t go wrong. A list of the challenges that a software project could face would stretch longer than this entire blog. Let’s list a few examples:

• Resource constraints, including skilled people
• Budget limitations
• Integration with legacy/modern systems
• Integration with market systems
• Building for scalability
• Compliance with energy industry regulations
• Compliance with data protection regulations
• Cybersecurity
• Managing tech debt
• Managing shadow IT
• Staff training
• Change management
• Time-to-market pressure

There really are a lot of very good reasons why SaaS providers are becoming the default choice. Even the use of Excel as an all-purpose data workhorse arises from a lot of these pressures, although spreadsheet software brings its own set of drawbacks.

But it’s more than just avoiding challenges. Exploiting comparative advantage is how companies set themselves apart from the pack. Where are retailers looking for this? It isn’t in writing code or building software teams. The focus of an AGL or Origin will be managing the energy transition, ensuring that customers receive a high level of service while delivering on net-zero promises for 2035 and 2050. Cutting costs and improving operational efficiency are important, but even if budgets were infinite there is still only so much time to go around. Software as a service has become the standard model because the service part really matters. SaaS lets energy companies be energy companies.

Why not Platform as a Service?

What about the Oracles and IBMs of the world? There’s clearly a place for platforms like these; why not turn to them to manage your pricing applications? Maintenance & time-to-market is reduced and there are a host of add-ons, consultants, and integrations to swiftly tailor something to your needs.

If an in-house solution aims to keep costs lower, going down this route can quickly blow up in your face. Once you paid for Oracle, an Oracle specialist, your implementation consultant, an integration platform like Mulesoft, and any add-ons, you’ve probably blown past the TCO of buying a specialised solution. What do you get in return? The added convenience and deployment speed might solve the issues around focus described above, but there is no certainty around verticality. Microsoft, SAP, and others have incredible levels of internal knowledge, but they don’t know pricing for energy retailers.

Unless the PaaS supplier offers an energy-specific platform, customization constraints inherent in many PaaS solutions could hinder the implementation of industry-specific features or integration with proprietary systems common in energy retail. Performance requirements for real-time pricing and demand forecasting may exceed the capabilities of generalized PaaS offerings. Additionally, the sensitive nature of customer and consumption data in the energy sector raises compliance and security concerns that may be more effectively addressed with a solution that is purpose-built for energy. The highly regulated nature of the energy sector often requires granular control over data storage and processing, which may be limited in PaaS environments. 

There are even more specific platforms: if we take pricing as an example, this is largely a data challenge. Snowflake describe themselves as Data-as-a-Service and would be able to avoid issues around performance and data compliance that wider platforms suffer from. Nonetheless, performance and compliance are still not addressing the things which make energy retail energy retail. You are diverting your pricing experts to spend time on software development instead of areas where they can generate business value. You remain reliant on experts who might leave you with major replacement headaches: Python, Snowflake, Energy is a very rare combination of skills.

What should retailers do?

In-house is out. PaaS solutions have their own set of issues and don’t deliver on specific energy use cases like pricing or forecasting. Fortunately, there is an answer, one that many retailers around the world have already discovered. Gorilla has become the de facto choice for pricing and forecasting, with Synergy, and Meridian in New Zealand joining the likes of British Gas, Shell, EDF, and SEFE as Gorilla users.

There simply aren’t solutions out there that can boast the level of energy experience and expertise that Gorilla can. There’s no need for extensive customisation for energy scenarios; Gorilla’s applications work for energy retailers out-of-the-box. At the same time, Gorilla’s delivery process is flexible and able to fit to the unique needs of each customer.

Data siloes are almost inevitable with in-house software as they are inextricably tied to the experts who built them. It’s difficult to train new users or socialize findings to the wider organisation. Gorilla overcomes these problems. It’s a system that is fully auditable and transparent, allowing anyone to understand how results are produced and where data is stored. New staff can learn how the company does pricing or forecasting with industry learning certifications, leading to teams building knowledge across pricing, analytics, data, sales, and IT.

What is more, TCO ends up lower when you opt for Gorilla. Buying a SaaS platform like Gorilla gives you a completely different time-to-value; Gorilla has achieved go-live times of under 6 months with some customers, and an MVP can be ready even sooner. Can you wait for 18+ months for an in-house team to return something functional?

And that’s just the start. Once your in-house solution is finally ready, how long will updates take? Are you going to wait months for IT resources to become available? Once the project is completed, get ready for everything to become a fight - fights over maintenance responsibilities, fights over which budget is used, and fights over pushing updates to production systems.

Gorilla doesn’t have any surprises or hidden costs. You know exactly who is doing maintenance and updates, and when they will occur. Low-value activities are automated, freeing up your experts to focus on areas with the most value-add, with no need to divert attention to maintenance or feature development.

Final Word

The siren song of in-house applications is strong, but will dash your hopes upon the rocks. Even if you can avoid the troubles that plague major software projects, hidden costs and long-term maintenance end up turning cost savings into greater losses. Building on top of platforms, whether broad cloud development solutions or specialist data platforms, offers the chance to solve some of these problems, but introduces new issues around customization and performance. And both fully in-house and PaaS options pose the same question: why are you putting so many resources into non-core parts of your business? Energy retailers need to focus on energy retail, not software. Get the best energy software you can find to support your teams and let them get to work. Right now, that means Gorilla. Ready for a faster, less risk alternative to self-build? Let’s talk.