Eurostars is a Eureka programme that supports international, market-oriented R&D projects led by innovative SMEs. It is part of the European Partnership on Innovative SMEs, co-funded by Horizon Europe, and aims to turn collaboration between organisations in different countries into new products, processes or services and opportunities for business growth.
There are currently 37 participating countries: the 27 EU Member States, plus the United Kingdom, Switzerland, Norway, Iceland, Türkiye, Israel, Canada, South Korea, Singapore and South Africa. The programme usually has two calls each year. Proposals are evaluated internationally, while funding is managed nationally, through CDTI in Spain.
The evaluation covers three criteria: excellence, impact, and quality and efficiency of implementation. It considers the technological advance, the expected commercial results and other impacts, and the consortium's ability to carry out the work.
In my experience as an evaluator, I have seen proposals that connect these aspects very well, and others where, despite an interesting idea, important questions remain unresolved or unexplained. Some issues come up repeatedly and are worth looking at more closely.
Putting the proposed advance in context and identifying the technical challenges
To understand what a project contributes, we first need to know what already exists and where its participants are starting from. However, some proposals confuse the state of the art with competitor analysis, or use the state-of-the-art section to describe the company's own development and its technology readiness level (TRL).
These are three different points of reference:
Distinguishing these helps put the proposed advance in context, but a fundamental question remains: what technical difficulties will need to be overcome to achieve it?
Many proposals explain the basis of their innovation well and even provide a good analysis of the state of the art, yet fail to identify those challenges. This is particularly common in projects that integrate existing technologies.
At first glance, some may look like straightforward integration projects. However, getting the different components to work together can require complex solutions and substantial new development. Integration does not always mean simply connecting things: limitations may emerge that do not affect the individual components, or performance requirements may demand new solutions.
Unless that work is explained, the project can appear much simpler than it really is. It also remains unclear whether these difficulties have been taken into account when estimating resources and timescales. Failing to identify the challenges therefore creates a risk both for project delivery and for its assessment. This is not a minor point: “level of technical challenge” and “technical achievability and risk” are explicit sub-criteria under excellence, and each is scored separately.
Proposals that handle this well make it clear what has already been resolved, what remains uncertain and how the partners intend to address it. Connecting each challenge with the development work it requires helps justify the technological ambition and assess whether the approach is feasible.
Demonstrating the product's value and understanding the competition
Technical difficulty is one part of the assessment. The proposal also needs to explain what the customer gains from the development.
Many projects describe each participant's technology in detail, but are less clear about the added value created by combining them. Integration alone does not demonstrate an advantage. The improvement needs to be expressed through KPIs, with a baseline and targets that allow comparison with existing alternatives.
Depending on the product, these indicators might relate to performance, accuracy, time, cost or quality. The important distinction is between checking that the system works and demonstrating the benefit it delivers. Both may be relevant, but getting components to work together does not, on its own, explain why a customer would choose that solution.
This connects directly with competitor analysis. Some proposals claim to have no competitors because no existing product combines all the functions they envisage. Yet there may be companies that already provide some of those functions, hold a significant market share and have the technical and financial resources to expand their offerings.
If integration does not present a significant barrier, a competitor covering only part of the solution could soon compete with the whole product. The analysis therefore needs to consider what would prevent them from doing so and what advantage the proposed solution would retain. Similarly, claims that a product will be better or cheaper need to compare equivalent scope and performance.
Proposals developed with input from potential customers tend to explain that advantage more clearly. Discussions about needs, pricing and purchasing processes help establish demand and build more credible sales forecasts.
Presenting a large market and assuming a share of it leaves many questions unanswered. The proposal needs to explain which customers the partners intend to reach, through which channels, at what price and with what sales capacity. It should also set out what will still need to be done after the project before sales can begin, how much that will cost and how it will be funded.
Social and environmental impacts require the same care: explaining assumptions, providing evidence and distinguishing what the project can achieve from what depends on other factors. This includes possible negative effects and the measures planned to reduce them.
Understanding each partner's motivation
Once the development and target market have been defined, it should be clear why it makes sense for these participants to work together. Their complementary roles should be reflected both in what each contributes and in what each expects to gain.
For businesses, there needs to be an economic motivation. This does not mean that every company must sell the product or take an active role in its commercialisation. They may supply components, provide services or license project results, but they should understand their position in the value chain and how they expect to earn a return on their investment.
Universities and technology centres may pursue research or knowledge transfer objectives, although they may also generate income through licensing or other forms of exploitation. What matters is that the tasks, rights to results and expected benefits fit each organisation's role.
Some consortia explain this relationship very well, making the collaboration feel credible. Others describe the participants' capabilities but leave their longer-term motivation unclear. The financial forecasts should help clarify this by showing how each partner's investment, costs and expected income relate to one another.
Planning the work and validation
All of this needs to translate into a work plan that sets out responsibilities, dependencies between tasks and the resources required. The technical challenges identified should be reflected in the activities, risk management and decisions to be made during development.
Within that plan, the validation approach needs its own justification. Its duration depends on the type of project and how difficult it is to measure the KPIs reliably. Some results can be verified through relatively short tests; others require sufficient data, longer observation periods or testing under different conditions.
The proposal therefore needs to explain what will be measured, how and with what resources. If testing depends on users, data or external processes, those dependencies should be reflected in the schedule, along with enough time to analyse the results and make adjustments.
Milestones are useful when they support decisions about the development. Beyond recording that a report has been delivered or a task completed, they should show what result is expected and what will happen if it is not achieved. Linking indicators to thresholds and go/no-go decisions makes it easier to understand how uncertainty will be managed.
The budget, in turn, needs to reflect that work. Staff effort, equipment and subcontracting should be justified and consistent with the planned activities, including validation.
Using the annex to explain the project more clearly
Eurostars allows applicants to submit an optional technical annex to complement the application form with figures, tables and diagrams. This is useful given the application's word limits and formatting constraints: the necessary information should appear in the relevant sections, while the annex can expand on it and make it easier to understand.
I have seen proposals make very good use of this space. A diagram can explain the solution and the partners' contributions; top-down and bottom-up market analyses can be supported by sources, assumptions and calculations; and financial forecasts can be presented in a way that makes the relationship between sales, costs, investment and returns easier to follow.
For this to work, clear references from the main application are essential. Pointing to the relevant section, figure or table allows the evaluator to consult the evidence while following the argument, without having to search through the whole document.
Some projects use this approach to explain clearly what would be difficult to convey through text alone. Others barely take advantage of it. Preparing the annex alongside the main application helps identify what needs a written explanation and what would be better understood through a diagram, a comparison or a table of data.