Fintech Dev Definitive Guide.

Step 1: Figure out the problem that you want to solve

If you can identify a problem that affects a group of people, and work toward a product providing a solution, customer acquisition of your product becomes way easier and more natural, because you will not have to work hard to convince potential customers that they need your product. Of course, it is possible to envision your product as a bigger and better version of an existing product, but in that case, you need to have a strong marketing strategy to convince people to switch from the existing product to yours (benefits that might be obvious to you might not be so obvious to your potential customers).

Why is it important?

Identifying the problem that you want to solve for your customers will give you the necessary direction when designing your product. It will also make it easier to determine which features are critical, and which are less important so they can be omitted from the minimum viable product (MVP).

What happens if you fail to complete this step?

Products that start without a clear vision are often very difficult to work on, mainly because the feature list and priorities tend to change quite often - these products usually take a very long time to complete, bringing a lot of frustration to all parties involved.

Step 2: Choose the features for your product and assign them priorities

After identifying the problem, and getting the necessary direction, you should try to create a list of features that your product will provide to your customers. It is a good idea to give a priority to each of the features on this list. For this you should use at least two priorities (such as “must have” and “nice to have”), but if you can assign more than two priorities, that is even better because it would make creating a product release roadmap easier.

Why is it important?

Having a list of features is further refining the direction that is set in the previous step, and giving priorities to the features is a great help to your development team to determine which parts of the product should be built first, and which can be added later.

What happens if you fail to complete this step?

You can not really avoid having a list of product features defined, but if you don’t do it in advance, you are risking to increase development cost, because the team will have to discover features as the product is being built.

If features are not assigned priorities, then you risk getting into a situation where everything is of high priority, which in fact quickly turns into a “nothing is of high priority” mindset.

Step 3: Identify your target user group and their chosen device

During the problem identification, almost simultaneously you should be able to identify the prospective customers of your product. The more precisely you identify your target market, the better. After you identify the customers, the next step is to decide how they will interact with your solution. Keep in mind that your target customer group should determine the means of interaction. In today’s world the most obvious choices might be mobile, or web application, but other options are also available.

Why is it important?

Identifying the correct target user group allows you to build your product to use the most appropriate means of communication with your customers. If your customers mostly spend their time using mobile phones, then you can build your product as a mobile application, but if they can’t use mobile phones maybe your product should be IVR service or contact center service.

What happens if you fail to complete this step?

If you don’t know who your primary customers should be, you risk spending time and money building a system which will not be easily adopted by your customers.

While you are trying to keep that product running, somebody else might come with a product, offering the same service, but better suited to the target audience.

Step 4: Try to envision how your product will be used

Although (most likely) you are not a professional designer, you should still try to create some sketch of your product at least on a piece of paper. You should especially try to visualise user interaction with your product, what steps the user would have to go through in order to complete specific actions.

Why is it important?

The more you have to show to the others about your product, the easier and faster the communication will be (which will save both time and money during development).

What happens if you fail to complete this step?

Although this step is not really business critical, the worst that can happen is you spend more time designing your product (we are talking about extra weeks at most, provided that you are able to make up your mind about design alternatives that the development team will offer to you).

Step 5: Be aware of regulatory requirements in the territories you want to start your business

For most territories, corresponding central banks have prescribed requirements for financial service providers, and although they might be somewhat different in different territories. However, main themes are pretty much identical:

• Protect the customers' funds
• Protect the customers' personal data

Customers' funds are usually protected by keeping them in the separate bank account (you should not mix customer funds with your company’s funds or with your revenue). Process of dealing with money separation is called “Treasury Management” and it is arguably the most important thing to consider when starting a fintech company.

The most important thing when creating treasury management processes is to make them robust, and to immediately plan for error detection and recovery (no matter how bullet-proof you think your processes are, errors will happen and it is better to have error detection and recovery procedures in place from the very beginning).

When it comes to protecting the customer’s personal data, many countries have different regulations. Most fall into these categories:

• Customers' personal data should not leave the country
• Non-authorized personnel should not be able to see customers’ personal data
• After customer closes their account, data allowing customer identification should not be kept (it should be deleted, or somehow obfuscated)

A customer’s personal data can be protected by combining data tokenization, a robust privilege system in your back-office and encryption.

Why is it important?

Quite often fulfilling regulatory requirements is linked with timelines given to you by external authorities (for example, maybe it is the central bank’s procedure to review each application for 4 months before giving approval). Being aware of these timelines will help you better plan your development time and scheduling of resources. A technical reason to investigate in advance, is to be able to immediately design the system to use tokenization and/or encryption of data as appropriate.

What happens if you fail to complete this step?

If this step is not taken, you will have to rebuild large portions of your product, you might incur added cost for over-resourcing. Your company would be liable for not following regulatory requirements.

Step 6: Identify service providers necessary to your operations

Try to identify service providers you need to use in order to provide the best possible experience for your customers. Here you should group service providers in two groups: must have and nice to have. Gather as much information as possible about each service provider you want to work with (both on specific company and on service provider type).

Some service providers might have specific requirements in order to engage with you (for example some BIN sponsors might want you to deposit funds before they start doing business with you, or some payment processors might require you to be PCI DSS compliant before allowing you to use certain services).

One thing to be very careful about, is to collect other people’s experiences with providers you are considering working with (especially be careful to consider experiences relevant to you - for example, a particular KYC provider can have a really good reputation and good reviews in Europe, but its coverage of African countries can be very poor, and needless to say, they would be a suboptimal choice if you are planning to start your business in Africa).

Another issue to be careful about is that according to their sales and marketing teams all service providers are reliable all the time, but quite often the reality is quite different - make sure that the contract you are signing allows you to break out of it quickly if it turns out that their service is not as good as advertised. In addition, be ready to spend some money in advance to validate their services, before definitely deciding to use them in the final product.

Why is it important?

In any product development, integration with external service providers always takes a significant amount of work. It is very important for system designers and architects to be aware of all details about the systems they need to integrate with, in order to properly plan project scope, budget and timelines.

What happens if you fail to complete this step?

Failure to complete this step will almost always have severe consequences to project completion - project will have to be redesigned to deal with forgotten external service provider, or, and this is much more common situation, large portions of the system will have to be recreated in order to switch from service provider A to service provider B (in case former’s services turn out to be suboptimal).

Step 7: Decide if you want to build your product from scratch or use out-of-the-box solution

In general there are two basic routes to get to your product (with many intermediate steps between these two extremes):

• Build your own solution from scratch
• Use or customize somebody else’s out-of-the-box solution

Both approaches have pros and cons, the most obvious pro for building your own solution is the ability to evolve your own product in any direction you want. On the other hand, starting with a ready solution might significantly shorten your time to market.

When it comes to downsides, building your system from scratch usually requires more time and money than purchasing a ready solution. On the other hand pre-packaged solutions may not be 100% suitable for your specific problem. After initial time saving for MVP phase, ongoing added cost to customize it, might overtake the cost of building your own solution from scratch.

We here at Codenizer, have managed to get good results with a combined approach. For example, we have smaller independent components, such as Connect library, or generic wallet, that we can tailor to individual needs, without really having to write everything from scratch. We build all customer’s business logic from the ground up.

One common pitfall that many startups fall into, is trying to immediately build a solution that they will use through the entire life of their business. In our experience, it is much better to start with more modest requirements, especially when it comes to scalability and performance, and to start working on the next version of the system once your product gains some traction and starts generating revenue.

Why is it important?

Depending on which of two paths you choose, your spend will be much different and resourcing needs will also differ. For that reason, as soon as you decide your approach, the sooner you will be able to predict with confidence the product costs, and timelines.

What happens if you fail to complete this step?

This is the step you can not really skip on your way to the product, but the more you postpone it, the longer it will take you to efficiently plan your timelines and costs.

Putting it all in writing

If you are able to answer most of the questions above, the logical next step would be to put as many details as possible in writing. Describing your product in writing will help your team build the product in the exact way you envisioned it.

The document describing all aspects of your product (those listed above and more) is called Software Requirements Specification (SRS) and is arguably one of the most important and most valuable assets to create. This document contains much more information than what we mentioned above, but this is still a good start. The more you invest in the SRS leads to savings in development. A detailed SRS will shape the features backlog, and it will allow the development team to come with an optimal plan to create the working version of your product in the shortest possible time.

Why is it important?

Having as much information as possible in writing will reduce the time your team will need to extract your ideas from you. Also, quite often people tend to think things through better when they are writing them down, compared to talking about something.

What happens if you fail to complete this step?

Even if you haven’t created a document containing answers to all the questions mentioned above (but you have thought about them), requirements specialists within the team will be able to gather the necessary information from you. They may require additional time from you in order to achieve this.