Deep tech is not always defined by the product itself. Often, it is also defined by the way such a project needs to be evaluated. Deep tech starts where classical diligence is no longer enough.

In software or simpler hardware solutions, even at an early stage, you can often assess growth rate, retention, CAC, conversion, and the quality of founder execution. With technologically complex projects, that is not enough. Here the key question is not only: “does anyone want this?”. Often, we are talking about the future and making a bet on what the world will look like in a few years. That is why we ask much broader questions: does this technology really work, can it be built, used, protected, certified, and deployed in a repeatable way? Will the market be ready for it? And if not — will the company be able to co-create that market?

At Hard2beat, we therefore do not look at deep tech through the lens of the deck alone, market size, or a breakthrough narrative. We look for projects with a real technological advantage: unique IP, hard-to-copy know-how, a scientific or engineering edge, and a clear path to reducing risk over time.

We spend a lot of time speaking with companies that are still early, hard to assess unequivocally, often building products ahead of the market, and sometimes trying to move the boundary of what is even possible. In such projects, the classic question, “will this sell?”, is not enough.

You need to ask it differently: what would need to be true for this company to become truly large? Which assumptions are most fragile? Where could the technology fail? What is already evidence, and what is still a hypothesis? Will the company’s advantage grow, or disappear once the market becomes attractive to larger players? And finally: are the founders a team capable of carrying such a difficult project?

The reason is simple: a deep tech company rarely has only one type of risk. Usually, it combines several layers of uncertainty that, in classic startups, often appear separately:

• scientific risk — whether the operating principle is actually confirmed and backed by hard evidence, not just a promising story;
• engineering risk — whether the technology can be turned into a repeatable, reliable product that works outside the lab, in the customer’s hands, and in real operating conditions;
• market risk — whether the customer not only understands the problem, but also has a strong enough motivation, budget, and purchasing process to actually pay for and implement the solution.

A laboratory prototype can look impressive, but the road from a demo to an industrial, medical, energy, or defence product is long, expensive, and full of moments of truth. At each of them, it may turn out that the technology works, but cannot scale in production; that the product works, but does not pass certification; or that the customer sees the value, but is not ready to change the way they operate.

That is why our approach shifts the emphasis:

• from forecasting revenue -> to understanding what customer value must be proven;
• from looking at KPIs -> to testing hypotheses and mapping technological risks;
• from scaling the narrative -> to scaling the quality of evidence that the technology works;
• from asking “how large is the market?” -> to asking what needs to happen for this market to truly open up.

Technology and IP — where is the real value?

The first question is: what in this company is truly hard to copy?

We are not interested in buzzwords like “AI-driven”, “patent-pending”, or “quantum-ready”. We are interested in whether there is a real technological core that competitors cannot easily recreate by hiring a few engineers, using open source, or integrating available components.

In diligence, you have to separate the scientific promise from engineering reality. Key questions:

• what has already been independently validated?
• which results are repeatable?
• what works only in laboratory conditions?
• what are the most important unproven assumptions?
• does the advantage come from an algorithm, data, material, process, hardware, system architecture, or merely from integrating someone else’s components?

It is helpful to map the company across Technology Readiness Levels, or, in medtech/biotech, the EIT Health Healthcare Innovation Cycle:

• TRL 3–5 — laboratory validation, proof of concept, prototype;
• TRL 6–7 — pilot in conditions close to real-world use;
• TRL 8–9 — production readiness, certification, deployment with a customer.

Hard evidence is especially important: test data, validation reports, results from external laboratories, failure analysis, benchmarks against competitors, and clearly described next milestones in technology development.

IP also needs to be assessed critically. The number of patents matters less than the quality of the claims, enforceability, geographical coverage, and the risk of infringing third-party rights. A patent application alone does not yet create defensibility.

Green flags: independent validation, strong patent claims, a clear strategy for continuing IP protection, know-how that is difficult to recreate.

Red flags: only partial rights to IP, an advantage based mainly on trade secrets, no evidence of repeatability of results, a single provisional application, no FTO.

Regulations and standards — does the company understand the path to market?

In many areas of deep tech, the technology may work, but still cannot be sold quickly. Medtech, energy, advanced materials, defence/dual-use, and industrial hardware require certification, safety testing, compliance with standards, and often long purchasing processes.

That is why we ask: which regulations and standards apply to the product? Does the company know which certifications are required for commercialization? How long will all of this take and how much will it cost? Will the round budget finance this stage? Who on the team has already gone through such processes?

A good deep tech company does not just say: “we will do certification”. It shows a staged plan: tests, documentation, audit, external partners, risks, contingency budget. The absence of such a plan is not a detail for us — it can be a key red flag.

Production and supply chain — a prototype is not a product

This is where the difference between a slide and reality materializes. It is not enough to prove that something works once. You also need to show that it can be manufactured repeatedly, at the right quality, at an acceptable cost, and at a scale that makes business sense.

That is why we look at production not as an operational stage “for later”, but as part of the investment thesis. If the product requires specialist components, a non-standard process, difficult quality control, or a long supply chain, then the question of scaling comes much earlier than in classic software.

In the process, we check, among other things:

• does the company understand which elements of the product are the hardest to manufacture?
• are the results repeatable across batches, devices, customers, or environments?
• what do yield, quality control, and tolerance for errors look like?
• which components are critical, and are there alternative suppliers?
• does production cost realistically decrease with scale?
• what costs will appear after deployment: service, warranties, field support, component replacement, integrations?

Many startups reach a stage where the technology works, but the operations do not add up. It works in the hands of the R&D team, but not as a product that can be handed over to a customer, deployed, maintained, and serviced.

Therefore, in diligence we are interested not only in the demonstrator, but in the entire path from demonstrator to repeatable product. Sometimes it is production, not the technology itself, that turns out to be the company’s biggest risk.

Market and adoption — does the customer need to have it?

We are not interested in big-market narratives from a pitch deck. TAM does not buy the product. A specific customer does — with a specific budget and timeline, in a specific purchasing process, with specific expectations.

But that does not mean the market question is secondary. For a VC fund, it is fundamental, because at the end of the day we invest in companies that must have the potential to build very large businesses. That is why it is not enough to show that the first customer has a problem. You also need to show that this problem exists across a sufficiently large number of organizations, that budgets are real, and that the path from first deployment to broader adoption is credible.

In the process, we check:

• who exactly will be the first paying customer?
• what problem is painful enough for them?
• is this a must-have or a nice-to-have?
• does the customer have the budget and urgency to implement it?
• is the value the company is selling to the customer the same value the customer has in mind in the purchasing process?
• does the pilot have defined success criteria and clear rollout conditions?
• is there a large enough market behind the first customer segment for the company to grow to venture-backed scale?

The most convincing analyses for us combine two levels: bottom-up, meaning a specific first customer segment and a realistic sales path, and a broader market perspective that shows why this company can, over time, grow far beyond the first use case.

Business model — will innovation turn into a business?

Sometimes we come across the belief that simply creating an innovative technology should be enough, and should open the possibility of convincing investors to continue financing the team. Not every new technology comes with a business model capable of withstanding long sales cycles, deployments, support, warranties, certification, costly production, and reaching a scale that can satisfy investors’ return expectations.

We assess:

• is pricing based on customer value or only on cost?
• what does gross margin look like — now and at full scale?
• what are the costs of implementation, service, maintenance, and warranties?
• does the sales model fit the market: enterprise, government,
• is the company not assuming software-like sales velocity in a market that buys like industry or public administration?

Many deep tech companies underestimate hidden costs: tooling, certification renewal, warranty exposure, field support, integrations, delays. That is why showing an attractive target margin is not enough for us to make an investment decision. You still need to show how to get to that margin in the real world.

Team — can they move from science to business?

The best teams combine three competencies:

• scientific depth — creating technology and IP,
• engineering discipline — system integration, QA, reliability, production,
• business competence — founder-market fit, network, sales, regulations, partnerships, deployments.

In diligence, we check whether the team understands its own competence gaps. This is more important than declaring that “we have everything in-house”.

Good signals:

• a detailed roadmap of experiments and pilots,
• a hiring plan linked to risk reduction,
• domain experts with real experience,
• awareness of the technology’s limitations,
• clear “kill criteria” for subsequent stages.

The most dangerous teams are those that can talk very well about the vision, but cannot name the most important reasons why their project might fail. From our perspective, lack of risk awareness can be a bigger problem than the risk itself.

Financing — does the round reduce risk?

The first principle: new capital brought into the company should buy risk reduction, not just time. Each round should lead to a specific point that unlocks further financing or commercialization:

proof of principle -> validated prototype;
prototype -> pilot or certification;
pilot -> paid deployment;
deployment -> scalable production or repeatable revenue.

That is why we try to understand:

• what is the most important risk that will be removed thanks to this round?
• is the budget sufficient to reach the next value inflection point?
• what happens if certification, testing, or production takes longer?
• is the company not financing “half a stage”, after which it will still be too risky for the next investors?

Underfunding a critical stage, especially certification, production, or clinical/industrial validation, can kill even a good technology.

What are we looking for?

Deep tech due diligence is not about looking for a company with no risk. Such companies basically do not exist at the early stage. It is about something else: understanding which risks are fundamental, which can be reduced with capital and time, and which can break the entire investment thesis.

We look for companies that have a real technological core and can clearly show how they will reduce risk over time. We do not expect everything to be proven at an early stage. If everything were proven, the company would probably no longer be at the stage at which we invest. We do expect, however, that founders understand what is evidence, what is a hypothesis, and what is still only a good narrative.

The best deep tech companies do not have answers to all questions. But they know which questions are truly the most important. That is why deep tech diligence is, for us, a stress test of the investment thesis. Not to catch founders making a mistake. But to see whether behind the technology, narrative, and vision there is something that can survive contact with the market, regulation, production, competition, and time.

Because in deep tech, the biggest companies often start with very difficult questions. Not with easy answers… 

… and If you’re a founder wondering how to demonstrate these dimensions in practice, we’ve described them from the other side in the 10 slides we want to see in a deep tech pitch deck.