Build vs. Buy: The benefits of SaaS

October 2, 2020

Build vs. Buy: SaaS

At Blicker we offer a Software as a Service (SaaS) product to the utility industry that tackles a common pain point: meter reading. We let companies simplify the process and reduce the occurrence of bad readings by automatically reading a meter from a photo. Potential customers often express enthusiasm when learning about our approach, but at the same time someone within their organization will often raise the following question:

“Maybe we can develop this solution within our own team of data scientists & software developers… could that be a cheaper option?”

Building your own software always looks very appealing. You have a clean slate and full control over the development of the final product. It will allow you to develop exactly the set of features you need and it can perfectly fit the existing systems and processes inside your organization. Furthermore, you’ll not be dependent on another company to maintain the service and all of the customer data will remain in house.

However, it’s easy to underestimate the effort that goes into the development of a product. To help you make an informed decision when it comes to building or buying a SaaS solution, we would like to share what goes into the development of a product like Blicker.

Machine learning is hard work

Blicker uses machine learning to detect and read meters in images, and machine learning often appears to be a deceptively convenient solution. Simply feed it example images of meters and give it some time, and it’ll learn how to read them all by itself. Arguably the most time-consuming and costly part of the process is often overlooked: building this dataset of examples.

To teach a machine learning model to read meters, it’s necessary to set up special example images where each and every object of interest has been painstakingly outlined. Every single meter, display, serial number and individual digit needs to be marked to teach the model to recognize it. That’s all assuming that you’ve already compiled the hundreds of thousands of images of meters to use for this purpose.

The catch here is that a model may already appear to work after training on a much smaller set of examples. You’ve now got a proof of concept that recognizes perfectly lit and framed images, but this is where the 80-20 rule, or Pareto Principle, comes into play. Customers won’t be satisfied when it fails to recognize badly lit or angled meters, and training the model sufficiently to achieve that level of accuracy is where most of the development time is spent.
Blicker has been trained on a large variety of different meters from utility companies across the globe to ensure that it can handle all kinds of scenarios.

The work is never done

Another challenge with machine learning is that it’s still a rapidly developing field. The performance of the model that you’re currently using may be eclipsed by a new type of model that’s published in a paper from one day to another. It’s important to stay on top of those developments and continue optimizing the models and algorithms you’re using, because your competitors will. To stay aware of this kind of progress in the machine learning community and to incorporate these improvements into your own product, requires you to staff employees who’re dedicated to this kind of work.

Additionally, the input for the model will also change through time. You may need to recognize new types of meters or deal with new kinds of recognition impediments like dirt on displays that are placed outside, so you’ll need some kind of retraining process in place.

A service like Blicker already has this kind of knowledge in house and uses it to continuously improve the product. The models are retrained using hundreds of thousands of images from customers all over the world to handle a wide variety of new scenarios. Customers benefit from this by simply experiencing improved meter readings after every update without any implementation effort from their side. When you are developing this yourself, you need to make sure that you’re committed to the ongoing development of the service.

Services have dependencies

Now, let’s assume that you’ve developed a model with adequate recognition performance. The next challenge is to turn this model into a product that is ready to serve to customers. 

You may already have infrastructure in place to deploy regular software, and machine learning software can work that way, but you may find that performance isn’t good enough. In a use case like Blicker, where customers need to know if their photo is readable immediately, you don’t want your recognition to take longer than a second. Delivering this kind of real time performance often requires specialized hardware like a GPU (Graphics Processing Unit) or TPU (Tensor Processing Unit). Having this kind of hardware around is significantly more expensive than normal servers, not to mention the fact that it may go unused for prolonged amounts of time if your customers are only uploading photos during the day. Of course cloud technology makes it possible to scale this kind of hardware dynamically, but you’ll need more specialized staff to set all of that up.

Depending on the type of photos you’ll be processing, they may also contain a lot of sensitive customer information. You need to make sure that you’ve got the right data handling policies in place and that your platform processes the data securely, even when it’s being used for training new versions of your model.

Decision time

Developing a service like Blicker yourself is a lot of fun and we’re proud of what we’ve accomplished, but the other side of the coin is that a project never really works like you want it on the first attempt. It took a lot of time to build a high quality training dataset and to design the algorithms that take care of the many edge cases we’ve encountered in the wild. A lot of that hardship goes hidden behind the mature and established product that Blicker is today, which is why we’ve aimed to uncover some of that work in this article.

During the development of Blicker itself we also often face the trade- off of solving a certain challenge ourselves, or by using off the shelf solutions. When developing solutions yourself, you have to consider the longer time to market, high upfront costs and the available skills within your company. We make these kinds of decisions by evaluating what - if anything - we stand to gain from solving it ourselves and it’s essential to have this in mind before diving into a project with so many unknowns.

Blicker itself is ready to be used by utility companies today, which allows them to focus on their core competencies like end user experience, by spending time on the development of their website and app. We’d be happy to help you, too, make the right decision by giving you a free demo of our solution.


Other news

Getting ready for Enlit 2022!

Read moreRead more

How to Reduce Non-Technical Losses in Utilities (Case Study)

Read moreRead more

How to Empower the Utility Workforce (Proven Examples)

Read moreRead more