Discovery Phase for Business Idea Validation
At first, the Client received a business analyst from our side.
The business analyst systemized and organized their idea, as well as identified the specifics of a future product’s users, their expectations, and needs to dispel doubts and prove the client’s assumptions about the product.
All the results in detail were systemized in a Vision and Scope document. Highlighting some moments in it, the Client received:
1. The suggestion to start with a Minimum Viable Product (MVP) as a way to launch the product fast, spend less money, and test their idea with real users before adding more functionality.
So the V&S described which functionality an MVP should get, and what can be postponed and included in the full-scale software development.
2. A complete analysis of the target audience, demonstrating how each user will benefit from it and what problems or incommodities it will resolve.
For example, the pain of managers at trucking companies is to deliver physical fuel cards to drivers who can be at any point in Europe, so the process could take 2 weeks. The pain of drivers is to find ways to fuel up a truck having no actual fuel card, which may imply 2 weeks of downtime. The pain of carriers is a high risk of fraud, loss, or accidental damage to a physical card.
Support of various roles and their functions within the app
3. Mockups (interface prototypes) to visualize how the software may look like. The mockups are created to bring life to an idea or wireframe and allow a designer to test how various visual elements work together.
Mockups for the mobile version of the future app
4. Outlining functionality of the app, for example,
- Integration of the app with logistics companies to get info on geo-location and current fuel level of a truck;
- Integration of the app with multiple Fuel Card Providers to remotely order new virtual cards, check virtual card status and get card details in response, get/postcard limits parameters (sync), get transactions (invoices), and more.
- Developing a rule-based Decision engine on the backend that decides whether to activate a card based on rules validation, which is essential for secure fueling. There should also be a Decision Engine Log (database table) which could be used for debugging, so that it could be easily checked why the Decision Engine made this or that decision.
- Defining a suitable Virtual Fuel Card technology. Fuel cards can be simple magnetic cards or also credit/debit chip cards (EMV cards). As the startup can work only with cards that allow contactless payment, for MVP we decided to use simple magnetic cards. Cards have limits set per day/week/month and their balances are the sum of transaction (invoices) amounts per day/week/month.
A rule-based Decision engine for secure fueling
Proof of Concept for Testing Technical Realization
After the Client received a detailed Business Analysis with technical details, they realized that cloning virtual cards might be problematic. This is why the business founders decided to make a Proof of Concept.
At this stage, we involved a software developer to test the problematic part. The developer created a piece of code for a virtual card, cloned a fuel card, and tested the outcomes.
Considering that in the result we always received errors, we saw that the European fuel stations didn’t accept any cloned cards, because fuel cards use a microchip format/technology that differs from the standard one used in payment cards (Visa and Mastercard). It allows only reading any card using NFC but doesn’t allow cloning it.
Having received the proof, the Client eventually decided that the idea of this business was not viable because you can not clone fuel cards and create virtual ones.