Preparing for Success: A Frontend Engineer's Guide to Tech Due Diligence

All right. Before we dive deep into the world of tech due diligence, let me share a bit about who I am and my experience in the realm of frontend engineering. And don't worry, I plan to keep things light. A nice change of pace from the more technical talks you might be used to during the React Day Berlin.

My name is Armin. Over the years, I have worked on various projects, using React extensively, and I have seen firsthand how the decisions we make as frontend engineers could shape the trajectory of a product, team, or even the entire company. So let's move to the larger picture here. What drives us at Tech Miners and how it lays the foundation for our today's talk. At Tech Miners, our role isn't just to evaluate, but to guide and uplift. Our unique approach to tech due diligence is data-driven, diving deep into processes, people, and technology. We have assisted countless businesses in preparing for significant milestones, from investment rounds to exits.

But all this talk about tech due diligence might have you wondering, what it is really? So let's demystify that. Our presentation today is structured into two primary segments. First, we will familiarize ourselves with the essentials of tech due diligence, what it is, and why it matters so much in our role, in our field role. Following that, we will dive deep into some practical insights on how we can effectively prepare ourselves for such a process. So by the end of our talk, I hope you will not only be understanding the tech due diligence better, but also you already have some ideas on how to improve your work, whether it could be your team or your product.

So by the end of our talk, I hope you will not only be understanding the tech due diligence better, but also you already have some ideas on how to improve your work, whether it could be your team or your product.

So before we start, I want to ask you a question here. Hands up if you are already familiar with what tech due diligence is. Alright, five, six maybe? That's pretty cool. That's why I'm here. So don't worry. I expected that.

The truth is, in the fast-paced world of software development, whether you're part of a nimble startup, hungry for its first round of funding, or a key player in a well-established tech giant, considering it a strategic acquisition, the concept of tech due diligence is one you are most likely to encounter at some point in your career. We have various forms of due diligence, but today our spotlight is on TechDD, which directly involves us as software engineers.

So tech due diligence isn't just a box to tick. It's a thorough examination that can influence the future direction of a product or the entire company. Of course, on the other hand also, it is quite critical for investors, stakeholders, and potential buyers to understand the technical robustness, scalability, and future-proofing of the technology that underpins the company that they are really interested in.

A typical robust, let's say, TechDD involves several key steps, from starting with a kick-off session to define the scopes and objectives, to the thorough analysis of the technical architecture and code base. The process is usually spread over a few weeks to ensure an in-depth analysis without significantly interrupting the company's daily operations.

The areas which will be explored during a TechDD are tech team, team culture, of which are here, the product scalability, tech stack, of course, what frameworks they're using, languages, choice of tools. Tech assets, which is basically where we gain access to the data, get as much data as possible we can, and process them to extract some insights from. Product management, product development roadmap, maybe also even a competitive analysis. And lastly, legal and IP section, which could be quite critical for companies maybe in the sector of cybersecurity or insurance, let's say.

The outcome of a TechDD is a detailed report that provides insights into the technical health of a company. It identifies strengths, weaknesses, opportunities for improvements, and potential risks. Findings are almost the most important element of any TechDD report. In this context, a finding refers to a significant piece of information that has been uncovered during the TechDD process. Each finding is data-driven and often supported by visual aids, like charts for better understanding. They look at different things, like how serious a problem is, or whether it could be solved easily. This approach, of course, help us to sort out which issues are big deals and which ones aren't, and to spot any major concerns or red flags.

Red flags in TechDD diligence are essentially a combination of issues or findings that signaled potentially serious problems with a company's technology strategy or implementation. Red flags aren't just some simple alerts. They are evaluated based on how easily it can be fixed, the amount of effort and resources needed to address the issue, and the estimated duration for resolving the problem. Although it is not, I would say, although it is not relatively frequent for any company undergoing a TechDD to have a red flag, what's having a red flag is something to definitely vary off, because they could significantly impact a company's technology operations, and by extension, its business success.

Not that we have understood the concept of TechDD, you might wonder, where do I, as a software engineer, fit into this picture? So let's unravel that.

Front-end engineers, like many of us here, are the bridge between design and functionality. Our role is pivotal, but how does it interwine with TechDD? You are all like, as if being a software engineer wasn't already like you walk in the park, endless coding, keep up with the ever-changing stack, like I'm talking about two major releases of Next, I guess, every six months, right? Yes, you are already familiar with that. But don't worry. You don't actually need to do too much extra to be prepared for a TechDD. That is, of course, if you're already doing things right. So let's get to the how to get prepared part.

Preparation is the key success in almost every endeavor. In the realm of TechDD, our code infrastructure lays the foundation. The examples which we're going to explore in the following few minutes are among the most significant or commonly overlooked issues based on our experience from the real-world TechDD. I believe this approach will help us gain a better understanding of how this looks like in practice and how they can impact the tech environment. It is crucial to remember, however, that red flags and findings are highly relative. Same issue or finding could be in the situation of one company a really big deal, a huge case, but the same problem could be like nothing really important, of course, again, based on the company situation. So that's why each situation demands a tailored response, considering unique characteristics and needs for the company. So let's get prepared. The very first part of getting prepared for anything is to get to know the thing itself. Here is also no exception. Luckily, we are already familiar with the essentials of TechDD diligence, like its steps, goals, and what it looks for. So the first step is already done. It wasn't hard, right? So till here, a quick recap. We do TechDD. You learn what is TechDD. Now we're going to see some real-world examples from our TechDDs, and that will help us getting prepared better for such a process, or generally getting better in that thing. Now, let's dive deep into our first section, dependencies and licenses.

This is critical area in TechDD diligence, especially for SaaS products. The key thing here to remember is open-source doesn't always equate to free to use without any restrictions. Misunderstanding this can lead to significant legal risks and potentially turn into a red flag all on its own. That was a little bit of a delay. All right. So it's not just about using them. It's about understanding the licensing, keeping track of their updates, and knowing their maintenance status.

Actually, let's have an example here. Consider a scenario where over 40% of a project's dependencies require major updates. What does this chart tell us about? If you'll see it, it's like this chart not only flags the potential security risk within a product, while we have like 40 more than 40% of the libraries needing major updates, but also indicates a need for the development team to enhance their monitoring and update processes. Moreover, the choice of a certain open-source licenses needs careful consideration. That's because using some licenses without a solid reason can be risky, potentially affecting business operations and compliances. So we watch out that part.

We all might just know about MIT license, which we use daily, but it's definitely helpful to get to know some other open-source licenses and their implications. Moving forward in our How to Get Pre-Purchased series, now let's put our attention to automation and infrastructure. The goal here is almost clear, like to automate as much as possible. The benefits of automation in tech is well known for all of us. Efficiency, consistency, scalability. However, there are certain aspects that can raise red flags.

First, let's talk about monitoring. Is the company's approach reactive or proactive? Do they have real-time messaging systems in place to notify them immediately of problems? Because this is of course really crucial for timely responses to the issues, right? Circling back to licenses, automating license monitoring is definitely a smart move. That's because licenses not will change, but can change during the time, and the change actually can affect our product really very heavily. So let's keep that in mind. Some ports appear could be implementing pre-commit hooks in pipelines. This can prevent many issues by ensuring that the code meets some certain standards before it's getting merged. Lastly here, I see it important to mention that in a tech D.D. process, some shortcomings are totally expected and acceptable, of course depending on the company situation. But the thing is, it's not about not having any issues. It's about not having unsolvable issues in the future. Interestingly, if a startup appears too perfect, itself could turn also into a red flag.

Now let's shift our focus to documentation. This old saying perfectly captures the often overlooked importance of thorough and accessible documentation in technology processes. How many of us here rather write code than documentation? Hands up. See, we all agree with that. This often leads to a scenario where in startups, documentation might be almost nonexistent, which is acceptable in some cases. But surprisingly, even in larger companies, it's not uncommon at all to find significant gaps in technical documents. I'll say, one of the most critical types of documentations is technical onboarding material. Considering how frequently startups change their teams, it's ideal for a onboarding document to be comprehensive enough so that a new engineer could start meaningfully contributing to a product within the first month or two.

While these tools have their place, of course, they fall short in areas like searchability and indexing. Too often we see important documents dispersed across platforms like Google Drive, Google Docs, which make it hard to find information when needed. If you're asking us about ideal approach, when it comes to documentation, it's all about knowledge accessibility and knowledge availability. Documentation should be centralized, ensuring that there is there when we need that. Assigning an owner to each document can definitely help maintain accountability and keep the information up to date. And even we can integrate documentation creation into your development process. Maybe even put it in your definition of done in your tickets and stories. I'm pretty sure that would be a perfect place for that.

Next up is a choice of frameworks and tools. Typically, the choice of frameworks or language isn't itself a big deal, as most have long-term supports. For instance, even a language like COBO, seemingly outdated, isn't an automatic red flag. However, the rationale behind choosing such older technology is what matters. Is there a strong justifiable reason for its use? Or if it's outdated, is there a plan in place for migrating to more modern technologies? Let's put our attention to another example in this area. Imagine a case that a company should choose between native mobile application development compared to hybrid solutions like React Native. If the company, in this case, goes for the first option, it needs to be backed by solid reasoning considering higher maintenance costs of the native mobile application development compared to hybrid solutions. So after all, beyond just picking a library or framework or a package, it's about making informed choices. Generally speaking, it is best to avoid reinventing the wheel and opt for well-established, widely supported frameworks, unless there's a compelling need for something more cutting-edge or older, let's say.

All right, we have reached the last step. In the last step, let's turn our attention to code quality in our take to diligence preparation. A critical aspect of a code quality is ensuring consistency across the board. This is where automated tools like ESLint become invaluable. Coupled with Comethooks, these tools help maintain a consistent coding style throughout the team, making the code more readable and of course more maintainable. We often come across the issue of hard-coded values and configurations. This includes case like customer-specific hard-coded configurations or hard-coded secrets within the code. Although it's a very common frequent problem, we see that a lot, it's the one that could be really, really easily fixed, yet frequently overlooked. For front-end development, maybe us front-end engineers, we remember that any secrets used on client-side devices can pose a security risk, considering that most front-end applications are being built and served on the client-side. Of course, there are some exceptions. I love tools like Next.js, Remix, BigFan. But generally, if you try to keep the secret as far as possible from the client-side, you should be safe. So the focus here is not just on writing a good code, but on writing secure, scalable and maintainable code.

And just to keep things in perspective, always remember this piece of advice. The next person reading your code might not be a junior, but a senior serial killer, and he knows where you live. With this amazing news, we have reached the end of our journey. I hope this session provided you with a clear perspective on the importance of taking the diligence and unrolling it. Thanks for your time and attention.

Where do we want to start? Maybe let's differentiate between software development best practices and take due diligence.

Of course. Where is the difference? Because this could also be like, hey, best practices for software development.

Sorry, I didn't get your question. I mean, all of that stuff also applies for like a general software development. If I don't want to prepare like an acquisition.

Exactly. So yes, the whole thing about taking due diligence is like, I mean, when we do take due diligence, because we want to know if a technology is robust, which is, I mean, the technology operations of a company is robust enough to invest or acquire or whatever. Or even a take due diligence could be a health check. Just for example, a CEO or a CTO wants to know if everything is going right within their company, right? Mostly CEOs. And of course, having a healthy product, I mean, best practices are there for that, right? And that's the whole purpose of having best practices.

And when you write the report, how do you actually formulate like some findings you have? Do you say, OK, well, the code base looked a bit odd and they didn't follow the practices?

Basically, well, I would say each company does take due diligence a little bit different. But generally what we do actually is, as I mentioned also in the talk, all findings are data driven. So we either have like proper data or proper case to show or examples. And they are mostly coming with some charts provided by our in-house tools and amazing data engineers.

And if you write the report, like what's the oddest stuff you did find during take due diligence?

Ah, that's a good question. First of all, I need to clarify here that I myself don't do take due diligence because in order for you to be able to do it, you need to have like really a huge experience behind you. Right. So what we do actually, we have like an amazing SCA team which have like more than 50 years of CTO experience. And they are actually the main leader of each take due diligence, because in order to like, by looking at the chart or data and insights, they just have a gut feeling of if everything goes fine or not. So it definitely needs a really rich background. What I do actually, I am mostly working on the in-house tools that we have and engineering. But I definitely face cases, I would say maybe, I don't know, something is top of my mind, copy pasting jQuery in your React. Okay. I just remember that at the moment.

Okay. And if you find that like, how do you respond to it? And do you try to like improve the situation with like the clients? I mean, as I mentioned, take due diligence is highly relative on the company, right? I mean, it's not just that we get access data and we analyze them. There are also lots of interviews, as you've seen in the processing slides. SDAs will actually have, they have in-person interviews with like senior software engineers, tech leads, managers. So it's not just data that we have, but if they see something in the data and the code base, they would definitely, will discuss it in the interviews. And if they are not convincing yet, of course something is wrong. Yeah.

And you mentioned that it's highly dependent on the company, but is there any agreed on best practice to do this and how much do they differ? I would say not really, because it's, it's, it's a really niche market, right? I mean, you don't expect, I mean, it depends on where are you working actually, what is your market, but it's, it's not a really huge market and therefore there aren't also like many big players out there. But we try to do our best, we try to be best, at least in Europe. That's a good, good thing.

And maybe we can move on to some practical examples. Sure. Like, like do we have like a guideline on where to actually place the documentation, what should stay in the repository and what should get, go into some company wiki? I would say it's whatever works best for your team and again, data should be accessible and available when you need it. I think by just having these two points, everything should be fine. Like it doesn't matter actually what tools you're using. Of course, if it's a, if it's a tool that has a, like, I don't know, huge learning curve and all of your teams cannot keep up with that, that's a problem. But generally, yeah.

About keeping up with stuff, like you should drive the tech TV stuff within the company, it should be like an engineering managers to make sure that it's all followed or should it be the singular developers? And how do you educate the rest of your company about like best practices related to that? You can also read the question, because I didn't get your question. Like, could you elaborate more on that? Yeah. So I think like a lot of us are wondering, like, who should drive this in the company? Should it be a grassroots effort from the engineers? You mean, you mean the very person which is the first point of contact in the process of take due diligence? There are usually like CTOs. And so the CTO should ensure like long term that his company is ready for that? Actually, it depends. Like if they are, if they expect to raise some funds in their future. I mean, based on their situation, as I mentioned, again, it's highly relative everything here. That's why super experienced guys living every tech TD with lots of like background and being in industry for like, you know, 10 or 20 years. But yeah, actually, that's the reason. So it's highly relative. But again, if they expect something like that, they could be prepared. And what's the best way to get more experience there? If you want to like move up into that path? I mean, it wasn't like something magical happening there. It was all the points that I mentioned, you can easily find them if you search like best practices about documentation or best practices about, I don't know, infrastructure automation.

It was all the points that I mentioned, you can easily find them if you search like best practices about documentation or best practices about, I don't know, infrastructure automation. Or basically, there are like tons of articles out there about best practices. And what I just mentioned in this talk was like the points that we frequently face. And it wasn't just wanted to like mention, because we can also like feel that better. But generally, it's following best practices, have a clean code, like I'm in this like, among the things that we all know as principles of being a software engineer, right? So it's not something magical happening there.

And how would you sell that non-magical stuff happen to non-technical people in the company to me to make sure that they are like, willing to spend the business? That's a good question. I mean, I mean, I thought we have engineers here. But I'm joking. Basically, sometimes I mean, I don't know if it's correct to say most of the times or not. But this market connection and networking is really important. And most of the times you have like a client, which is maybe a VC want to invest and a target company, which wants to for example, in this case, imagine that wants to raise some funds. So the target company has no other choice if they want the fund, they need to undergo technical diligence. And how do VCs choose us? Maybe because we're the best maybe. Well, I mean, I guess no other choice then. And I guess you just said that there might be some developers in the audience. I think we all as developers, we love automation and tools. And there's definitely tools for like doing license checks and stuff. And do you have any recommendations there? And do you also have like a general tool recommendation how to track your own?

Yes, again, again, if you can search for those tools, there are like, lots of them out there, you can actually compare and choose the one based on your situation that fits your company the most. But the most famous things out there for example, depend upon maybe it's a, it's a, it's a bot that you can integrate in your GitHub workflows. And it will just check if you have like any outdated dependencies and it will just create automated PR so you can review and merge that. Making things much more easier, you don't need to always check everything. And anywhere there it will say you if for example, this update has some fixing some critical security vulnerability or not so lots of good inputs there. We can include other tools like Sonar maybe in your, if you're already aware of that, in your development pipelines, it's also like tons of features, one of them could be monitoring. Okay, and let's close with like one last question. Especially in the EU like data privacy is getting more and more and more important. And you said like you actually analyze data for companies you're looking into. So like what are the companies allowed to share with you? And how do you make sure that that data is like only used for your process? Again, I would like to mention that. I mean, if a company for example, imagine a case you have a company you want to raise some funds, raising funds is not easy, right? And if you find a VC and the VC wants you to undergoing a Tech TD, and then finds you, you will definitely undergo Tech TD. So it's like, somehow, most of the times, it's for the best undergoing Tech TD. And therefore, they have to like cooperate.

And of course, some companies, they, for example, don't cooperate, like in a good way. Maybe they don't want to give up some critical data. But I mean, we are signing NDAs, everything is legal. There's no concern about like data leakage or anything like that. Everything is anonymous. I mean, we are living in Europe, right? We have strict rules about that.

But generally, if speaking about, if you want to know what datas we usually get access to, in the best case, I would say everything possible, like from access to all the source codes, every process source codes. And we have like lots of different data engineering processes out there, which can extract some amazing datas and insights. From ticketing systems, there are like valuable insights hidden into ticketing systems. We can like gather much knowledge about that. And an organizational chart, maybe the salary structure, like basically everything may be in between of a Tech TD process. Also, STAs could ask for a significant documents, maybe again, to ensure about something. So anything would be, I mean, the more data, the better we can. Well, that's probably 25th century. The more data, the better.

One last question from me there. You're saying you also want the source code, but how deep do you actually go into like single lines in the source code analyzer? Do I need to like be thinking, be scared that Amin's going to come around and check my Monday morning source code? Actually, I mean, sometimes a company either going to Tech TD could have like tons of repositories, millions lines of codes, and it's definitely not quite efficient to go over all of them, right? So we have automated processes like automate, we are actually going through codes like within the data processes that we have, and we gather some insights like, for example, I don't know how detailed I am allowed to go, but for example, we can understand maybe which file could be like hotspots maybe, or generally even STAs. I mean, if you're an experienced guy, you could like figure out somehow which file is important, which is not, which contains some business logic, important business logic, and have a look at that. That would reveal so many things.

That sounds super interesting, but we need to close down here. But if you have more questions, you can go to the speaker Q&A now.