Lakestar’s new €262.2 million Resilience I fund is not just a funding announcement. It is a signal that European capital is becoming more willing to back companies that can sell into both commercial and defence markets. For founders, the real question is not whether defence funding is growing, but how to build a company that can absorb it without losing commercial momentum.

That matters because dual-use companies do not raise like ordinary SaaS startups. Their product cycles are longer, their compliance burden is heavier, and their buyers may include procurement teams, public institutions, or security-sensitive customers. The companies that win will usually be the ones that treat market access, certification, and deployment environments as part of the product, not as afterthoughts.

Why this fund matters to operators, not just investors

Lakestar’s positioning is useful because it shows where European capital is trying to go: defence, resilience, autonomy, and operational infrastructure. That is a broader opportunity set than “we build military tech.” It includes software for logistics, sensing, autonomy, cybersecurity, simulation, industrial monitoring, and other systems that can serve both private and public buyers.

For founders, this changes the fundraising conversation. Investors are not only underwriting growth in the traditional software sense. They are also underwriting access to regulated markets, contracts that may be sticky once won, and technical moats tied to certification, reliability, and integration complexity.

The implication is practical: if your product can be deployed in both civilian and defence contexts, the market story should be built around deployment readiness, not just innovation. Buyers and investors will want to know whether the system can survive procurement scrutiny, security reviews, and integration into existing infrastructure.

The funding model is different from normal startup growth

Dual-use startups often need to explain longer sales cycles and higher implementation effort without sounding inefficient. That is a hard balance. A commercial SaaS investor may expect quick onboarding and self-serve expansion. A defence or resilience buyer may require pilots, testing, documentation, and security review before a contract can even be signed.

This means the financial model has to reflect a different reality. Revenue may be lumpy. Deployment costs may be front-loaded. Gross margin may look unattractive early because engineering and compliance work are embedded in each sale. Founders need to model this honestly instead of forcing a standard software narrative onto a hardware or regulated software business.

That also affects how you allocate capital. In a dual-use business, capital often needs to go first into product reliability, system integration, and evidence generation. If you spend too early on broad sales expansion, you may create pipeline you cannot convert because the product is not procurement-ready.

What founders should decide before chasing defence capital

Not every startup should pursue this path. The best question is not “can we sell to defence?” but “does our product architecture support both markets without a costly fork?” If the answer is no, then entering the defence market may force the company into a custom-services model that weakens repeatability.

There are three decisions that matter most.

First, decide whether the company is building a product platform or a project business. Defence buyers often want customisation, but too much custom work can destroy scalability. If the roadmap is becoming a sequence of bespoke deployments, the startup may be drifting away from venture-grade economics.

Second, decide what compliance and security requirements are now part of the product. This could include data handling, export controls, hosting constraints, access management, or testing standards. These are not administrative extras. They shape architecture, cost, and speed to revenue.

Third, decide which customer segment leads. A startup that tries to serve both consumer buyers and defence agencies with the same sales motion may struggle. The better model is often one anchor market, one shared technical core, and a product strategy designed to reuse capabilities across segments.

What most people miss

The hardest part of dual-use is not building the technology. It is proving that the same technology can be sold, deployed, and supported in two very different commercial systems.

That means documentation, assurance, procurement compatibility, and support processes become part of the moat. Many founders underestimate how much buyer trust depends on non-product work: traceability, deployment controls, auditability, and the ability to pass internal reviews quickly. Those details often determine whether a pilot becomes a contract.

How to structure a dual-use go-to-market without wasting capital

A useful approach is to build one operating core and two market-facing motions. The core is the technology, engineering, and trust layer that works across segments. The market-facing layer changes depending on whether the buyer is commercial or public-sector.

For the commercial side, the sales motion may focus on speed, workflow improvement, and ROI. For the defence or resilience side, it may focus on reliability, compliance, mission fit, and deployment assurance. The mistake is to pretend those buyers want the same pitch deck, same onboarding, or same proof points.

This also has implications for hiring. Dual-use companies need people who can work across product, policy, and implementation. A sales team alone is not enough. Early hires often need to include systems engineers, security-aware product managers, and customer-facing operators who can translate technical capability into procurement language.

Founders should also think carefully about channel strategy. In some cases, the fastest path into defence markets is not direct outbound but partnerships with primes, integrators, or established suppliers. That reduces control but can shorten the trust-building phase. The trade-off is margin and speed of product iteration.

Where the operational risk sits

The biggest risk in this segment is not market demand. It is operational fragility. Dual-use startups can overpromise on performance, underestimate certification timelines, or assume that a commercial prototype can be sold into sensitive environments without redesign.

There is also financing risk. If the company depends on long procurement cycles, it may burn cash before revenue becomes predictable. That makes milestone planning essential. A founder should know exactly which technical, regulatory, and commercial gates unlock the next round of capital.

Another risk is strategic drift. Once a startup raises against the defence narrative, it may be pressured to chase contracts that do not fit the product roadmap. That can pull the team into low-margin services work or force custom development that weakens the platform. The funding story should support the product strategy, not replace it.

A founder checklist for evaluating whether this path makes sense

• Can the same core product serve at least two adjacent buyer types without major re-engineering?
• Do we understand the compliance, security, or export constraints that affect deployment?
• Can we model cash flow for long sales cycles and front-loaded implementation work?
• Is the company building a product platform, or is it drifting toward custom projects?
• Do we have a clear answer on who the first anchor customer is?
• Can our team handle procurement, assurance, and support requirements, not just product development?
• Does our fundraising story explain how the business will convert technical capability into repeatable revenue?

For founders building in resilience, autonomy, defence software, or adjacent infrastructure, Lakestar’s fund is a reminder that capital is becoming available for harder markets. The winners will not be the startups that simply say they are dual-use. They will be the ones that can prove the business model works under the rules of both markets.