Risk Management Guide for Startups: What Are the Key Tech Risks and How to Mitigate Them

Some risks that are thought to be unknown, are not unknown. With some foresight and critical thought, some risks that at first glance may seem unforeseen, can in fact be foreseen. Armed with the right set of tools, procedures, knowledge and insight, light can be shed on variables that lead to risk, allowing us to manage them.

In today’s era of revolutionary innovations, startups of all types are often vulnerable to a number of threats and have to operate in a highly competitive and uncertain environment. According to statistics, an estimated 90% of startups fail within the first 10 years due to unforeseen circumstances.

Still, technical issues or issues somehow connected to technologies or a tech team are one of those that must be considered within the shortest time possible.

In this article, I want to speak of the risks that many startups tend to encounter and provide you with a few mitigation tactics based on my expertise. Basically, each product has its own risks and pitfalls, but I will highlight only the most common ones from my practice.

Content

• A few words about myself
• Risk assessment and evaluation
• Connection to tech due diligence
• Tech risks: types and mitigation tactics

A few words about myself

Looking back, my career started in 2007 when I was studying at Sumy State University. I was about to develop a startup, but I didn’t know such a word back then, so it was just another project for me. Genuinely speaking, I had no accurate picture of what must be done. Nevertheless, my first startup proved to be a successful and profitable marketplace for SEO agencies and website owners.

Yet time marches on, so I have a strong technical background now — I’m the founder and CTO of Casers startup and Brocoders startup development company. To date, we’ve built more than 70 successful products, including startups at an early-stage or round A. Now I have a few success stories under my belt, along with a few failures.

Recently, I held a workshop with the experts from Startup Wise Guys accelerator sharing my experience and discussing some critical tech startup issues with examples from my career. In this guide, I want to do the same. You may find a lot of things that you already know, but I hope some others can help you sleep better.

You can also view my presentation and workshop video here

Risk assessment and evaluation

Now, what is startup risk management in the first place? I would say that it’s a set of methods for risk identification and analysis that allows you to find out what potential issues can damage your startup project the most. Backed by such information, you can provide suitable means to ensure substantial risk reduction early on.

Following specific metrics, you can identify the risks with the highest exposure and eventually develop cost-effective mitigation approaches. Let’s make a risk management framework to cite an example.

As you can see, there are two criteria for each risk:

• Occurrence probability
• Impact severity

These two criteria form four sectors that allow us to narrow the focus on particular risks that require urgent mitigation, while others can be ignored for a while since they are not so critical after all.

Those risks from the D sector, if not treated properly, can ruin your business and leave you bankrupt in some cases. So one of the most significant tasks that you have to face as a startup owner is managing and mitigating such risks as if your life depends on it.

A pragmatic risk management plan is exactly what you need to manage potential tech issues properly, and it shouldn’t be a problem for you to create one. You may want to take a look at this risk assessment example table. It consists of 7 columns:

• Risk: You can brainstorm anything that could cause substantial harm to your business
• Type: Assign the risk to one of the categories. Assigning a type can suggest who might be best qualified to manage that particular risk
• Likelihood: Think of the relative probability of manifesting this particular risk. Simple descriptors like high, medium and low should be sufficient
• Consequences: What would happen to the company if this risk factor manifests itself
• Mitigation Tactics: List the things you can do to either reduce the likelihood or minimize the impact of the consequences in case this risk manifests itself. Please also note that just because a tactic is available, it doesn’t mean you should employ it
• Mitigation Costs: For each mitigation tactic, think about the implementation cost
• Status: Once you have assembled the first six columns, you need to decide which mitigating tactics, if any, you need to implement. Your choices will depend on your personal risk tolerance – there’s no right or wrong answer

Connection to tech due diligence

As I mentioned above, one of the key factors why startups fail is technical issues, and even well-established companies can run out of their budget and resources for the same reason. That’s why venture capitalists (or VCs) and angel investors conduct tech due diligence in the first place. But what Due Diligence or simply DD is all about?

Due diligence is an assessment process conducted either for a company that is buying another company or for a VC before the investment round. DD helps to understand all the risk factors and estimate the deal.

For example, Facebook buys a company that operates a face recognition technology. Based on due diligence methodologies, Facebook will have to check:

• If the technology is accurate enough
• How easy will it be to integrate it with other Facebook products
• How scalable it is in terms of performance: can the technology solution handle more requests than it handles now
• Whether the team will be able to adapt and maintain this technology

Not that long ago, I had a chance to talk to a company owner focused on providing DD services for 15 years straight. And he mentioned that many of his clients are actually startups, not only VCs or private investors. And this sounds reasonable: it’s way more important for a business to understand its potential risks than for anybody else.

DD may take from two to thirty days to conduct, depending on what investors would like to assess. Assessing risks can be divided into two types:

Immediate risks can blow up the company. Example: the entire business is based on an online presence, but you have only one poor-quality server on cheap hosting, and you are down for seven days in a row because you didn’t manage to fix the issues. Or otherwise, you came up with severe security issues, and you get hacked, which by itself damages your brand reputation (especially if you are in finance or another industry where trust is the key to success). Hidden risks are harder to identify. A wrong team setup leads to wrong tech decisions. Thus, a lack of skills can just make business growth impossible.

Moreover, DD depends on the stage of the assessing company. For example, tech DD is not even worth performing at the seed stage since there is not much there yet, and things can still change at any moment.

Tech risks: types and mitigation tactics

Now that you know the key aspects of the risk analysis process, we can view the risks themselves. Again, each product can have its own risks, as well as each company can have different weights for likelihood and corresponding consequences.

I collected the most popular and the most significant tech-related issues that my companies or partners faced and divided them into six groups:

• Development and source code
• Product and QA
• Team and process
• 3rd party
• Vulnerability
• Disaster

Each group consists of 3-5 risks so that I won’t dive deep into each of them. Instead, I’d like to tell you more about those that I know better and where I can provide valuable suggestions.

#1 Development and source code

Let's get started from some geeky staff: risks related to technology and the code itself. There are four typical problems here:

• Code quality and technical debt
• Speed and technical debt
• Technology selection
• Buggy code

Code quality and technical debt

So, what is a technical debt anyway?

Imagine you are building a button component following designer instructions. It has a particular height, but your designer warns you that it may be changed later.

You have two options here: you can either build a unique interface for this component that will help you smoothly change the height in the future or just hardcode a height value.

The second option is a bit simpler and faster to implement. In such a case, you should opt for technical debt since you will have to redo (or refactor) the element if the height is changed someday. Certainly, you can change a hardcoded value all the time, but it will take more time and slow down the development process.

So, tech debt occurs when a team decides to opt for a speedy delivery solution instead of a better approach that would take longer to implement.

When it comes to code quality, you always face a dilemma: build your software fast or make your software awesome. It’s not possible to follow two strategies at once.

You have to choose which one is more important for your company now, so there is no right or wrong choice here. Indeed, you still can try to balance, but it is harder to achieve in most cases.

Some years back, we were developing a startup project for accounting firms. The high speed was a top priority for them since they still didn’t find a suitable business model back then. We had two senior developers working on the project, but we also hired one more ambitious expert to enhance the development speed.

He always tried to build things perfectly and redo everything to deliver the best code. And... he left the project quite quickly. He wasn’t aligned with the rest of the company and felt uncomfortable there, as well as the company itself.

The developer’s seniority is not usually about delivering the perfect code but rather about being aligned with the core business needs. A senior developer can outline tech debt and postpone the refactoring for the later stage if the business requires a fast solution.

Here are a few tools that will be useful for maintaining good code quality:

• Sonarqube, linters, code style guides. This is basically a set of rules each developer in the company must follow. For example, tools like ESLint can help you check automatically if these rules were followed in each update of your application. It also would be great to integrate a linter to your git-flow development process. It will automatically reject any code from being merged with your current application source code until it satisfies the requirements.
• Report tech debt, communication. Here I’m suggesting that if you decide to take this debt and fix it later, you may want to put it to your task tracker backlog with a “tech debt” tag, so you never forget that you took it and can fix it later.
• Microservices. The microservices architecture allows you to separate a complex app into smaller pieces. When you reduce the complexity, you improve your source code quality in particular.

Speed and technical debt

Ok, I am getting back to the speed. The downside of the priority to move fast and take tech debt is slowing down the development speed. Sometimes, you may have to rebuild a project from scratch, but it’s not the worst scenario, and many companies go through this process.

When a startup is at an early stage and is actively looking for a business model to apply, it must be flexible enough to adopt changes immediately. As a result, it may bring a considerable amount of tech debts, since usually, teams don’t have the time to consider every detail and take care of tech debt right away.

You know, like, you come up with a lovely project architecture and write beautiful structures and bum! The CEO announces a little change (he believes it’s a little one), and it breaks all your architecture completely.

However, when you have already discovered and tested your business model, sometimes it makes sense to start a project from scratch while supporting your product’s current version. In such a way, a new version will be designed properly with minimum technical debt.

Try to ask yourself: How are we going to keep that velocity in the future?

Technology selection

By technology, I mean programming languages, libraries or SaaS sometimes. I spend a bunch of time selecting proper tools for particular tasks to enable a project’s safety in the long run.

On the other hand, it’s vital to ensure that the experts responsible for technology selection really cut the mustard. I’m talking about CTOs and tech leads.

To make sure that technology fits your project’s needs, you may want to pay attention to:

• Tech-related community
• Corresponding trends
• How difficult to learn and how many experts are there
• Performance
• Code quality
• How difficult to customize (customization can take longer than building something from scratch)
• Bugs and how fast they are resolved

Buggy code

It’s not about code quality. Even a beautiful code that follows all the best practices and style guides can generate tons of bugs.

When changing a very independent feature, you may break something else unexpectedly. It always happens. But you need to know what exactly was broken to fix it at the very early development stage.

A pretty obvious tactic here is to write unit tests. With unit tests, you can cover individual functions in the source code to ensure that the functions and modules work correctly.

Besides, QA engineers can also include acceptance criteria and test cases in task tracker tickets. Thus, developers can check their work and ensure a hassle-free working process.

To cite an example, the task is to create a new filter “by a product type” in your product list. Apart from the task description, you can add the list of acceptance criteria:

If a user clicks on the filter dropdown menu, there should be a list of all product types, defined in the admin panel If a user selects a product type, a product list should include only products of this type Admin should be able to create new product types in the admin panel and so on

#2 Product and QA

Now we move on to the risks related to a product and QA. Some early-stage startups may sometimes afford to move the testing process to their customers, while other companies with sensitive users can’t opt for such an option.

The question is about the consequences. What if your customers will face critical bugs? Will you lose them? What is the loss for your company?

There are three critical problems here:

• Product full of defects
• Scalability, capacity
• Hidden errors and uptime

Product full of defects

Unit tests can’t cover end-to-end functionality since they don’t check whether a product feature works like a user expects it to work. Usually, developers or managers cannot implement a sufficient QA process by themselves. So, a dedicated QA Engineer or a QA team is a must.

Besides, I would recommend you pay attention to TM4J. It is a test management tool for Jira, one of the most widely-used task trackers for IT projects. It is a useful tool that fully integrates the QA process into the development and keeps it very visual. It works very well with both manual testing and test automation.

Scalability, capacity

Scalability and capacity. For me, it always sounds like a problem that I really enjoy facing: when you unexpectedly get 10x or 100x more customers in a day.

There are many services and tools for load testing, which helps you understand how many users your application can handle per minute, for example.

However, the most important thing here is to know your bottlenecks in terms of performance. So when you find these, you can use a scalable solution for this particular part of your product, such as Amazon Lambda.

In Amazon Lambda, you pay not for the time your server is running but for the number of calls or operation cycles. And it scales really easy. However, you can read our posts about other things we’ve learned while using Amazon Lambda for one year.

I wouldn’t tell a lot about this, because it’s more about companies at a later stage.

But I remember the story. Let me show you the video video.

We came up with this idea suddenly. I've been so impressed by it and the tech challenge behind it that I couldn't stop coding. And when the project was released, it reached about 10K registration after just 3 days. And the product wasn’t ready for such a high load at the first go-of.

So, it’s always better to test your capacity if you have a chance, even if you are at an early stage.

Hidden errors and uptime

Sometimes you may be unaware of critical malfunctions until it’s too late. You can’t rely entirely on your QA team and customers’ reports, so it’s better to act proactively. I remember the story about one quite mature farmer app from the US when customers didn’t receive real-time push notifications. In fact, they managed to spot the issue only two months later while analyzing logs.

To avoid the same issues, you may want to take a look at the following solutions. Sentry and Bugsnag are great tools for exceptions monitoring. Also, New Relic or Logz.io are very useful when it comes to log analysis.

#3 Team

Well, this risk is way harder to evaluate and mitigate since people are unpredictable.

Choosing a partner and your team is crucial. So, don’t forget to do a background check even if you know the person. I remember one CEO from our accelerator batch who was always speaking of his partner like they were best friends. And you know what? They broke up after three months. The reason was the inability to deliver a product with the right code and within a certain deadline. So there are no best friends anymore.

Miscommunication brings a lot of problems, too, I should say.

So, you may want to have a product roadmap accessible for 2-3 months ahead for all the team members to see and contribute to.

You may also want to write and share company values and goals with every teammate and force the tech team to participate in meetings with your clients. Founders must have a real vision of where to take the product next and have a fountain of ideas.

To hire top developers, the CTO must be able to sell as well as the sales team does.

To be able to react and iterate fast, you have to implement an agile development process. A handy tool here is CI / CD that helps deploy immediate reaction to customers’ feedback. However, yet it requires test automation and sufficient code coverage.

#4 3rd party

One more category of risks that is also hard to manage is third-party services (or external) because you can’t control them. Everybody uses integrations, 3rd party APIs, SaaS and so on. So everybody can face such problems.

I would advise you not to spend too much on vendor selection. Instead, you’d better use Clutch and do a background check before you hire a new company.

3rd party service goes down

Any service can go down once or a couple of times, or even regularly. You see, when I updated the presentation for the workshop and decided to take some screenshots from DownDetector, it turned out that GitHub had some severe issues: hundreds of reports from users per hour.

One exciting tactic here is to create an abstraction layer that will help you switch to another solution easier.

When we developed an application for the Nigerian market, we faced a payment issue since they didn’t have a suitable and stable payment solution there. So we had to create an abstraction layer to be able to switch between solutions if something bad would happen.

High cost of 3rd party services

A short story about the startup that used Google Places API widely. When we jumped into the project, the startup was growing, and in one moment, we realized that the bill from Google we had to pay out was more than 10000 USD, very close to what we were earning at that time.

That said, don’t forget to estimate the payment plans to be aware of how much money you will have to spend. Again, creating an abstract layer can help you out.

#5 Vulnerability

To reduce vulnerability risks, you may want to look at such monitoring solutions as Sqreen or Sonarqube. Furthermore, such tools can also help you avoid common mistakes.

Please always remember that the source code is your company’s main asset. So sign NDAs and keep them safe and sound.

#6 Disaster

Disaster. It’s the last category that is almost impossible to predict. Nevertheless, we are the witnesses that black swans exist. Sitting now at home and avoiding handshakes, for example.

Do not give up and wash your hands!

Wrapping up

Those tech risks we were talking about are definitely worth paying your focused attention to, yet most of them require in-depth expertise. That said, tight-knit risk mitigation strategies allow you to future-proof a predictive tech risk evaluation process and ensure your project’s success.

Therefore, it’s a good practice to get a piece of advice from a seasoned professional. We at Brocoders, are always ready to share our multi-year expertise and implement your disruptive ideas. Please, don’t hesitate to contact us to get a personalized insight.