This is a series of three posts that explain the story behind iomando from different perspectives: design, business and technology. These have always been my main areas of concern as a co-founder and product owner of the company, so I thought it might be a good idea to write them down and recap some of the work we’ve done the last years.
I’ve already written extensively about iomando: product announcements, company vision, business strategy, design decisions, fundraising, you name it… But these series are not intended to cover each step we’ve made along the way. Instead, they aim to structure some of the most relevant content and then briefly elaborate on the key ideas behind each domain. Think of it as the indispensable summary you should read if you really want to understand the company.
This last piece will describe the underlying technology that enabled the product. We'll revisit all the product announcements since the beginning and we'll get deeper insight about the new features each one brought to the market.
Although the main purpose of the article is to get a sense of the technology we've developed and its role in the overall company strategy, I've tried to avoid technical terms as much as I could. So expect a readable document without going much deep into the technical stuff.
Introducing iomando version 1 - Insights into the announcement of the iomando version 1.
Our Bet for GSM - Why we chose cellular technology to build our main module.
Introducing iomando version 1.1 - Insights into the announcement of the iomando version 1.1.
Introducing iomando version 2 - Insights into the announcement of the iomando version 2.
Hardware update version 2 - Insights into the hardware side of the iomando version 2.
Push - Further explanation of the push feature introduced in iomando version 2.
Door Status - Some called it version 2.1, but this is all about the Door Status feature.
Plastic for Bits - The underlying principle that enables every single feature iomando has.
API iomando - Introducing the license program that will allow third parties to integrate or build upon our access technology.
Introducing iomando website - Insights into the announcement of the iomando website.
Introducing iomando version 3 - Insights into the announcement of the iomando version 3.
In order to unveil the roots of our technology we have to go back to 2011, when the closing gap between the physical and digital experiences piqued my curiosity.
I was working on a side project that consisted of a tiny electronic board - an Arduino Uno - featuring a Wi-Fi module and a relay that could be triggered via TCP/IP. With this device, a local wireless network and a PC you could control and program anything from your house: the alarm, the garage door, the irrigation system… It was some kind of rudimentary home automation system, but it was pretty amazing at the time.
The next iterations of this hack brought cellular connectivity to the device, which meant that the Wi-Fi network was no longer required, and also a mobile friendly web-app, which meant that we could move from PC to a mobile device. Fast forward four years, one can safely say that, although we’ve shipped a ton of stuff, the core architecture of our technology remains the same:
- Mobile app: this is what our users download in order to access.
- Server side: controls the permissions and updates all the data in real time.
- The electronic device: this is the piece of hardware we install next to the access in order to control it.
Early 2012, after a little detour, we build upon our original technology and shipped iomando version 1. With iomando version 1 we aimed to do just one thing, but do it right. Despite there were some scattered initiatives at the time, we were the first of our kind to ship in Spain. Because of that, we got a lot of positive feedback and a warm reception from the media and the early adopters.
But looking back, it’s curious how the product even got off the ground, because it lacked some features that today we think of them as indispensable. Let’s see from a spec point of view what things might surprise us if we released them today:
- It could only handle one access per space.
- Users had to login w/ username and password.
- The management tool, despite it was accessible from mobile, was a web based iframe, that only allowed to add and remove users.
- Believe it or not, It was available for BlackBerry, too.
- The gap between pushing the button and the door actually opening was huuuge.
Despite all of this the delta improvement with keys and remotes was enough to convince a lot of people to switch from incumbent products. The smartphone adoption was not ubiquitous as is today, so it still wasn't a good fit for everybody. But the lower price, the increase in security and the connivence of having all your accesses in one place was enough to validate the idea and keep going forward.
As time went by, some competitors started to show up, but curiously, few of them betted on the same core technology, and on top of that, we were the only ones relying on cellular data to fuel our operations.
I’ve written extensively about the topic because I find fascinating the constraints that the underlying technology places on business models, but here’s a quick list of why we went with cellular:
- Compatibility: not all of our customers had NFC enabled phones nor had Bluetooth activated all the time. On the other hand, cellular was ready on every device.
- Installation: we were not only rooting for a great experience for the user, we also wanted installers to feel comfortable with the product. Cellular technology made it easier to install and also worked out of the box without relying on third party connections, like a Wi-Fi network.
- Pairing: this one turned out to be an even better decision over time, but back then, we just wanted to control the experience end-to-end and that meant "magically" handling the pairing server side.
- Security: we didn’t want local communications between our hardware and the phone, so all the traffic was routed through our servers.
There are much more reasons for that, I encourage you to read the full article, but to sum it up I’d say that cellular seemed like a good idea because it was rooted in the nature of every smartphone. Sending and receiving packages over TCP/IP is the thing they do best, so we let them do that.
Soon after the introduction of iomando version 1, we released our major update so far, the iomando version 1.1. With this update we brought a lot of "under the hood” improvements that, although were not pixel visible, they enhanced the experience in many ways.
- It reduced the amount of time it takes to open the door up to 80%.
- Introduced a real time communications channel to inform the user of the state of an open request at any given moment.
- Set up a VPN for our devices in order to increase the security of the data transmission.
- Brought a mobile native experience for the management tool and the ability to further customize the time frame of the permissions.
In April 2013, after so much feedback from our customers and all the lessons learned along the way, we brought to the market the second version of iomando. iomando version 2 was not a redesign (we say 2.0 like we mean it), instead we rebuild our product from the ground up, a clean slate that helped us design for the new reality without compromises.
From a design standpoint, the update came just in time for the, yet to be announced, iOS 7 and the flatter trend that followed. Version 2 also stood out because of its beautiful colors and a personality that made its design truly unique. Above that, version 2 also brought with it:
- Login without password: to reduce the friction during the log in process we developed a whole new way to smoothly register and log in to the service via SMS.
- Multi-door: each Space could now access up to four doors from the same screen.
- Geolocation: we leveraged the geolocation capabilities of the smartphones to enhance the management experience and create rules based on the distance of the person from the access point.
- Management console: added the possibility to refine the management settings to a point where you could also set days, time-frames and periods of times when the users would be allowed.
- [Beta] we released a web based management tool.
Over time we’ve learned that in order to really push the boundaries of what is possible in access technology, updating (only) the software is usually not enough. Because of that we also updated our hardware device and added a new hardware model to our product line.
- Two relay board: each board got the ability to control up to 2 doors.
- GPS module: this module updated the position of the device in real time, so when an administrator set a security geo-fence the distance would be automatically calculated.
- Radio module : this was our new addition to the product line. The radio enabled module (codenamed ARCD) was able to locally connect to a parent board (the cellular one, AICD). This way in Spaces where there were a lot of accesses having just one cellular connection deployed would be enough. It supposed huge savings because the ARCD was way cheaper to produce, because it didn't sport a cellular module, which was by far the most expensive component of the BOM.
Push and Door Status
The following months after we released iomando version 2, we made a couple of significant updates to the product. The first one was the introduction of a push channel so that all the changes in the server side were pushed immediately to the devices, in real time. For example, changes in the permissions, new additions of users... instantly showed up in the app. Moreover this technology would the foundation of some upcoming features, like notifications in version 3.
The first of these upcoming features was Door Status, a new technology that would allow every administrator to know at any given moment, in real time, if the door is opened or closed. The cool thing about Door Status was that we silently equipped the new hardware we rolled out several months before with all the necessary stuff to start working out of the box. So the moment we completed the roll out, the feature was already available to all of our customers.
We've said that many times, but our vision goes beyond opening doors with the smartphone. We profoundly believe that technology will redefine what it is possible with access control. This is why at the end of April 2014 we took the boldest and most ambitious step since our foundation.
We introduced the iomando API, a new license program that would allow third parties to integrate or build upon our access technology. For the dev team that meant the biggest collective effort we've ever done. Building an API from the ground up was huge in a way none of us could have ever imagined. But it was also one of the most rewarding experiences we've lived together as a company.
But if we wanted to grow at a much larger scale, we were going to need a ton of help. So we might need to join forces with partners that really had the power to push forward in a meaningful way.
Therefore instead of competing with everybody and make a painful battle out of every little sale, we thought it was a smarter decision to join efforts and build an environment where all parties could benefit from.
Remember the Beta version of our management tool we silently introduced along with the version 2? So here's what it has become: iomando Dashboard, a better management experience aimed to access and mobility managers. The new tool brought all the features from its mobile sibling, but it also gained a lot of capabilities, leveraging the additional screen real state gained because of the transition from mobile to web.
iomando version 3 was not just an update to our existing vertically integrated product, it was much more than that. With the iomando version 3 we profoundly rethought every detail and every step of the access experience.
The mobile app was the remaining piece due to update after our new brand redesign, so with the introduction of iomando version 3 the transition to our new design was also complete for all the product lines.
iomando version 3 was built with the same tools and rules we provide to third parties through the iomando API program. By doing this we wanted to lead by example and push the limits of what was possible with our technology, inspiring businesses and developers along the way.
The biggest novelty of the iomando version 3 mobile app was the the break up of the management features from the app itself. This was possible because the recently announced iomando Dashboard unbundled the management capabilities from the app.
This separation allowed us to design the app around the assumption that it was only intended to access. This kind of focus freed us from the constraints that all the management blocks presented and, thus, we could rebuild the experience from the ground up and further enhance the access capabilities.
To recap some of the new features that iomando version 3 brought to our customers, here's a quick list:
- Unified view for Spaces and accesses
- New algorithm to automatically sort Spaces and accesses that presented the most likely space you'd be opening at any given time.
- Slide to open: it avoided unintended taps, it displayed contextual information... huge win for the overall experience.
- Contextual information right into the access view showed the most relevant content to our users, just when they needed it.
- Access to Door Status right from the app.
- Push notifications that informed the user, in real time, about relevant changes regarding their accesses.
- TouchID as a less intrusive and more optimal way to secure the app.
All the features we listed above are not separate efforts that we've built because we thought they were cool. They had their own purpose, of course, but all of them, in one way or another, worked together towards the goal of making the experience of accessing faster, smoother and, above all, delightful.
In order to create a truly disruptive experience and leap forward existing competitors in the market it is necessary to make both hardware and software interplay in a meaningful way. The only way to do that is by controlling the solution end to end and also by having cross-functional teams that are able to create synergies among both worlds.
The new hardware also came with a whole range of great stuff:
- Up to 54% smaller than the previous one.
- New box that was more accessible and easy to install.
- New industry standard I/O ports that our installers were demanding.
- Improved internals (better processor, antennas and communication modules) which translated to better performance.
- Way more power efficient and consumed up to 40% less energy despite better performance.
- Sported the new iomando Connect.
Arguably, the most relevant feature is iomando Connect: it provided network connectivity to the places where iomando couldn't offer a great experience because it didn't have access to the internet.
Despite cellular connectivity presented lots of advantages, it had some weaknesses as well, like the dependency we had on network operators, but above all, the quality of the service in places with poor network coverage.
iomando Connect aimed to solve exactly that by creating a local Wi-Fi network that only iomando users would be able to use in order to enhance the access experience in areas with poor network coverage.
 Believe it or not, every time we opened a door with version 1.0 we sent an SMS to the door. Yes I know how you feel about that, I feel it, too. That was because our telco provider wasn't able to provide static addresses to the SIMs, so we couldn't rely on they changing at any given time. That's why we pointed to the only fixed parameter we had to open the door, and that was the SIM phone number. Despite being so (cost) ineffective, that gave us time to deploy the VPN with local IPs that we rolled out with version 1.1.
 iomando has two types of hardware, the first module - codenamed AICD - which features an internet connection and is able to talk directly to the servers, is the one we use when the installation has two access or less that are close one to another. The second module - codenamed ARCD - is a radio device that connects to AICD in places where there are more than two access within less than 2 km. We use ARCDs because they cost less - they don't have GSM module - and it's easier to manage all the doors fleet from just one internet connection.