top of page

From No-Name Startup to EDF Coordinator: 15-Month Story of Success

Oct 15
13 min read

Updated: Oct 16

theMOON article cover for “From No-Name Startup to EDF Coordinator: A 15-Month Story”

On 4 July 2025, Limited Liability Company "Dark River Group" was officially registered. Ten days later, I joined the company. Of five people.


My first task was relatively simple on paper: work with the operations manager and prepare an application for one of our products. The result was terrible.


The technology itself was real. The team understood what it was building. But the application did not speak the language that a defence programme expected. The military problem was not defined properly. The product was described from the developer’s perspective rather than from the perspective of capability. The structure did not match the requirements of Brave1. And I did not yet understand how defence programmes evaluated a technology.


So I started reading applications that had already succeeded. That was the beginning.

Fifteen months later, the work looked very different. Instead of trying to understand how to write one application, I was coordinating international partners, analysing the history of European Defence Fund winners and preparing a coordinator-led project under the Ukraine Support Instrument.


The change did not happen because of one grant, one event or one important introduction. It happened through a sequence of systems, relationships, mistakes and decisions.



July 2025: Starting from zero


A ten-day-old company does not have much organisational memory. Much of the knowledge existed inside individual people.


My first response to the failed application was therefore not simply to rewrite the document. I needed to understand why it was bad. I began studying previous successful applications and comparing how defence technologies were described. The distinction became obvious quite quickly.


A developer naturally explains: what the product is. A defence programme wants to understand: what capability problem it solves, who needs it, how mature it is, what evidence exists and what the next development step should achieve.


That difference became the first important lesson. Writing was only the visible part of the work. The underlying problem was structure.



Building a system before building a pipeline


At the same time, I started creating an internal knowledge base in Notion. The initial purpose was practical. If we learned something once, we should not have to rediscover it every time another application appeared.


The Wiki gradually started covering:

  • application processes;

  • programme requirements;

  • internal product information;

  • submission logic;

  • required documents;

  • lessons from previous attempts;

  • and the status of current opportunities.


I also created a system for tracking applications and results. Then a common table covering all company developments. Then a dedicated grant tracker.


Product presentations, development documents, visual materials and pitch materials began to move into a more structured workflow.


The company itself was also changing. Several products I had started preparing applications for disappeared because the people responsible for them left the company.


In August, more structured hiring started. A designer joined. The operations function developed. R&D leadership became more defined. That instability was frustrating at the time, but useful in retrospect.


It forced the fundraising process to become less dependent on one product or one person.


Between July and November, the work around Brave1 alone expanded significantly. We collected technical and media materials across the development portfolio. The company was verified on the platform.


Six developments were prepared for the defence review process, all passing that stage on the first attempt. Several grant applications followed. Products were added to the Brave1 Marketplace. APUS began to move into sales activity through the platform.


At the same time, we were already testing international routes. We applied to K4. We entered SPECTRA Challenge and received an invitation to pitch.


A backlog of foreign programmes began to form. None of this yet looked like a European defence strategy. It was still learning.


But there was now a system capable of accumulating what we learned.



November 2025: The first proof


In November, one of the Brave1 applications finally converted into a grant.


The wait had been much longer than expected. For a young startup relying heavily on grant financing, the result mattered financially.


For me, it mattered for another reason. It was the first grant I had won in the new role. Until then, most of the process had consisted of building, submitting, correcting and waiting. The grant created the first evidence that the methodology could produce a result.


But it also created a new question: What comes after the Ukrainian programmes?


By then, I already knew that a business development manager would join the company in January. I wanted her to arrive with something more useful than a list of links.


So December became a month of mapping.



December 2025 - mapping an ecosystem we had not entered


I spent December searching for European and international programmes in which a Ukrainian defence company could potentially participate.


That was when I first began to see how broad the landscape actually was. There were Scandinavian support programmes. NATO DIANA. EUDIS. PESCO. SAFE. EDIP.


Initiatives that would later become much more important, including BraveTech EU and the Ukraine Support Instrument, were still emerging.


And then there was the European Defence Fund. Next to EDF in my table was effectively one very simple conclusion: Ukraine is not eligible. At the time, that looked like the end of the route.


Every programme I found went into what became the Fundraising Table EU 2026.


But the table was not only a list of funding opportunities. For each route, I tried to understand:

  • what the instrument was;

  • who could participate;

  • what type of company it was relevant for;

  • what stage of technology it supported;

  • what action the company should take next;

  • and whether there was a realistic path for us.


The table continued developing throughout 2026 as our understanding grew.


Looking back, this was probably the first version of something I would later do much more systematically: map the ecosystem before choosing the opportunity. I did not know it yet. I was simply trying to prepare useful material for the incoming business development manager.


Preparing for EDF before we had a route into EDF


Early 2026 brought the EDF Info Days.


We still did not have a straightforward Ukrainian route into the programme. But that did not mean we had to wait. The event platform provided access to participant profiles.


There were 3,123 of them.


Instead of opening the platform during the event and randomly requesting meetings, I extracted the participant information and started working through it before the Info Days began.


Companies. Research organisations. Potential coordinators. Technology partners. People connected to relevant topics.


I started adding relevant people on LinkedIn and reaching out directly.


This changed something important in the way I thought about events. Previously, an event was a place you attended. Now it became a dataset.


The attendee list could be analysed. The companies could be categorised. Priority contacts could be identified. Meetings could be prepared before anyone arrived.


The event itself became the final stage of preparation rather than the beginning of networking. That approach produced the first major result almost by accident.



The first consortium started before the event


One of the people I connected with through LinkedIn was Martin. We spoke before EDF Info Days.


During that conversation, he mentioned another person - a scientist already involved in building a project. An introduction followed. Then another conversation. Then a discussion around the project concept. And suddenly the thing we had been trying to understand from the outside became real.


We had our first EDF consortium opportunity.


The important part was not that LinkedIn magically generated a consortium. It did not. The important part was the sequence: participant data → targeted outreach → conversation → introduction → technical discussion → consortium opportunity.

The consortium existed because the relationship started before the event. That lesson stayed with me.


Months later, when I started writing publicly about networking in European defence, one of the recurring ideas was that the strongest relationships rarely begin when a call is already closing. Consortium formation starts earlier. Often much earlier.



March 2026 - when the ecosystem became real


March was probably the month when European defence stopped feeling like a collection of websites, programmes and policy documents.


EDF Info Days took place. The first consortium discussions were underway. Around the same time, another Brave1 grant arrived for APUS-R.


I also began publishing on LinkedIn. My first analytical work around the European Defence Fund eventually developed into "Navigating the European Defence Fund".


That work was initially part learning exercise, part attempt to organise the information I had collected. But publishing changed the process.


When knowledge stays inside a private table, it only needs to be understandable to the person who created it. When you explain it publicly, gaps become obvious.


Why does this programme exist? Who can actually participate? Where do SMEs fit? How do consortium roles work? What is the difference between technical eligibility and a strategically useful role?


Writing forced me to answer these questions more clearly.


Then, on 25-27 March, I attended the EUDIS Defence Hackathon in Kraków. For the first time, I was not studying the ecosystem from a laptop. I was inside it.


European defence companies. Innovators. Programme actors. Mentors. People discussing technologies, military needs and partnerships in the same room.


At one point, someone asked a question that stayed with me: Why is a company as mature as yours participating in an event at this level?


That was strange to hear. Dark River Group had been registered less than nine months earlier. I had joined when it was ten days old. Internally, we still knew exactly how young the company was. From outside, someone was already seeing something different.


That was one of the first moments when I realised that perception inside an ecosystem is not determined only by age. It is also determined by how consistently a company appears, what it can demonstrate and how clearly it communicates its role.



The second consortium came differently


The first consortium had required deliberate outbound work. We had mapped people, contacted them and followed introductions.


The second one started differently.


In April, Khrystyna, our Business Development manager received a message from a representative of another company. She had seen her presentation during the EDF Info Days. Their consortium was already developing a project.


A conversation followed. Then another. We entered the second consortium.

This was a small but important transition. The first opportunity had to be found. The second one found us.


That does not mean visibility replaced business development. It meant visibility had started supporting business development.


At the same time, my LinkedIn activity was growing. The EDF guidebook led to more conversations. A webinar on navigating the European Defence Fund followed.


I kept meeting people. Our business development manager kept attending conferences. The number of independent points of contact with the ecosystem began to increase.


That is when networking started to become cumulative. One conversation created another. One publication created an introduction. One event made the next meeting easier. One project discussion created a reference for the next.


Visibility compounds.


Learning to say "No"


A later conference produced another opportunity. Our business development manager met a representative of a major European aerospace company.


The name is not important here. What mattered was the proposal.


There was an opportunity to discuss cooperation around a Ukraine Support Instrument project. A year earlier, the reaction would probably have been simple: A major European defence company wants to talk to us. Say "Yes".


This time, we looked at the actual project logic. The expertise was not the right fit. The partnership would have looked impressive from the outside, but the contribution did not make enough sense.


So I said "No".


In retrospect, that decision represents an important part of the transition. Entry into an ecosystem begins with access. Maturity begins when access is no longer enough.


A consortium does not become strong because a recognisable logo is inside it. Every partner has to solve a real problem inside the project. That applies to SMEs. It also applies to primes.


By that stage, the question was: Should we be in this particular project at all?



From applications to a European defence function


Around the same period, another Brave1 grant followed, this time connected with a flight controller. But the nature of my work had already changed.


I was no longer spending most of my time thinking about individual grant applications.


The scope now included:

  • programme analysis;

  • consortium formation;

  • partner communication;

  • European positioning;

  • project concepts;

  • work-package logic;

  • industrial cooperation;

  • funding strategy;

  • and the relationship between different EU instruments.


At my one-year performance review, my role changed to Head of EU Defence Funding. The timing mattered.


One year earlier, I had been trying to understand why my first application was so bad.

Now the task was becoming the creation of a repeatable European funding and consortium function inside the company.


And another change was happening at the same time. I was beginning to move from understanding programmes individually to understanding the network behind them.


August 2026 - building the EDF database


EDF consortium building can look opaque from outside.


A call document explains the topic. It explains eligibility. It explains the evaluation criteria. What it does not show clearly is the industrial network that repeatedly appears behind successful projects.


So I started analysing previous winners.


By 3 August 2026, the dataset covered EDF winning projects from 2022 to 2025:

  • 143 unique projects;

  • 2,243 consortium roles;

  • 1,313 legal entities.


The purpose was not academic. I wanted to know:

  • Which organisations appear repeatedly?

  • Who coordinates?

  • Which organisations are stable consortium nodes?

  • Which national ecosystems are most active?

  • What does a typical consortium look like?

  • Where do SMEs enter?

  • Which capabilities appear frequently?

  • Which activities appear less frequently and could represent specialised roles?


The data showed that around 77% of organisations appeared in only one project, while a much smaller group participated repeatedly. The ten most active industrial and research groups appeared across almost 60% of the analysed projects. A typical winning consortium included around 12 organisations from approximately seven countries.


The database gradually became more operational. The objective was no longer only to understand who had won. It was to use previous EDF activity to understand where future consortium entry routes might exist.


This was another change in perspective. At the beginning of the journey, I was searching for programmes. Now I was analysing networks.



From participant to coordinator


By late summer, the transition became much more practical.


One of the next major projects was UNITE – Brave NATO, prepared with Spanish partners. The work was much broader than writing an application.


I coordinated meetings. Partner inputs had to be collected. Responsibilities had to be clarified. The project logic had to remain consistent across organisations. Technical material, administrative information and supporting documentation had to be brought together.


The final documentation package reached approximately 157 pages.


At the same time, the two EDF consortium processes that had begun months earlier continued towards submission.


By then, we were no longer talking about European cooperation hypothetically. There were real work packages. Real partners. Real deadlines. Real budgets. Real dependencies between organisations.


And then came the Ukraine Support Instrument.


This time, the direction was different again. Instead of looking for a consortium that had space for us, I began structuring a coordinator-led project myself.


That meant thinking from the centre rather than from the edge.


What is the industrial objective? Which capabilities are missing? Which partners are actually required? Who should lead which work package? Where should production sit? What does each organisation contribute? How does the supply chain work? What evidence supports the scale-up assumptions? How does the project fit the programme logic?


The starting question in July 2025 had been: How do I write this application? Fifteen months later, the question had become: How do we build the project and which organisations need to be inside it?


That is a very different job.


What actually created the progress


The visible results were grants, consortiums, events and international partnerships.

The less visible part was the system behind them.

Step

What mattered

Why it mattered

1. Build systems before scale

Create the Wiki, trackers, application history and internal knowledge base early.

A company working across multiple programmes cannot repeatedly reconstruct what it already knows. Processes create organisational memory.

2. Map before entering

Build a picture of programmes, institutions and routes before an opportunity becomes urgent.

If the first time you study a programme is when its deadline appears, you are already late.

3. Treat networking as research

Analyse event participants, previous winners, companies, research organisations and potential coordinators before outreach.

Targeted conversations are much more valuable than random networking.

4. Publish what you are learning

Turn practical experience into analysis, guides and public content.

Writing improves understanding, increases visibility and creates new conversations around real expertise.

5. Move from access to fit

Evaluate whether the project, partner and role actually make sense instead of accepting every opportunity.

A strong consortium is built around complementary contributions, not prestigious logos.

6. Convert information into intelligence

Use data to identify patterns, recurring organisations, consortium structures and realistic entry routes.

Information becomes strategically useful only when it improves the next decision.

What I would do differently


A large part of the first months was spent discovering things manually.

If I were starting again, I would structure the process much earlier.

Step

What I would do

Practical action

1. Build the ecosystem map immediately

Start with the whole system rather than individual calls.

Map programmes, institutions, national actors, primes, SMEs, research organisations, accelerators, investors, procurement mechanisms, events and capability communities.

2. Separate the pipelines

Treat funding, procurement, partnerships and market entry as different processes.

Maintain separate pipelines for grants, sales, consortiums, procurement, accelerators and industrial cooperation.

3. Build partner intelligence earlier

Study previous projects and participants before outreach begins.

Track winners, coordinators, recurring partners, relevant national ecosystems and consortium structures.

4. Define the role before contacting the partner

Explain the company’s contribution clearly before asking for cooperation.

Position the company as a specific technology provider, integrator, manufacturer, testing partner, subsystem developer or validation partner.

5. Start before the programme opens

Build relationships before the formal application period starts.

Engage potential partners, coordinators and stakeholders months before the deadline rather than during the final preparation stage.

The larger lesson


Fifteen months is not enough to become an established European defence organisation. It is enough to learn how quickly a company can change its position when learning becomes systematic.


Dark River Group started this period as a company of five people. I joined ten days after its registration. My first application was bad enough that I had to learn the basics by reading other applications.


A few months later, I was mapping programmes we were not yet eligible to enter. Transition towards building a consortium rather than searching for one.


The most important change was not the number of applications. It was the direction of the questions. At first: Where can we apply? Then: Who should we talk to? Then: Where do we fit? Then: Which partners do we need? And eventually: What project should we build?


That progression is useful beyond one company.


European defence can look inaccessible from the outside because the visible layer is dominated by programmes, institutions and large industrial players.


But companies do not enter an ecosystem all at once. They enter through one relevant relationship. One useful capability. One project. One contribution that another organisation actually needs. Then they build from there.


The route is rarely linear. But it becomes much easier to navigate once the objective is no longer simply to find an open programme.


The objective is to understand the system well enough to know where you belong inside it. 

bottom of page