European Grant Matching API

What we delivered

We delivered the final grant matching API for a startup building a product that helps companies find relevant European grants. The engagement combined software implementation with consulting, taxonomy research, and product recommendations.

The startup already had a working MVP. Its next challenge was to develop the matching capability for a larger scale without carrying forward an implementation that was expensive to maintain. Match quality also mattered. Too many false positives would burden users with irrelevant opportunities, while false negatives could hide grants worth considering.

This was not a request to add a standard search endpoint. The startup needed to decide how its domain knowledge should be represented before it could rely on the resulting scores. The project therefore covered both the matching software and the research needed to choose the taxonomy behind it.

Why grant matching is more than keyword search

Companies and grant programmes often describe related work using different vocabulary and in different languages. Multilingual matching therefore requires more than translating a list of terms. Synonyms help, but they do not resolve the whole problem. The structure of the taxonomy determines which ideas are treated as related, while the granularity of each category changes which distinctions the system can preserve.

Some decisions were inherently domain-specific. Should object recognition and motion tracking belong to one broader group, or should they remain separate concepts? Which parts of a grant document contain useful matching evidence? How much should one decisive concept influence the score when many weaker terms also appear?

A match could contain most of the expected vocabulary and still be wrong because one or two critical concepts were absent. The reverse was also possible. A large number of generic terms could create a superficially strong score without adding useful evidence. The matching logic therefore had to give decisive concepts enough influence while preventing noisy keywords from dominating the result.

Researching and iterating the taxonomy

We compared several taxonomies available through public research and modified existing structures. We also developed custom alternatives where the available groupings did not represent the decision well enough. The work covered:

• hierarchical categories and the boundaries between related concepts.
• multilingual synonyms and mappings between different expressions of the same idea.
• weights for decisive and supporting keywords.
• the relative importance of concepts extracted from different grant sections.
• the effect of taxonomy changes on both missed opportunities and irrelevant recommendations.

The grant taxonomy alternatives were not treated as interchangeable data files. Changing the hierarchy, a synonym map, or a keyword weight could alter which grant appeared relevant. We examined those effects and gave the client recommendations about the trade-offs between candidate approaches.

This work led from several possible taxonomies to the approach selected for the final API. Each iteration informed changes to both the knowledge structure and the matching logic rather than remaining a separate theoretical exercise.

Evaluation with the client’s domain expert

We evaluated successive approaches on test data with a subject-matter expert employed by the startup. The expert brought grant-domain knowledge; our role was to turn that feedback into changes to the taxonomy and technical implementation.

The review focused on whether a taxonomy produced useful distinctions, represented critical concepts, and avoided recommendations driven mainly by noisy terms. This evaluation exposed cases where many keywords looked correct but one or two decisive concepts were missing. It also revealed when broad vocabulary contributed little to the quality of a match.

The project did not establish a public production-accuracy or grant-success metric. Its evaluation basis was the test data and the client’s expert review. The supported result is therefore the delivery of an expert-reviewed matching approach and API, not a claim about funding won by end users.

From research to a usable API

The final deliverable was a Python and FastAPI service combining multilingual taxonomy processing, weighted matching, machine learning, and natural-language processing. Python and FastAPI matter here because the research was translated into an API the startup could use in its product, rather than ending as a taxonomy report or isolated experiment.

Alongside the API, we delivered the research and recommendations behind the selected logic. The client received both the implemented result and a record of the choices considered while comparing category structures, synonyms, important concepts, and document sections.

The engagement moved the startup from an MVP and several competing taxonomy ideas to a selected matching approach embodied in the final API. It also gave the product team a clearer basis for future decisions about the matching model. For organizations facing a similar problem, the relevant starting point is not a preferred algorithm. It is a representative test set, access to domain judgment, and a clear definition of what makes a recommendation useful.

Explore the grant-technology context or the custom algorithm development approach.