Why the question of the software is crucial
Every shared mobility offer requires a system through which vehicles can be booked and managed. If only a single vehicle with a limited user group is to be managed, a simple calendar or Excel list may be sufficient. However, as soon as more vehicles or users are involved and it is a professional sharing offer, a suitable software solution is essential.
Normally, this includes access for drivers, usually in the form of a mobile app, through which vehicles can be booked and bookings and payment methods can be managed. Sharing providers, on the other hand, need a portal with which they can, among other things, manage their fleet, set tariffs, manage users, view bookings and carry out billing.
Quite a few providers initially underestimate the effort involved in commissioning and maintaining a system over the long term. After all, this represents an additional challenge in addition to the other building blocks of the set-up and operations.
Due to the many tasks and functions of a software system, it influences both the efficiency of internal handling and user satisfaction and can quickly make the difference between success and failure. There are also significant differences in terms of costs and time to launch, depending on whether you develop the software yourself or outsource it.
It is therefore also important to emphasize that the decision in favor of a particular software solution cannot always be reversed quickly and easily. Take your time for this part of your offer and base your decision on well-founded arguments.
Option 1: Self-made Software
Self-developed software promises full control over the system – but requires an internal development team with qualified software and app developers.
This can then develop a shared mobility platform that – within the framework of the existing know-how – is individually adapted to your needs and only covers the features and components that are really required. Having your own system makes sense above all if you need very specialized features for your offer that external software providers cannot offer, or at least not in the near future.
However, with the freedom and control gained comes responsibility. Because all updates, tests, errors and malfunctions must be carried out and solved by your IT team. The personnel requirement corresponds to up to 10 full-time positions for software development and product management. The associated personnel costs represent a large part of your development costs, in addition to the costs for servers, licenses, material costs, etc.
You should plan about a year for the initial development period, depending on the scope and complexity of the software solution. As soon as your offer can go live, the work of your developers is not done yet. Because the shared mobility market and the needs of drivers are constantly changing, which sooner or later leads to necessary adjustments to your software. Likewise, there are ongoing technical updates and security gaps that you need to take care of. For example, it is your responsibility to ensure that user data cannot be stolen at any time and that your entire offer is GDPR-compliant.
Sometimes it also becomes challenging if you want to integrate special locking systems, on-board units (OBUs) or other interfaces or scale your mobility offer, i.e. want to expand it to other vehicle types or new user groups. Your software should be built in such a way that you don’t have to start all over again in such cases.
In general, independent software development involves a higher risk that the software will be error-prone or that the entire development will fail. The high development effort could also cause a change in your actual business purpose and gradually make you more of a technology operation instead of a sharing business. However, it is also conceivable that this new or expanded business model will allow you to license and sell your own platform solution in the future.
With the shift in focus comes the risk of a so-called “knowledge silo”. This describes a situation in which knowledge is not sufficiently shared between different teams. It quickly arises when teams have different focus points and don’t share information among themselves. As a result, the efficiency of internal collaboration decreases, (process) costs increase and scalability is restricted. Such a silo can also only lie with one person: Assuming your CTO leaves the company, you must be able to ensure that a successor: can take over this position without any problems and that valuable knowledge does not leave the company with one person.
Compromise 1: Hire an agency
A compromise solution could be not to develop the software in-house, but to commission it from a specialized agency. They may have more experience in software and app development and also take into account your individual wishes and requirements. In the future, you will also commission the agency to regularly monitor the functionality, for updates and extensions.
The development time will remain around one year, depending on when and with how many resources the agency can start the assignment. The costs are also comparable. However, you do not need an internal development team, but outsource the personnel expenses to the agency. When selecting these, you should make sure that you have knowledge and experience of the shared mobility industry so that the entire development is always based on this.
Because unlike you, the motivation of an agency is not primarily driven by your product, but by the prospect of developing an exciting and ideally successful software solution. While you as a provider always have an eye on the future development of the market and product, an agency tends to work with the current starting point and only orients itself to a limited extent on forward-looking development.
Also, be aware that most agencies will only provide you with the finished product with no source code. If you end the contract with the agency in the future, you may have to buy the source code or start again from scratch.
Option 2: Use of standard software
Since a standard software solution is already established and in use by other providers, the often long research, development and test phase is no longer necessary and you can bring your sharing offer to the market much faster. A further advantage is that the experience of other, sometimes transnational, providers has already flowed into the development and fine-tuning of the software. You benefit from them from day one and receive the current status quo of the market.
Some of the features included may not seem necessary at first, but may prove useful in the future as your offering evolves. In any case, you do not bear the development costs of the software alone, but these have been distributed among a large number of providers in the price calculation. The costs for standard software are accordingly significantly lower than for independent development.
Most software providers offer different packages with different scopes. This is how you adapt performance and price to your needs. For example, you can start with one of the smaller packages and upgrade later if you want more features or similar. require. This allows you to easily scale your offer and integrate a variety of other services such as locking systems, payment systems, analysis tools, etc.
Customer support is available for questions and problems, and the software service provider takes care of potential bugs, malfunctions and software updates centrally. A software manufacturer also usually implements adjustments to changed market situations or circumstances (e.g. the possibility of integrating new vehicle types or new laws) without your intervention and, if necessary, adds further functions without price adjustments.
So you can do without internal developers and instead concentrate entirely on your sharing offer. However, what speaks against a standard solution is that you cannot customize the platform indefinitely and adapt it to your needs. One solution may also not cover all wishes, so that you have to use additional services for analysis or operation management in parallel.
But: By using an already established platform, you take the sharing philosophy to heart, which probably motivated you to run your shared mobility project.
Compromise 2: Software package with customization options
Standard solutions are not sufficient for all providers. This is especially the case if the offer is either very specialized or very extensive, for example with a large fleet or a high number of users. Then sometimes the standardized features and platform components are not enough to meet the needs of the provider.
For these cases, most software providers offer flexibly adaptable packages. These include, for example, a white label app that you can use to put your own brand in the spotlight, or a customer support manager for personal support.