The software for booking and internal administration is an elementary component of a sharing offer. However, it would be too simple if there were only one industry-standard solution for this. Instead, you are spoiled for choice: Do you want to develop your software independently or rely on an existing, standardized system? Compromises include outsourcing software development to an agency or a customizable package from a software vendor. Find out below what speaks for and against each of these options.
Why The Choice Of Software Is Crucial
Every shared mobility offering needs 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 an 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 indispensable.
Normally, this includes access for drivers, usually in the form of a mobile app, via which vehicles are booked and bookings and payment methods can be managed. Sharing providers, on the other hand, need a portal with which they can manage their fleet, set rates, manage users, view bookings, and perform 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 alongside the other components of 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. Thus it can quickly determine success or failure. There are also significant differences in cost 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 quickly and easily reversed. Take your time for this component of your offer and base your decision on sound arguments.
Important Decision Criteria For Software Selection
Although gut instinct is a good guide in many of life's issues, you should not base such a momentous decision as finding the right software system for your shared mobility project solely on it.
Instead, become aware of individual factors that contribute to and influence your decision:
Cost: Initial costs are incurred for setting up or developing the software, as well as ongoing costs for continuous maintenance and regular updates.
Time: The length of time it takes to develop or implement software affects how quickly your offering can go to market.
User-friendliness: In the best case, your software allows easy and intuitive operation both by the driver and by you as a provider.
Integrations: Which external services must be able to be integrated into your software solution?
Complexity: Do you need particular features or other specializations for the optimal realization of your sharing offer?
Stability and functionality: Your system must be stable and reliable at all times and be able to handle higher requests and events if necessary.
Security: Ensure the security of your and your users' personal data and protect your system from external threats.
Scalability: Do you want to start small and take off later, with additional vehicles or a larger user group? Then tailor your system for scalability right from the start.
Future orientation: The requirements of your customers change just as quickly as the current technology standards. Regular updates and continuous adaptations ensure that your software is always up-to-date.
The factors mentioned are of course weighted differently in each individual case and may vary from case to case. It is important that you know which of the factors are important to you and which may be less relevant.
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 scope of the available know-how - is completely customized to your needs and covers only the features and components that you really need. An in-house system is particularly useful if you need very specialized features for your offering that external software providers cannot offer, or at least will not be able to offer in the near future.
However, with the freedom and control gained also comes responsibility. Because all updates, tests, errors and faults must be carried out and resolved by your IT team. The personnel requirement is equivalent to up to 10 full-time positions for software development as well as 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 allow about a year for the initial development period, depending on the scope and complexity of the software solution. Once your offering goes live, however, your developers' work is not yet done. The shared mobility market and the needs of drivers are constantly changing, which will sooner or later lead to the need to adapt your software. There are also constant technical updates and security gaps that you have to take care of. For example, it is your responsibility to ensure that no user data can be stolen at any time and that your entire offering is DSGVO-compliant.
It can also be challenging if you want to integrate special locking systems, on-board units (OBUs) or other interfaces, or if you want to scale your mobility offering, i.e., expand it to include additional vehicle types or new user groups, for example. Your software should be built in such a way that you don't have to start from scratch again and again in such cases.
Knowledge for Take Away
This guide guides you step-by-step through the process of setting up your own shared mobility offer. Get an overview of what you'll need to consider and benefit from best-practice-tips and examples.
In general, independent software development carries a higher risk of the software being error-prone or even the entire development failing. The high development effort could also cause a change in your actual business purpose and make you gradually more of a technology business instead of a sharing business. However, it is also conceivable that this new or expanded business model will allow you to license and distribute your own platform solution in the future.
The shift in focus is also accompanied by the risk of a so-called "knowledge silo". This refers to a situation where knowledge is not shared sufficiently between different teams. It quickly arises when teams have different points of focus and do not share information among themselves. As a result, the efficiency of internal collaboration decreases, (process) costs increase and scalability is limited. Such a silo can also reside with just one person: Assuming your CTO leaves the company, you need to be able to ensure that a successor can easily take over this position and that valuable knowledge does not leave the company with one person.
Compromise 1: Commissioning an agency
A compromise solution could be not to develop the software in-house, but to commission a specialized agency. This agency may have more experience in software and app development and will also take into account your individual wishes and requirements. In the future, you also commission the agency for regular monitoring of functionality, updates and enhancements.
Development time will continue to be about a year, depending on when and with how many resources the agency can begin the job. The costs are also comparable. However, you do not need an internal team of developers, but outsource the manpower to the agency. When selecting them, you should make sure that they have knowledge and experience of the shared mobility industry, so that the entire development process is always geared to this.
Because unlike you, an agency's motivation is not primarily driven by your product, but by the prospect of developing an exciting and, at best, successful software solution. Whereas you as a provider always have the future development of the market and product in mind, an agency tends to work more with the current status quo and is only partly oriented towards foresighted development.
Also, be aware that most agencies will only provide you with the finished product without source code. If you terminate the contract with the agency in the future, you may have to buy the source code or start from scratch again.
Option 2: Use Of A Standard Software
Since a standard software solution is already established and in use by other providers, the often long research, development and testing phase is eliminated and you can bring your sharing offer onto the market much faster. Another advantage is that the experience of other providers, some of them transnational, has already been incorporated into the development and fine-tuning of the software. So you benefit from these right from day one and get the current status quo of the market.
Some of the included features may not seem necessary at the beginning, but might prove useful in the future and with the continuous development of your offer. 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. Accordingly, the costs for a standard software are significantly lower than for an independent development.
Most software providers offer different packages with varying scope. This way you can adjust performance and price to your needs. For example, you can start with one of the smaller packages and upgrade later if you need more features or the like. This also allows you to easily scale your offering and integrate a variety of other services such as locking systems, payment systems, analysis tools, etc.
Customer support is available to you 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 adaptations to changed market situations or circumstances (e.g. integration options for new vehicle types or new laws) without your intervention and, possibly, adds further functions without price adjustments.
You can therefore do without internal developers and instead concentrate completely on your sharing offer. One argument against a standard solution, however, is that you cannot individualize the platform to an unlimited extent and adapt it to your requirements. Also, a solution may not cover all your needs, so that you have to use additional services for analysis or operation management.
But: By using an already established platform, you are taking to heart the sharing philosophy that probably motivated you to run your shared mobility project yourself.
Compromise 2: Software package with possibility of customization
Standard solutions are not sufficient for all providers. This is especially the case if the offering is either very specialized or very extensive, for example with a large fleet or 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 flexible customizable packages. These include, for example, a White Label App that allows you to focus on your own brand, or a Customer Support Manager for personal support. In MOQO's Premium Plus package, you can request project-based feature development to further customize your offering.
Note
Customers with a smaller partner package at MOQO can suggest new features and other customizations without obligation via the Idea Board in the portal.
Such customizable software packages offer you significantly greater flexibility in terms of your offering, while you continue to benefit from the software manufacturer's specialized experience in shared mobility. Even though the costs are higher than for a simple standard solution, they are still significantly lower than those for in-house platform development.
Conclusion: There’s No Right Or Wrong
Ultimately, no one can make the decision between doing it yourself and outsourcing it. Basically, in cases where no specialized features are mandatory and needed quickly, standard software is the cheaper, faster and often more secure choice.
Nevertheless, none of the models listed above represents the ultimate and universally valid solution. Factors such as costs, benefits and the future perspective must always be included in the decision-making process and then weighed up for the individual case.
