Dozens Mobile-Only Bank: A DashDevs Case to Be Proud of

Have you ever thought about launching a successful digital product? Dreaming of a brilliant idea that would change the world, attract followers, and enhance global consciousness. We are constantly reading all those stories of success, newly established unicorns, and “from-zero-to-hero” cases. From the stories mentioned, the process of digital product creation seems to be quite easy for everyone. You just need to generate an idea, create the architecture of a future product, develop an application, release it, and support the app, enjoying its success. Such articles invoke yawning with boredom from those who have once created an application. During development, you face many situations and address many not-so-obvious challenges. For example, in a case, you produce a crypto-messenger or a digital financial institution with a banking account. Is it as simple as the idea=> development=> release=> success cycle? No, it is not. The development of fintech products is even more complicated but more involved. We learn it by doing, not reading, not from blogs, but from real life.

If you wonder how long it can take to create a digital financial institution for the western market, the answer is nine months. It is an exact timeframe from our real-life experience.

What has made it possible? It is all about the decisions we have made and the responsibility we have taken. Before going deep into the development process, let us give credit to the team.

Team

In total, the team of 80 experts has been working to deliver a digital financial institution in 9 months. The bunch of people involved comprises the Project Imagine team of a business owner (a company that creates solutions to reimagine people’s relationships with money) and a Dashdevs sci-tech crew (a software development company that builds digital business products).

Product vision

Everything started with just an idea. Sounds quite trivial, right? Though there is one significant difference. The idea is not a sudden strike of mere inspiration. It comes from profound industry knowledge, experience, involvement, and engagement.

The core visioner of the Dozens fin-tech app is Aritra Chakravarty. After 15 years of experience in wealth management and fintech, he came up with an understanding that something is wrong with the current state of retail banking. A vision of a non-traditional financial institution crystallized.

An insight is that a financial institution must earn only if the client of the financial institution earns and grows their savings account.

The idea is simple and clear. Every vision requires a thorough check if it is valuable for real users. Not just friends and family, because relatives and cronies are emotionally motivated and always loyal to us. For validation of a business idea, ask the opinion of independent groups of potential customers. With Dozens, we asked the community of potential users for real feedback. These people represent the target audience. The community participated in focus groups to test the product at different stages of its development.

The other side is a team. When we established the vision, we needed to hire people who would be able to create a product like this. To achieve the results, we needed a team of professionals from different spheres, including traditional banks, too.

At every product development stage, there are a number of tasks to complete. Some of them are basic and influence the overall product progress. For building the product vision, a business owner should make some crucial decisions and answer the core questions.

Core questions to define a product vision

• What makes a product different? — Every key worker needs to know the vision and unique product value, so define them and write all those straight on the walls, and every key worker ought to know it. Such posters are decorating the office of Dozens.
• Is a product valuable for the users? — You may get a lot of information from marketing research. For example, you may find out that people do not know that they need your product. There is no pain your product could solve for them. However, you may discover the real pains while improving your vision.
• Who are the competitors? What are their key values? — Learn the market, know the incumbents and key players, and what atm fees and other terms they have. Find substitute products similar to your idea. Offering a contrasting vision, you should know what the usual one is.
• What do people think about competitors? What are their weak and strong points? — Knowing public opinion can help you to understand what people expect from a product, and what may attract them. To determine if there is a user’s need that is not satisfied yet, for instance, interest rates. Moreover, from feedback, you will know which solutions people like and which do not.

Facts on Dozens

Timeline: 2 weeks to clarify a product vision + 15 years of previous experience. The update period is every three months.

Capacity: 2 business analysts + the product owner

Results: Reports (on the market, competitors, customers, similar products, et cetera.)

Responsible person: The product owner.

Product mission

You have read thousands of times that a product with a mission can change the world for the better. As well as all that “make the difference” motto. Anyway, it is always hard to plan practical steps to complete a mission. Our advice is to learn the environment as thoroughly and deeply as you can, and you will find the gap between expectations and reality. The next step is to define what actions will change the status quo.

The mission of Dozens is to be a financial app that earns when its clients earn. It sounds revolutionary and a bit idealistic. How can a financial institution help the user to earn? Mission accomplishment starts with an understanding of the financial behavior of human beings. There are two main types of people according to their attitude to money: spenders and savers. We have decided that Dozens as the financial application must be useful for both types and help to earn either spenders or savers.

An app for spenders may help them to control their financial behavior and even change it to a healthier type. So that with the help of an app, spenders could monitor and analyze what kind of expenses should be cut. Understanding their budget, expenses, monthly fees, and their limits may also help spenders to avoid unnecessary money losses. The app may help them in the improvement of their financial behavior.

Savers know how to manage current expenses. They want to make their money work for them. Savers expect a financial app to offer them money-saving and money-increasing functionality.

Back to the mission, to make a financial institution earn when its clients earn, and clients may earn only if they learn how to manage their finances. Spenders who use tracking features of the app may advance to savers and benefit further with the help of options for increasing their money. That is why personal improvement and financial education become a part of a mission, not just free checking and savings.

If a business owner finds answers to the following questions, it will be much easier to determine a product mission

.Core decisions to set a mission

• Who is your target audience? — Try to research and define who your people are, what attracts them, how they make decisions, what they may expect from a digital product, etc. To make a long story short, know as much as you can about the people you are going to share your ideas with.
• What are the pains of the target audience? — Understanding the target audience of the digital only banking product, focusing on what experience makes them unhappy, frustrated, or seems to be painful for them. If a product is capable of changing such an experience to a positive one, it turns into a painkiller.
• Which products are we going to offer? — Your target audience has needs. Knowing them, a business owner may offer products to match those needs. It is a product owner’s decision to choose which customer expectations to satisfy and how.
• The research will reveal the situation on the market. What is the sequence of products (MVP, MSP, etc.) for release? — Some of the online banking products that a business owner provides for clients are of basic functionality, at least one has to be the killing and/or selling feature. Is there a need to release a minimum viable product as fast as possible, or do you have time to develop a fully-functional product?
• What are the additional features/products that banks offer that can be useful for the user? — In addition to the core functionality, a digital product may provide some extra value. For a financial institution, such values may include self-invested personal pensions, real-estate purchases, international payments, etc.
• What are the core numbers to determine that a product is successful? — There should be some indexes to evaluate the result. Otherwise, it won’t be measured, and it couldn’t be estimated. A team should know which factors and numbers define the success of the digital product, what vital limits are, and how to monitor them. For example, these measurements may be statistics on registered users, analytics on product usage, checking and savings accounts stat, etc.

Facts on Dozens

Timeline: 2 weeks of brainstorming and research.

Capacity: The whole product team.

Results: The 3-year plan.

Responsible person: The product owner.

Product design

As we have clearly understood our product vision and mission, our next step was creating designs for mobile applications. The design is something that users quickly fall in love with. We are not talking just about the user-friendliness of the app. An attractive app is more pleasant to use. As you may know, colors affect our decisions significantly. Colors can stimulate our choice or, conversely, suppress it. Working on the color scheme of an application, prepare several appropriate variants of all products, including a debit card. You may need alternatives when testing an app design with a focus group. Moreover, there may be some options for your marketing and promotional activities.

The logic of Dozens is straightforward and reflects the needs of the main types of users. Spenders actively use Spend and Track sections to analyze all expenses and learn how to manage the money. Meanwhile, savers need to have more options to save (Grow and Invest sections).

When we started with the design, we wanted to create a recognizable app style so that a user enjoys checking accounts. The design process started with wireframes which we showed to the community of target group representatives. We asked them for feedback about wireframes. After improving wireframes to fit user expectations, we proceed with a design style.

During the whole product design stage, we collaborated with the users’ community and developers. The focus group opinion is essential at every stage of the design process to check if our app matches our users’ needs. Consulting developers on the design stage is undoubtedly a crucial necessity. Backend developers have requirements, and mobile developers have possibilities. What is the use of the cool design if it is comprehensive or cannot be implemented? Creating the design, a banking service owner needs to remember that it should be applicable and usable, not only engaging.

Core questions to create a design

• Do people appreciate the idea? — Gathering feedback from the target audience is an extremely important part of the designing process. A business owner’s approval is not enough for the app design. If a product targets the real market, it should attract real users and motivate them to perform specific actions.
• What are the goals for the first year? — At the design stage, you should also remember that your products and services will develop, change, and grow. So we had to define objectives and set priorities, as well as select solutions to achieve our plans.
• Should it be the same design for both platforms? — Sometimes habits or behavior of users of various mobile platforms also are different. For Dozens, we use the same design for both platforms to ensure clients receive the same services.

Facts on Dozens

Timeline: 6 weeks for the core design and up to now for additional features and improvements.

Capacity: 4 designers + the product owner.

Results: Wireframes for the entire app. Developed design of three sections for the financial app.

Responsible person: The product owner for the product vision, and the lead designer for design solutions.

Architecture design

After completing the previous stages, the scope of the application functionality becomes clear. It is time to combine all the structural elements into a system. It is time to think about the approach to design the architecture and make the list of service suppliers required for the application. For a digital financial institution, we were choosing a KYC services vendor, card processor, payment processor, investment platform, and some other vendors that only banks need. A server side must coordinate all these partners.

We started with the search for a ready-made, customizable solution that could fit our requirements. Firstly, we had a proposal from one of the partner companies. They could have provided a white-labeled horizontal solution. The business owner’s team was excited about the possibility of using this solution, though the tech crew did not share their inspiration. After the proper technical assessment, and many internal discussions, we decided that the risks of the further unsolvable technical debts were higher than the advantage of the fast release. We rejected the quick-to-launch mobile only solution, and proceeded with designing the complicated architecture for our financial product with the help of other services and platforms.

The vital advice we can give to a company that decided to create a product with several integrations:

Ask a vendor to provide you with the codebase or the list of APIs with detailed documentation. The next step is an attempt to build your product with the chosen solution or check the API calls.

A chief technology officer plays a primary role in the process of designing the architecture. He makes the decisions at this stage and takes responsibility for further improvements. He is in the middle between technology and business. It is essential for CTO not only to be an advocate of the vision and mission but also to know long-term strategic goals. Igor Tomych, CEO of Dashdevs, plays the role of CTO for Dozens. He was a decision-maker, bearing responsibility in the real time, and having deep insight and intimate knowledge of the fintech field.

Providing financial services means ensuring robust performance and organizing a dependable support system. A digital financial institution is more than just a mobile application and a server-side.

The tech approach is a path to a branchless financial institution.

To go through the architecture design stage flawlessly, the next answers will guide you through this road.

Core questions to create an app architecture

• What are the compliance requirements? — The operation of financial institutions is strictly regulated to protect economies and financial institution clients from possible frauds, for instance. When building a digital product, a business owner should know the requirements, first of all. Second, checking that the technical solution complies with the regulative requirements is crucial.
• What are the critical security requirements? — Requirements for the safety of your solution should be determined, coherent, and specific. For example, in the documents for one service that we needed to integrate with, there was the requirement, “Your server must have a high level of security.” What exactly does it mean? Determine your standards and document them.
• Check whether you have the full list of APIs and full documentation for it? — We’ve changed a few partners because of the issues with the API. They failed to provide it.
• How much do integrations cost? — In this step, you need to calculate the cost of the service usage and analyze its quality. Be ready to change the sub-contractor if it does not fit your requirements, does not offer competitive pricing, or is unreliable.
• Is there a list of duplicating integrated services if the selected integrations stop working? — Building a product tries to predict the effects of negative scenarios. Always have a list of vendors that could substitute the picked ones. Working on Dozens, we switched to other service providers when integration failed to comply with our technical requirements. In particular, we refused to use two integration partners at the architecture design stage.

Facts on Dozens

Timeline: 3 weeks.

Capacity: CTO + the solution architect, 2 senior backend developers.

Results: An extendable and scalable architecture combining 20+ 3rd party providers.

Responsible person: CTO.

Execution

Having the approved architecture of the future digital product, it is time to plan the sequence of features for releases. Mobile application developers, backend devs, and supporting the platform DevOps had collaborated closely to reach the goals within the minimum possible period.

Development for Dozens was of extreme intensity itself. The application integrates with 20+ different services. These partner services are the real challenges because the application’s success depends on how reliable integrated services are. Below is the list of questions we faced and had to overcome implementing integrations.

• The outdated API documentation (deprecated methods, non-relevant responses, restrictions that were not documented or mentioned earlier).
• Environments that have a different configuration. For example, our platform was working on stage, but the same code is not working on the production. We started to investigate the issue to fix our solution. Unless we found out that the configuration of the environment is just different and the documentation about these differences in configuration simply did not exist. From one side, it was a relief to discover that the reason is not bugs in our solution. On the other hand, we should set our solution to work within the necessary requirements.
• Sub-partner dependencies. The production environment of Partner One will be available only if Partner Two provides the production environment. Partner Two doesn’t provide us with the prod environment until they perform their testing of our development environment. It had been a vicious circle. The timeline for the test was four weeks.
• No meaningful support or a contact person who can solve the problems. There is always a support manager who doesn’t understand the tech and cannot provide any practical help.
• Updates of APIs or environments without any notification. Just imagine the situation. You have been developing, and at the moment, your application has stopped working. You are spending hours trying to figure out where the bug is in your code, but the code is right. After all, the reason turns out to be the update of the partner’s API.

That is why we paid so much attention to the APIs, documentation, and the choice of partners in the previous step. You must do penetration testing for services you are going to integrate with before starting development.

Core questions to a product development

• Are we on track with the progress? — Define the approach to your product progress monitoring. Determine the intervals for reviews, how to manage a project, what time and bug tracking tools to use, and what are the critical KPIs. Keep tracking the progress. It is vital that the whole product team knows and understands essential milestones and indexes to evaluate your product progress.
• Will you have a backup if a partner service stops functioning? — Designing your solution architecture, you should have a chance to restore the full scale if there is an outage or interruption in the use of integrations. Design the backup logic and build the restoring algorithm.
• Do you fulfill DevOps’ and support needs? — These experts also have their requirements and demands to ensure clients’ engagement. For example, they need an API, platforms, and a tool for communication and tracking.

Facts on Dozens

Timeline: 6 months.

Capacity: CTO, the backend solution architect, the mobile solution architect, 16 backend developers, 6 DevOps for infrastructure, 25 mobile devs, 12 QA engineers, 4 automation QA engineers, 4 designers.

Results: The first public release of MVP (for teams and families).

Responsible person: CTO.

Maintenance & Support (After the first release)

The MVP was great. But the application didn’t have a complete set of features. The development continued. During that time, we started receiving feedback from our clients. There was a special dev squad that made hotfixes.

As you may remember, in the first stage of development, we planned the sequence of features to release. But after the release, the priority has changed due to the user’s feedback and business reasons. So there were no calm hours for our development team, as you can imagine.

Core questions of the post-release phase

• What is the priority of features for updates? — Based on the market research and users’ feedback, you will have the list of functionality to implement for the next version. Create a plan for the development of new functionality and prioritize new features and their implementation sequence.
• Which users’ comments are worth updating? — After testing your products on real users, you will get feedback that you need to process. We gathered all the comments. Then we evaluated them by comparing them to the product vision and mission. For those reviews which we determined to match the established goals, we set the priority and planned further updates and improvements.
• How to evaluate the performance of third-party services? — If a service integrated into a product is often out of work, it is time to refuse it and switch to the other. There should be no excuses except for reliable and stable performance. A product owner ensures the product operation for its users and builds trust. Especially, when it comes to a digital financial institution, every outage makes users worry about their money.

Facts on Dozens

Timeline: 5 weeks till the first internal release, 12 weeks till the first release for beta testers, friends & family, and 7 more weeks for the full public release, present time — maintenance & support.

Capacity (peak values): 7 backend devs, 12 mobile developers, 2 solution architects, 7 QA engineers, the product owner, the business analyst, the designer, DevOps, marketers, and customer supporters.

Results: The application was released to stores.

Responsible person: The product owner, the solution architects.

Conclusions

Currently, available technologies make creating products from scratch as easy as ever before. 9 months from an idea to a release is evident proof in this case. The reason why we have managed to achieve the result within such a term are:

• a skilled and motivated team,
• defined and polished product creation processes, and
• a fusion of two worlds — fin and tech.

Every expert in our team is responsible for a specific part of the application. “Being responsible” is not just a label or a line in the CV. The responsible person knows everything about the specified feature, and understands the tech basics of the functionality. The main measurement of responsibility is the result. The real measurable result in the real highly-performing application.

We are sure that you can even decrease the 9-month timeline of development. If you arrange production the following way:

• execution over perfection;
• results over emotions;
• failures in the early stages of architecture. :)

Within those 9 months with Dozens, we, in DashDevs, have been producing 30+ projects on different stages of development simultaneously. We have not stopped at this point. Our clients operate in various domains and require business software solutions for different fields and industries. Dozens, a digital financial institution, stands out of the bunch. It is a product that has challenged our team and brought our expertise to the next level. Consciousness and responsibility is our most valuable contribution to the development of the technical solution and integrity.

FAQ

What is the difference between Neo Bank and challenger bank?

The main difference between a neobank and a challenger bank is that the first doesn’t have a physical presence, while the latter does. A physical presence (or multiple locations) certainly has its advantages, but it also brings with it a host of new costs and complications.

Is Dozens a bank?

Dozens is a financial institution. It is a licensed e-money institution (FRN 900894) and an investment business with the Financial Conduct Authority (FCA) (FRN 814281). With their e-money license, they can provide debit cards and checking accounts.

What is Project Imagine?

The Dozens financial wellness and investment app and the Pi1 modular bank-in-a-box platform are two examples of how Project Imagine is revolutionizing the financial services industry. Pi1 is a complete digital banking platform hosted in the cloud. Dozens (a business and consumer product with nearly 50,000 users) and Pi1 are both products of this firm (a B2B financial services product).