Plastic for Bits

A couple weeks ago I wrote about the two-layered business model iomando was simultaneously operating, and how this strategy was designed to make the most out of iomando’s uniqueness.

Rereading the thing I feel like I tried to get too many points across and bundle way more information than a single 1000-word post could handle.

Yet it uncovered something worth emphasizing.

It may not be a marketable feature, nor something our customers can explicitly articulate — I don’t think they are “buying us” because of this. But it is definitely the underlying driver that has enabled our product so far.

Our sales pitch has always been packed with words like security, cost-reduction, control, management, ease of use, even how cool it is. But you seldom hear the ultimate cause, the reason why all of this is even possible.

We are replacing plastic for bits.

That’s all there is, it is as simple as it sounds. Our entire business thrives under this premise. Everything else is just a consequence of this underlying principle. It may seem like such an obvious, subtle detail, but it makes all the difference.

While our competitors are manufacturing and distributing physical keys and remotes, we are just sending ones and zeros through the air.

Atoms cost money per additional unit of capacity, but bits do not.

When it comes to producing anything, there will always be some fixed costs. That is machinery to manufacture a physical good, or a bunch of software developers if your product is an app, whatever.

But when it comes to scale and replicate “the thing” over and over, the software shows its strengths. In our case, adding additional units of capacity to our service has virtually no cost. Each new permission equals an app download, it is not physical, thus it has no cost.

In stark contrast, each time an admin had to grant a physical key, a huge logistic chain had to be deployed in order to make that happen. This meant resources, complexity, friction, problems, and ultimately, money.

On the other hand, being able to replicate additional software keys at no marginal cost means we can deploy our service on a larger scale without skyrocketing operational costs. And this has huge implications because we can serve large organizations with thousands of users at a fraction of what they were used to pay.

The larger the opportunity, the bigger our customer’s savings.

Moving atoms around is expensive, but bits are not.

Being software-based, we are able to automatically deliver and set up all the customer’s permissions instantaneously at no cost. Imagine a spot with thousands of users — a public facility for instance. Now imagine what happens when its council has to grant keys or remotes to every user. It is madness.

The first problem, again, is cost. But even if you are past cost issues, an inevitably and arguably worse problem still awaits: distribution and management.

Deploying thousands of physical devices through a massive disorganized crowd requires a massive, coordinated effort. Pick up or deliver each key, track who has one, be aware that nobody makes a copy… the list goes on and on and it is a nightmare for the teams in charge of access management.

That’s because moving atoms around costs money and time. But software can be quietly delivered, in the background, instantaneously. iomando is able to handle massive deliveries at no cost at all. Yet again, more savings and fewer problems.

On top of that, if those weren’t enough reasons, software is malleable in a way hardware is not. Once it is delivered, it can be modified, updated, improved. Possibilities that their physical counterparts would never match. It is not a matter of business, it is a matter of physics. And I would never bet against physics.

Every single feature that our customers love is a — more or less direct —consequence of this: bits enable additional creation and delivery for free.

That’s what software does by definition, it enables and reaps the benefits of scale.

And this is how we are leveraging it to change the way access management systems work.