Building a beacon platform the Lean way

Aug 20, 2015

For the past eight months, the Mubaloo Innovation Lab team has been busy building the MiBeacons platform, designed to deliver businesses, looking to deploy beacons for commercial purposes, with a reliable, easy to use and intelligent system.

The platform allows an end user to manage beacons, content, notifications and analytics passed to a mobile app via an SDK. This enables developers and companies to dynamically update content and campaigns as they please, similar to how a CMS such as WordPress works. This means the code doesn’t have to be updated frequently and non-technical staff are able to add content and control campaigns.

This blog talks about the evolution of the platform and the processes involved.

In late 2013, when everyone was getting excited about beacons, we started exploring the possibilities of the technology and what it would mean for the enterprise. To create an app that surfaced different content when you entered a beacon region, we had to hardcode content and associate it with a particular beacon.

If we then wanted to show different content using the same beacon, we had to go back and change the code, or include endless ‘if’ statements to cover the various scenarios. As you can imagine, as this scales, the resource commitment rapidly scales with it.

To tackle this problem we created a locally hosted ‘platform’ with the MiBeacons demo app, that would enable us to assign content on the fly and add/delete beacons. The APIs talked to the app via a SDK which worked well for demo purposes and meant that non-developers could configure the app.

At this time, we were continually having conversations with companies wanting to deploy beacons, yet didn’t necessarily want to create a completely custom deployment. Instead, companies wanted to be able to use a platform that would enable them to deploy beacons and easily manage them.

Despite a number of platforms being available for beacons, we kept on hearing that many companies who had conducted trials found platforms to be too limited or unreliable for deployments. With all that we had learnt about beacons and the conversations that we were increasingly having, we started to feel that we could apply our knowledge to create something companies were calling out for. It became clear that there was a huge gap in the market for a platform that worked in a way that would provide the best end user experience and provide companies with valuable analytics that enable them to improve operations.

Here at the Innovation Lab, time allowed us to monitor what was taking place in the market to identify where the gaps were and what different types of deployments require.

From our experience with our own beacons demo app and other deployments, we were able to do pre-learning about what does and doesn’t work when trying to deliver the optimal user experience. Whilst many companies have viewed beacon engagement as a form of push notifications, we quickly came to realise that push is the wrong technology to use.

We quickly developed a Minimum Viable Product (MVP) which allowed developers and brands to add content, notifications, beacons and view analytics relating to the number of unique users interacting with the beacons.

From our initial demonstrations to clients, we heard that it seemed much better than what was available elsewhere, but that there were other features that companies felt would help them further. This allowed us to pivot and move forward with the confidence that we were developing a product that would have a place in the market, as opposed to building a platform that may or may not have a business case.

Taking an agile approach to development has enabled us to map features out and understand their importance in terms of value and complexity. For anything that we have deemed to be more important, we’ve been able to quickly build in features, instead of trying to create a platform that had everything we may have originally thought was valuable.

Starting with a minimal viable product helps to ensure that the foundations of the platform are solid, as opposed to trying to create a platform that was ready to go. By adding features in an agile manner, based on the value that they will provide, we have been able to ensure the platform is both scalable and robust.

As an example of this, we now know that it’s incredibly valuable for clients to set notification triggers in the platform and also have a tie in with CRM systems. A typical use case here would be a discounts app that is running a lunchtime offer between 11am-2pm for 2 weeks.

When the user enters a beacon region, before sending them a local notification, it’s possible to check against a client’s CRM system to provide intelligent context, making a decision to send an offer based on a user’s preferences. This means that notifications and content received are likely to be more relevant to the user, as opposed to simply spamming them with unwanted messaging.

Use cases such as the one above emerged through clients testing the MVP and pointing out the limitations of the current version. This allowed us to then intelligently respond and develop features that we know will provide value to our clients and be used in real world scenarios.

By spending the time to observe the market and educate companies about the value of beacons, we believe that we have been able to better understand what companies and ultimately end users will find most valuable. By integrating into existing apps, we believe that the platform will help to enable a wider cross-section of companies to find value in beacon deployments.

If you’re interested in talking to us about our beacons platform get in touch:

Back to all articles