An applied research project rarely ends in scientific failure. It often ends with a server being switched off.
The final report is filed, the paper is published, the method is validated, the prototype has demonstrated its relevance on a pilot site. Then the funding stops. The PhD student who maintained the code defends their thesis and leaves. The domain name expires. Eighteen months later, the tool that was meant to serve the agricultural services of a partner country is no longer accessible, and the ministry that was waiting for it starts looking for funding to rebuild it.
This sequence is not an exception. It is the default exit route for a large share of applied research projects on climate, health or agriculture. And it cannot be explained by a lack of rigour: it can be explained by the fact that no one, in the initial design, had the job of keeping the result alive after the project ended.
The real break is not between science and application, it is between project and service
The gap between research and operations is often described as a technology maturity problem: you simply need to "move up the TRL scale". That reading is incomplete.
The break is first and foremost institutional. A research project has a duration, an earmarked budget, governance by work packages and an obligation to produce science. An operational service, by contrast, presupposes indefinite continuity, on-call support, up-to-date documentation, backward-compatible interfaces, and an obligation of results towards a user who is not a party to the consortium.
These are two different regimes. Moving from one to the other is not a matter of extra effort from the research team: it requires a change of actor.
The useful question at the design stage is not "how will we valorize the results?" but "who, by name, will operate the deliverable three years after closure, and with what resources?". If the answer is a laboratory, the answer is fragile.
Why a laboratory cannot — and should not — carry everything
Asking a research unit to operate a tool over the long term means asking it to take on a burden for which it has neither the mandate, nor the funding model, nor the evaluation indicators.
Three structural constraints come up systematically:
- Human resources are tied to the project. Research contracts are time-bound; the skills leave with the person.
- Academic evaluation does not reward maintenance. A security patch or an API update produces neither publication nor citation.
- The contractual commitments expected by funders belong to another profession. An institutional funder requires dated deliverables, financial reporting, availability guarantees, sometimes liability clauses. These are corporate commitments.
This observation is not a criticism of laboratories. It is an argument for them to focus on what they do better than anyone else — producing and validating knowledge — and to rely, within the consortium, on a partner whose business it is to carry what comes next.
What a private partner concretely carries within a consortium
In programmes run with the World Bank, AFD, UNDP, IRD or Météo-France, our role is not to "do research alongside the researchers". It is to take on the tasks that the academic set-up cannot absorb:
- Industrialize. Move from a laboratory script to a documented, versioned, tested and reproducible processing chain.
- Deploy. Install, host, secure, monitor, restore. Work with the real-world constraints of partner technical services, including where connectivity is limited.
- Operate. Ensure day-to-day functioning, manage incidents, update dependencies, maintain compatibility with upstream data sources.
- Report. Produce the technical and financial reporting expected by the funder, in its formats and to its deadlines.
- Transfer. Train local teams, document in the working language, organize handover to the host institution when that is the programme's objective.
This is the same logic we apply to our vulnerability assessment and adaptation planning activities: an assessment only has value if it becomes a decision, and a decision only exists if someone follows it up year after year.
A recurring point of attention: intellectual property and operating conditions must be dealt with at the design stage, not at closure. Who owns the code, the derived data, the trained models? Under what licence? With what exclusivity and what duration? Negotiations launched in the final months of a project rarely result in a workable arrangement.
From laboratory to business: supporting a spin-off without distorting it
Some research results are not meant to become a public service: they have a market. Creating a spin-off is then the most robust — and the most demanding — path.
We know this path because we have walked it. Ecoclimasol was born out of public research and, like any young organization, had to answer questions that never arise in a laboratory: what exactly is the scope of what we sell? to whom? at what price? who signs the contract? what happens if the service goes down?
Our support focuses on four concrete areas:
- Operational organization — roles, processes, tooling, the ability to deliver repeatably.
- The MVP — narrowing the scope down to what creates value for one identified first user, rather than carrying every feature imagined during the project.
- Industrializing prototypes — turning a demonstration into a product that can be maintained by a team that did not write the original code.
- Commercial strategy — positioning, first customers, business model, pricing, and skills transfer to the founding team.
On parametric insurance topics, for example, a feasibility study coming out of research only becomes a product after a structuring effort: index definition, data quality and continuity, trigger governance, distribution channel, acceptability for the insured party. It is precisely this continuum, from scientific hypothesis to contractual object, that we equip — in connection with our ClimaVista activity.
A successful spin-off is not judged by its fundraising but by its ability to honour its second contract as well as its first.
Giving results an interface: platforms, visualization, APIs
A research result that cannot be read cannot be used. This is true for a public decision-maker as much as for a farmer, a funder or a journalist.
Climate communication and putting results behind an interface therefore constitute a work package in their own right, not a cosmetic operation at the end of the project. This covers:
- project portals that stay online after closure, with identified hosting and maintenance;
- data visualization that makes uncertainties explicit instead of hiding them;
- documented APIs allowing other systems — meteorological services, ministerial GIS, private operators — to consume the results;
- reporting and outreach materials differentiated by audience: a policy brief for a ministry, a field sheet for an agricultural extension service, a dashboard for a funder.
There is also an institutional credibility dimension. A programme whose results are accessible, cited and reused three years after it ends is a programme that justifies the next round of funding.
What experience with international programmes has taught us
Fifteen years of work alongside laboratories and institutions, in the field in Africa, Latin America, Asia and Europe, with partners such as IRD, the Institut Pasteur, universities, Météo-France and multilateral funders, have brought a few regularities to light.
- Deployment costs more than demonstration. A budget that allocates 90% to scientific production and 10% to commissioning produces a deliverable that cannot be operated.
- Upstream data is the primary source of fragility. A chain that depends on a source with no contract will stop the day that source changes format.
- Ownership is prepared from the first year. Training at closure is training too late.
- Service continuity must be named, budgeted and assigned. Otherwise it will not happen.
Three questions to ask before submitting the proposal
For a research team preparing a response to a call for projects, the most useful exercise comes down to three questions, to be addressed before writing the proposal:
- Who operates the deliverable after closure, and on what budget? If no actor is named, plan for the corresponding work package and partner.
- What commitments will the funder expect, and who can sign them? Availability, deadlines, reporting, liability: these clauses presuppose a private counterpart.
- What is the real target use, and behind what interface? A model without an interface remains a model; a service presupposes an identified user and a channel.
Answering these questions at the design stage does not complicate the project. It changes its outcome.
Building the bridge from the first page of the proposal
Between research and operations there is no technical chasm to cross, but a chain of responsibilities to write down. The private partner is not there to translate science into a product at the end of the journey: it is there, from the design stage, to carry the commitments, the deliverables and the duration.
That is the role we play within consortiums, the support we offer to teams structuring a spin-off, and the function fulfilled by the project platforms we design and maintain.
If you are preparing a proposal, a deployment phase or the project exit of a tool that has already been developed, we can review with you the most suitable arrangement — scope, work packages, intellectual property, operating conditions.