Can I Get Public Funding for My Software Project?
TL;DR – Summary
Software and AI projects can also be funded through the Forschungszulage – what matters is that the project involves innovation with technical uncertainty, not routine development. The application must clearly describe novelty, technical risks, and a planned solution approach. External contractors/freelancers can partially be included – but only under certain conditions. Many companies leave money on the table because they incorrectly assume software is "not eligible" or fail to clearly delineate the innovation core.
Software is no longer just "implementation" – it is often the core of genuine technological innovation, for example in new algorithms, complex system architectures, or AI-driven processes. Yet applications for the Forschungszulage in the software domain fail at an above-average rate, because projects are described too close to routine development or risks and novelty are not presented in a tangible way.
This post gives you a compact overview of what can be eligible, where the typical pitfalls lie, and how to document software innovation so that it becomes comprehensible in the Bescheinigung review.
Forschungszulage: Why It Is So Attractive for Software Teams
The Forschungszulage is one of the best options for many software companies because it:
- applies broadly (not only to "classical" industry),
- can address innovations in digital products, platforms, and systems,
- and is particularly interesting when you are continuously working on demanding technical topics.
Important: this is not about "research for research's sake", but about innovation with technical risk – meaning projects where the outcome is not certain.
You can find more background on dieforschungszulage.de (initial assessment & first consultation).
Is Software Development Eligible at All?
Yes – software projects can be eligible if they go beyond standard development and venture into technological new territory. What matters is not whether you are building "SaaS" or "an app", but what is technically new and uncertain about it.
In practice, the challenge is that software is intangible. That is why the application must explain particularly clearly:
- What exactly is the innovation?
- Why is it non-trivial?
- What could cause the implementation to fail (technical uncertainty)?
- How do you proceed systematically – through to the prototype?
The 4 Success Factors for Software Projects (How the Review Thinks)
1) Clear Delineation: Innovation vs. Routine Development
Typically not eligible are activities such as:
- pure customization programming,
- migrations (e.g. on-premise to cloud) without a new technical approach,
- porting, standard integrations, configurations,
- debugging, pure documentation, maintenance/support.
It becomes eligible when you, for example:
- use new methods or newly combine existing methods,
- measurably achieve something new in technical parameters (e.g. latency, scalability, accuracy, robustness),
- enable functionality that cannot be achieved with the current state of the art.
Practical tip from dieforschungszulage.de: Do not phrase it as "We are developing a new feature", but as: "We are solving a technological problem for which no established standard solution exists."
2) Both the Goal and the Solution Approach Must Be Novel (Not Just the Product)
A common mistake: the product goal is new (for your company), but the solution approach is standard (for the market). It only becomes eligible when your project demonstrates:
- new technical approaches, or
- a new combination of proven approaches that leads to a recognizably new technical path.
The key question:
- Where are we entering technological new territory?
3) Name Technical Risks Precisely (No Buzzwords)
In software projects, risks are often formulated too broadly ("complexity", "AI hallucinates", "algorithms are new"). Better practice is:
- describe risks along the solution path,
- concretize them with target parameters (e.g. response times, error rates, throughput, memory requirements, stability under load, prediction confidence).
Examples of good risk categories (depending on the project):
- Real-time / latency criteria
- Scalability & system complexity
- Reliability / prediction confidence (e.g. in AI-assisted decisions)
- Conflicting optimization targets (e.g. accuracy vs. performance)
4) Systematic Approach: Explaining Scrum Is Not Enough
Agile methods are normal in development – but for the Forschungszulage you additionally need:
- an understandable work plan with work packages,
- a clear logic showing how you reduce uncertainty step by step,
- and a defined project endpoint, often: first functional prototype.
Important: typically eligible are the steps up to the prototype, not regular operations, rollout, maintenance, or routine improvements.
What About External Contractors and Freelancers?
Many software companies work with agencies or freelancers. In principle, such engagements can be eligible for inclusion – but there are restrictions, for example regarding the place of establishment of the contractor (EU) and the nature of the cost allocation.
If a significant portion of your development is done externally, it is worth structuring the collaboration carefully (service descriptions, allocation to work packages, evidence of innovation-related activities).
How dieforschungszulage.de Supports Software Projects
We support you with the following:
- Higher eligible costs: We help you identify eligible expenses cleanly, delineate them correctly, and document them completely – so that you do not leave anything on the table that is genuinely eligible in your project.
- Less internal effort: Instead of spending weeks refining wording, delineations, and documentation logic, you get a clear structure, fast decisions, and a robust application narrative.
- Significantly higher success rate: With professional support, the probability of success rises noticeably – from 75% to 92%.
If you want a quick initial assessment, also take a look at our reference projects.