From Native Token to Enterprise SaaS towards a Decentralized Platform for the Internet of Mobility
In 2017, Josep Sanjuas and I formed a team to explore how we might leverage blockchain technologies to to decentralize mobility. We initially started with a focus on finding a way for taxi cooperatives to collaborate and compete on a global scale with the likes of Uber, before settling on an even more ambitious goal: enable the creation of a decentralized Internet of Mobility which would allow any vehicle, public, private or shared, to be discoverable, routed, booked and paid for by any user of any app connected to the IoM protocol. Josep and I were quickly joined by our third founder, Victor Lopez and we thought we were off to the races.
We intended to create a native token, with a range of token economics principals including, but not limited to staking. We spent months planning for an eventual Initial Coin Offering (ICO), constructing product and business white papers, building a Telegram community, etc.
We commenced raising pre-ICO investment from pioneers in the blockchain space. For example our first investor was BlockAsset, which is a baby fund of Fenbushi, one of the first and largest blockchain VCs out of Asia (one of their early founders included Vitalik Buterin). Later, Centrality, one of the great success stories of the ICO boom, who has successfully weathered the storm and built a formidable team led by Aaron McDonald and begun to execute its Dapp ecosystem built on Substrate/Parity.
Then of course the burst of the ICO bubble forced many promising blockchain startups, Iomob included, to pivot their funding and revenue models. Besides the decline of the ICO market, the writing was on the wall that our initial vision for a fully decentralized blockchain-based protocol for the Internet of Mobility was too ambitious for the current mobility market. Just one example was the staking model we had designed which would require any mobility service provider who wanted to connect to the protocol to stake in the Iomob native token. In retrospect it is obvious that many players would be opposed to this including public transit authorities and massive private operators who are hard enough to convince to participate in aggregation models when they embrace the walled garden model, without adding an additional barrier to adoption of a staking requirement.
In our case, we made the determination our best path for survival and eventual success was to shift from funding the development of the open Internet of Mobility protocol described in our white papers via a token sale, towards a much more “traditional” enterprise SaaS company, funded through venture capitalists and strategic investors in the mobility space.
This meant thinking through which parts of the stack need to be built to serve an enterprise client, and to what extent blockchain was needed in this new role. We realized, for example, that no matter how strong we made the protocol, enterprise customers would be unlikely to see the value without us building the front-end user experience that would enable seamless user access to public and private mobility services. So we set about to build a team capable of continuing to lead the development of the protocol and APIs as well as a UX, UI and front end software engineers to build a world class white label mobile application.
And, after a few years of building, we are excited to have come out of the storm with a functioning back end which integrates APIs of a range of public transit, rail, micromobility, carsharing, bikesharing, scooter sharing and other mobility services, while containing our own intermodal/multimodal routing algorithms and yes, a pretty impressive white label application that allows users to 1) discover services around them, 2) receive combined mobility routing options to go from A to B, 3) book and onboard services, and 4) pay for those services seamlessly inside the app. As an enterprise software company, we do not have our own end users, but instead license the white label solution to major transport related customers including airlines, rail and bus operators, transit authorities and automobile clubs.
The question many whom have known us for years and our vision for a decentralized Internet of Mobility (IoM) ask us is:
How can you still claim to be committed to decentralization when you are focused on selling an enterprise license to a proprietary stack?
The answer is that Iomob has embraced the ethos of decentralization from the beginning and has established a four phase plan to achieve our original vision, with or without a native token.
Phase 1: Enterprise Mobility as a Service Platform
As can be viewed in our roadmap, Iomob is acting on our strategy and vision to support a decentralized Internet of Mobility. Phase 1 is the development and launching of our enterprise solution for major transport operators. In November of 2019 we launched our first trials of the full stack with Renfe, the Spanish rail operator. The solution has gotten early rave reviews from our client and from users who were used to an inferior users who for the first time can solve their entire door to door journey between and within cities (in the trial this is Barcelona and Madrid).
Along the journey we began to embrace human centered design principals and even paid for a design thinking consultancy, Six Fingers, to lead user research to improve the front-end. Phase 1 has been essential for us to build and learn and iterate and build more. We continue to refine the algorithms required to support true intermodal journey planning across and within cities, and of course learn the nuances of APIs that support deep integration of so many diverse mobility services including real-time vehicle mapping, unlocking vehicles (e.g. scooters), ticketing and payment services.
Phase 2: Open APIs
In order for the ultimate vision to come to fruition “any vehicle, public, private or shared, to be discoverable, routed, booked and paid for by any user of any app connected to the IoM protocol” we must support open APIs whereby any owner of any vehicle(s) can connect those vehicles to the IoM protocol without Iomob’s involvement. One of the most powerful aspects of decentralization is that it fights the tendencies of Web 2.0 to create walled gardens and monopolies who can dictate the terms for small players to participate in marketplaces. At Iomob we believe the mobility marketplace must support a truly open network effect so that a startup can compete equally with a unicorn to provide services to a user based on the user’s needs in that moment.
For example, what if a startup has decided to launch a pilot project to foster sharing of micro urban EVs, such as the Renault Twizy. But the startup, called Save our Planet (SoP), has limited resources and only 10 vehicles to put out on the streets in a controlled area. They have an investor prepared to further finance the project if they can prove there is demand for the service. Should SoP have to build their own shared mobility app and engage in marketing the app to potential users for a controlled pilot in a few neighbourhoods? It doesn’t make much sense. Why not allow them to plug those 10 vehicles into the IoM protocol and not even build or launch their own app?
As we are already in Phase 1 of our deployment, any user of an Iomob app can book and pay for SoP vehicles whether the user is local or a foreigner just visiting. So a user may have never heard of SoP and would not have the SoP app but SoP would have a chance to demonstrate user interest in their vehicles without the considerable expense and time of building their own app and marketing to local users which makese little sense for a constrained pilot. Of course in the future we believe even owners of their own private vehicle, whether it is a car, scooter or bike, will also be able to dynamically connect that vehicle, perhaps with smart contracts governing the terms of sharing authorized by the vehicle’s owner. Phase 2 will commence in the first quarter of 2020.
Phase 3: Creating a Global Mobility Standard
All of us in the Web 3.0 world are very aware of the importance of building community. The community must support an open protocol and collaborate to improve it over time. In our first iteration of Iomob, regarding the launch of a native token, we initiated the community building very early. With our pivot to an enterprise model we shifted the focus of community building away from the token sale and towards the marketplace. Specifically for Iomob to succeed, we need to embrace and engage key actors in the mobility ecosystem. In phase one and two that is about getting public and private mobility service providers (MSPs) to connect to Iomob so their vehicles can be discovered by Iomob’s white label apps such as the one we built for Renfe. And of course we also need to engage with public transit agencies as well as target enterprise clients.
In Phase 2, which we have already started preparing for, we also need to begin to work with other actors who share our interest in the need for open APIs of private MSPs across the modes of mobility services (taxis and ridehailing, micromobility-bikes, scooters, etc, carsharing, carpooling, bikesharing, parking, EV charging networks and more). During Phase 3, our aim is to collaborate with a range of current and future networks, NGOs, governments, consultancies, other mobility ecosystem actors, in an attempt to grow the commitment to a shared Internet of Mobility (IoM) protocol and APIs. Obviously, if IoM is to become a global layer of the internet that supports an interoperable decentralized mobility ecosystem, Iomob will depend on shared alignment with many key players and the community as a whole. We have begun this process as part of our Phase 2 Open API initiative and have been pleasantly surprised by the interest we are receiving, so we are optimistic about the future of our community building.
Phase 4: Decentralizing the Stack
Phases 1 through 3 set the stage for the ultimate objective we set out to achieve in 2017. We aim to decentralize key elements of the protocol and the stack to willingly give up control for the benefit of the growth of the ecosystem. While we have been inspired by the open source software movement, we have to admit we are not entirely altruistic with our decentralization goals. We believe that the capital UX of mobility is broken. We believe that every mobility operator trying to build walled gardens and proprietary closed app ecosystems is doomed to fail. Uber of course is the biggest current mobility player in the global market (outside of say Google whose maps are used by billions), and their business model has not proven to be sustainable. Sure they are worth more than $50 billion (USD), but they are also losing billions every quarter. Meanwhile 2019 witnessed dozens of mobility startups either fail outright or be swallowed up in M&A activity.
At Iomob we believe the future of mobility must be decentralized. That no one platform owns the market. Mobility is just too expensive to own especially on a global basis. Yet users desperately want one app that will travel with them wherever they go without having to discover and onboard new apps. This is exactly what IoM will achieve especially after we complete Phase 4 of our decentralization journey. In this phase, any app (not just those built by Iomob) connected to the IoM protocol will enable its users to travel the world and access any vehicle, public, private or shared in intermodal journeys. We like to refer to this as “global mobility roaming”.
Decentralization will not just happen at the app or the API layer, but also the hub layer. Referring to our Product Components diagram above, the hub for Iomob houses the integrations of MSPs and knows the real time location of all of the vehicles connected to it so when a user of an app connected to the IoM protocol wants to go from A to B, the hub, and its intermodal algorithms, generate the routing options which are delivered to the app layer. When we get to Phase 4 of our decentralization plan, other actors will be able to connect hubs to the IoM, further reducing the ecosystem’s dependence on Iomob. We anticipate a hub registry which may be governed by the community through a token curated registry.
In conversations with major public and private MSPs, this future state of Iomob has proven to be very compelling to them as it alleviates their concerns that Iomob could just create another type of monopoly control over the ecosystem and impose extractive commissions for exposing their services to the apps and users around the globe.
Iomob has developed a desired end state after completion of Phase 4 which contains four elements: 1) Open APIs, 2) Open Hub Protocol, 3) Open Source Reference of the App and 4) Open Source City Control Panel. In a future post I will dive into our plans for each of these components.
If this post intrigued you and wish to learn more about our journey and our plans, please check this link in early February (2020) to a video I made for the FinNexus Insights event. And if you would like to collaborate with Iomob you can reach us at: contact@iomob.net
About us:
Iomob, which stands for the Internet of Mobility, headquartered in Barcelona, Spain, has built a white label Mobility as a Service solution which combines proprietary algorithms enabling multimodal combinations of public and private services and an application that allows end users to discover mobility services, receive multimodal combinations for their journeys, book and pay for a range of mobility services. Iomob has won numerous open innovation challenges from organizations like Ford Motors, Renfe and Sweden’s Sustainable Mobility Challenge. Iomob has also participated in prestigious startup accelerators such as Techstars and Wayra and in 2019 has won the Best Mobility Startup of 2019 at the South Summit, The Public Choice Award from ERTICO in 2019, Top Mobility Startup in the Federation of International Automobiles (FiA) Startup Challenge and selected Top 100 Smart Cities Partners by Newsweek.
Learn more about Iomob by connecting with us:
