Back to blog

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

Dozens: from an Idea to the Digital Financial Institution in 9 Months

17 min read

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 mentioned stories, the process of digital product creation seems to be quite easy for everyone. You need just 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 the development, you face many situations and address a lot of not-so-obvious challenges. For example, in a case, you produce a crypto-messenger or a digital financial institution. Is it as simple, as the idea=> development=> release=> success cycle? No, it is not. The development of fintech products is even more complicated however more involving. We learn it by doing, not reading, not from blogs, but from real life.

If you wonder how long can it take to create a digital financial institution for the western market, the answer is 9 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.


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 relationship with money) and a Dashdevs sci-tech crew (a software development company that builds digital business products).

Product vision

Everything has started with just an idea. Sounds quite trivial, right? Though there is one significant difference. The idea is not sudden struck 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 in retail banking. A vision of a non-traditional financial institution crystalized.

An insight is that a financial institution must earn only if the clients of the financial institution earn.

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 the 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.

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. 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, what may attract them. To determine if there is a users’ need that is not satisfied yet. Moreover, from feedback, you will know which solutions people like and which do not.

Facts on Dozens

Timeline: 2 weeks for clarification of a product vision + 15 years of previous experience. The update period is every 3 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 behaviour 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 and savers.

An app for spenders may help them to control their financial behaviour 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, and their limits may also help spenders to avoid unnecessary money losses. The app may help them in the improvement of their financial behaviour.

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 becomes a part of a mission.

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 a target audience, focus on what experience makes them unhappy, frustrated, or seems to be painful for them. If a product is capable of changing such experience to the positive one, it turns to a pain-killer.
  • Which products are we going to offer? — Your target audience has needs. Except for knowing them, a business owner may offer the products to match those needs. It is a product owner’s decision, to choose which customer expectations to satisfy and how.
  • What is the sequence of products (MVP, MSP, etc.) for release? — Some of the products that a business owner provide for clients are of basic functionality, at least one has to be the killing and/or selling feature. The research will reveal the situation on the market. Is there a need to release a minimum viable product as fast as possible, or you have time for the development of the fully-functional product.
  • What are the additional features/products 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 be the list of self-invested personal pensions, real-estate purchases, international payments, and so on.
  • 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, 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, colours affect our decisions significantly. Colours can stimulate our choice, or conversely, suppress it. Working on the colour scheme of an application, prepare several appropriate variants. 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 style of the app. 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 the way they 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 need. 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 business 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 product 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 behaviour 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, 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, etc. 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-labelled 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 solution, and proceed with designing of the complicated architecture for our financial product with the help of other services and platforms.

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

Ask a vendor for providing 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 needs 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, 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 not 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, it is crucial to check that the technical solution complies with the regulative requirements.
  • 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 does it exactly 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 not reliable.
  • Is there a list of duplicating integrated services, if the selected integrations stop working? — Building a product try 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.


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 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, we should set our solution to work within the necessary requirement.
  • 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 4 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 stops working. You are spending hours to figure out where is the bug in your code, but the code is right. After all, the reason turns 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, 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 would be an outage or interruption in the use of integrations. Design the backup logic and build the restoring algorithm.
  • Do you fulfil 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 team 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 been 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 as matching 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 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 uses 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, customer supporters.

Results: The application was released to stores.

Responsible person: The product owner, the solution architects.


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 the 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, 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-months timeline of development. If you arrange production the following way:

  • execution over perfection;
  • results over emotions;
  • failures on early stages over architecturing. :)

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, outstands 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.

Share article

Table of contents