Rapid tech due diligence: How Catalyst Fund assesses a startup’s tech

Co-authored by: Matt Grasser and Malika Anand
July 22, 2020 - 8 mins read

Alongside product-market fit and adequate control of data, underlying tech quality is a key determinant of whether a startup will be able to scale and hit growth targets. Although the tech that powers fintech startups is critical to their success, tech due diligence tends to form only a minor part of overall due diligence. These proceedings often focus on growth metrics and financial models, both because investors have expertise in these areas, and also because they are more easily evaluated using standardized formats and metrics. Tech due diligence, in contrast, falls outside the wheelhouse of most investors and moreover, moves too fast for standardized assessments. 

Given these tendencies, Catalyst Fund’s Lead Technologist Matt Grasser and Head of Growth Aaron Fu led a discussion with 30+ leading impact investors on how Catalyst Fund evaluates startups joining our portfolio on four aspects of tech quality: robustness, inclusivity, agility, and team skill. 

This tech due diligence generally needs to be fast and simple so we use a few quick questions to rapidly assess the quality and scalability of the tech stack, and how well the team is thinking about tech development. Focusing tech due diligence on the four elements of robustness, inclusivity, agility, and team skill using proxy measures and heuristics gives us a fairly complete picture of whether the tech has been well-built, or if the startup needs additional support in this area. 



The first task of tech due diligence is to understand if the product has been built on a high-quality foundation that can serve as a basis for scale, data-driven decision making, or more advanced tech (our AI Readiness Toolkit also helps assessment for the last). This is important to assess because the quality of the backend infrastructure and code can determine the reliability of the product (i.e., by reducing downtime), and the startups’ own ability to manage the product. 

It is not feasible for the Catalyst Fund team or for investors to read endless lines of code or to unpack the architecture step by step. Instead, we probe the quality of the architecture by understanding how the startup has solved three tasks: 

  1. software & storage
  2. data organization & control
  3. data analysis. 

We are not evaluating the quality of these solutions; our goal is to understand the care, expertise and efficiency reflected by the team’s decisions.

One of the first things we ask is whether the team is writing its own code. In general, we are looking for startups to write the code in-house for elements that are core to its value proposition, but to use off-the-shelf tools for auxiliary operational issues like landing sites and tools for marketing. We want to see that the startup is striking a good balance between owning and writing the code. Either extreme – writing fresh code for everything or outsourcing everything – is a cause for worry. We also ask to see a database schema as well as documentation on data input and storage mechanisms. Again, we are not evaluating the documentation content, but rather observing the ease and speed at which it is produced, and how tidy it is at first glance.   


When Catalyst Fund first got to know Nigerian startup Cowrywise at the end of 2019, the team did not (yet) have a fancy set of dashboards or interactive data displays. Data was plentiful, but it was difficult to read and reference at a glance. However, when we asked for a data schema, the CEO produced a clean, easily legible, carefully updated map of how data was collected, stored, and piped. Immediately, we knew that not only was management on top of the tech, but that it was developed according to best practice. They only needed the extra instrumentation and simple data analytics to reinforce their systems and oversight. We helped Cowrywise set up some well-designed dashboards to stay on top of their key metrics (e.g., AUM tiering, retention) and within a few short months, Cowrywise was equipped with data-driven superpowers.  



The second area of tech due diligence that we consider is the extent to which it has been designed to be inclusive, with sensitivity to the particular needs and constraints of underserved users who may have older/less functional devices, intermittent connectivity, lower literacy, and other barriers. Technologists don’t always realize that remote, low-income people who are interfacing with the product’s frontend have pretty specific device and connectivity limitations, so it takes special attention to ensure solutions are inclusive. 

While the clearest indication of inclusivity would be to go into the field and observe users interacting with app, such up-close study is not feasible for during due diligence. Instead, the team uses information that is more readily available to look for evidence of the startup’s underlying sensitivity to the needs of underserved people. 

To understand the inclusivity of a product, the Catalyst Fund team evaluates the product’s: 

  1. specifications & requirements
  2. user experience

A quick review of the product’s requirements can indicate whether it is accessible to poor, remote, excluded people. For example, when apps are heavier (greater than a few MB) or don’t have offline capabilities, this can indicate that they would be challenging for people to download and access. With regard to user experience, the team takes a look at the amount of text in the app, the level of the vocabulary used, and the use of graphics to support comprehension. We often “mystery shop” an app to see how fast it downloads and whether customer support is responsive. Our Design for Trust toolkit provides a number of cases and tools to this end.    


One of the startups in our latest cohort, KarmaLife, features an app with simple, clear visuals, and very limited text. The text included uses simple words, rather than full sentences, and is always accompanied by a graphical element to aid in interpretation. The app also nudges and guides users using visual cues, for example, with red symbols for pending action items or highlighting parts of the screen that the user should press to complete eKYC. KarmaLife is also intentional about celebrating wins and progress to encourage users. For example, when users successfully join the platform, have completed their KYC requirements, or have made a successful payment or money transfer, they receive a visual celebration on the app. The app is also small to download, and was designed to be used on a mobile device. In this case, Karmalife’s users have smartphones by the nature of their work, so the team need not worry about feature phones or USSD interfaces.


A third area that Matt and the Catalyst Fund team consider for tech due diligence is the agility of the team. Tech agility is critical to knowing how well a startup will respond to a change in policy from a government ministry, or to a third-party payment provider suddenly exiting the market. Tech teams and architectures that can more rapidly adjust have an edge over the competition that is critical to startup success.

Again, it is not feasible to assess the code or to judge agility based on past history. Instead, the team probes how the startup currently makes improvements — either planned or in an ad-hoc fashion — which can indicate whether the tech is set up to enable and facilitate these iterative processes or if it will be an obstacle.

The team considers two areas of agility: 

  1. how improvements are managed and planned
  2. what tools the team uses to deploy improvements 

These two areas can give us a clear sense of how well a startup can adjust to changes in the environment and implement improvements towards product-market fit. We ask to see a tech roadmap to see whether the team has sprints planned in an orderly fashion or if there is a disorganized backlog of rollouts. We also ask how deployments are made; whether the team depends on manual, ad hoc, overnight merges or if they have continuous deployment abilities.  


When we started working with Destacame in 2016, their tech priorities, agility with roadmap, and customer centricity were immediately notable. This agility allowed them to quickly evolve from an alternative scoring platform into an entire financial management platform that includes a full range of products, from alternative credit scores to past-due debt repayment discounts, graduation loans, credit cards, and financial health advice to help customers properly manage their financial lives at every stage of the journey. Today, Destacame works with over 35 financial institutions across Mexico and Chile, serving nearly 3 million customers and attracting 120K new customers every month.

Sebastián Ugarte and Jorge Camus, cofounders of

Sebastián Ugarte and Jorge Camus, cofounders of Destacame


Team skill

Investors are accustomed to reviewing the team’s CVs, but tech and engineering skills can sometimes be hard to assess, especially among self-taught technologists who can be extremely skilled. Beyond the CVs of a startup’s engineering team, we have found it useful to look at the team structure, and processes within which the engineers operate to see if they are set up to really enable the engineers to deliver their best.   

To this end, Catalyst Fund considers both: 

  1. the structure of roles & responsibilities
  2. evidence of technical skills

For the first, we want to see well-organized roles and responsibilities that are distributed among the team. When too much is centered on the founder, it is a sign that the tech may be fragmented. For example, a startup from Catalyst Fund’s previous cohort, Kwara, has a clear, strong team with clearly defined roles and responsibilities. The team is led by a capable CEO who trusts her team, thereby ensuring that jobs are executed by those who have the relevant expertise. In general, great tech teams have clearly defined roles: Engineering Lead, back-end, front-end, QA, devops, product owner. 

To find evidence of technical skills, we pay less attention to the CVs, and instead look at the tools and analytics the team uses. If the engineers depend on spreadsheets, we know skills are an area of concern, whereas if we hear about tools and standards like RESTfulness, Swagger, object-orientation, CRUD operations, OAuth2, or JSON web tokens, or otherwise reference the particular backend stack and/or Android libraries they’re using, we have more confidence in the team’s skills. 


In the case of Kwara, there are seven core members on the tech team: two back-end specialists based out of Nairobi, two front-end specialists based out of Berlin, two engineers dedicated to customer success, and a scrum master. The team also calls on two part-time engineers to work on dedicated, defined projects as needed, allowing Kwara to scale specific time-bound projects while keeping the core team lean. Kwara has built a public RESTful API api.kwara.com so that their customers (Savings and Credit Cooperatives) can check credit bureau information or connect their existing channels. They use https://www.graphiti.dev to connect their front-end and back-end, and use https://clubhouse.io as their scrum board with sprints every two weeks, and almost daily releases to production.

They also use: Intercom for messaging with users, Convert Flow for newsletter sign-up, SendGrid for email dispatcher, Twilio for SMS, Ruby scripts for data transformation, Google Analytics and Hotjar to understand how users interact with their product, Rollbar for error tracking, AppSignal server logs tracking, and Hubspot for sales and marketing communications. While more tools is not always better, this particular list of tools tells us that the Kwara team is making smart use of high-quality available tools and dedicating their engineering firepower where it matters – towards solving the particular problems of their customers and developing valuable intellectual property. 

In all, this four-part tech evaluation gives a pretty clear sense of the quality of the systems and the skill of the team. During our discussion, we heard about many additional ways that investors are tackling this problem intelligently and efficiently. We look forward to sharing some of these lessons later this year.  


These ideas were explored as part of the first of three webinars in a due diligence series that Catalyst Fund is facilitating for our Circle of Investors. The first focused on tech due diligence, and the second, hosted by Nigerian investor Microtraction, will cover lean due diligence. The third, on remote due diligence, will be hosted by Partech, a European investor, later this year. Our goal is to share Catalyst Fund’s ideas and approaches in conducting due diligence on early stage ventures in emerging markets, and to collect thoughts and contributions from leading investors with the intention of creating a shared guide that reflects the best our sector has to offer in conducting due diligence.

Related Publications
Leave a Reply