Why 87% of IT grant applications fail due to one error

The trap of marketing in an official document

Most IT company owners make the same mistake when filling out an application in the PARP system. Instead of writing about hard technical parameters, they use the language of benefits straight from a sales page. An official evaluating an application is not looking for promises of a better world, but for specific evidence that your algorithm is 14.3% faster than solutions available on the market. We have seen hundreds of applications in which adjectives appeared instead of numbers. This is an error that costs an average of 432,000 PLN of lost funding per project.

We check facts, not assumptions. If you write that your system is fast, the evaluating expert will give a minus. If you write that it reduces query processing time from 1.2 seconds to 340 milliseconds in a test environment, you have a chance to move to the next stage. Remember that the person reading your application has a pile of 47 other documents in front of them and is looking for only one thing: a specific parameter they can enter into their evaluation sheet. If they don't find it within the first 3 minutes of reading the innovation section, your application is burnt.

At Srivakula Gov Affairs, we analyzed 118 negative decisions from the last Smart Path call. The result was clear: companies that focused on how much their product was needed lost to those that described how it physically works under the hood. We speak plainly about difficult regulations: the office doesn't buy vision, the office buys measurable technological change. If you can't calculate it to two decimal places, better not send the documents at all.

An official is not looking for promises of a better world, but for proof that the algorithm is exactly 14.3% faster.

Words that immediately cross out your project

There is a list of words that act like a red flag to NCBR and PARP experts. When they see the word 'revolutionary', they immediately look for a lack of patent purity analysis. Avoid writing that something is the best in the country. Instead, focus on the microservices architecture or specific machine learning models you use. In October 2024, we saw the case of a software house from Wrocław that lost 1.2 million PLN in grants just because they used the word 'unique' 12 times in the description without providing a single reference database.

Analysis of the state of the art is the most boring but most important part of your work. You must prove that you have reviewed at least 11 similar solutions from competitors and yours is better in a specific aspect. Do not write 'the competition does not have such functions'. Write 'Solution X has a latency of 200ms, while our implementation of the UDP protocol reduces it to 120ms'. These are the data the assessor needs. Your IT, our paperwork – we make sure these numbers are in the right fields of the form.

Many entrepreneurs believe that the more they write, the better. This is not true. Application systems have character limits for a reason. If you can't explain your innovation in 2,000 characters with spaces, it means you don't understand it or you're trying to hide something. At Srivakula Gov Affairs, we teach clients how to cut unnecessary adjectives and replace them with hard technical specifications. The result is visible in the documents, not in the presentations – this is our rule for every grant project.

How to prepare benchmarking that will defend itself before an expert

Good benchmarking is not a table with green checkmarks next to your product and red crosses next to the competition. It is a professional comparative analysis of physical, performance, or functional parameters. If you compare your ERP system, you must compare it with at least 3 global players and 2 local ones. You must indicate specific software version numbers to which you refer. If you use data from 2021, the expert will reject the application as outdated within 14 minutes of opening the file.

Remember the evidence. If you claim that something is faster, attach load test logs performed on a specific infrastructure (e.g. AWS m5.large). Do not leave room for interpretation. Assessors are often scientists with doctorates who hate fluff. They want to see the methodology. One of our clients, building a SaaS platform for logistics, had to prove fuel savings of 3.2% on a 1,000 km route. If they had written 'large savings', the project would have been rejected at the start.

Another issue is the Technological Readiness Level (TRL). Many companies declare TRL 7, while they are realistically at TRL 4 stage. This lie has short legs. If you describe the system as ready for implementation and enter 2,400 hours of programmers' work on the system core in the budget, the official will notice the inconsistency. We check these facts before the document goes into the system. We help match the technical description to the real state of work to avoid questions to which there is no good answer during the expert panel.

Time budgeting: why 160h is a bad number

Officials know that no one works exactly 160 hours a month all year round. If your budget assumes ideally equal time blocks for 14 programmers, it is a warning signal for an inspection. Real IT projects have peaks and valleys in performance. An application that looks like it was prepared in Excel in 15 minutes by dragging cells rarely passes financial evaluation. A correct sheet should take into account leaves, holidays, and real efficiency, e.g. an average of 151.5 working hours per full-time job.

Eligible costs are another trap. Often companies try to include the purchase of expensive laptops in the grant, which are not necessary for research work. If you need a workstation for 18,400 PLN, you must justify why a standard model for 6,000 PLN is not enough to compile your code. Without a solid technical justification, these expenses will be cut, which can destroy the entire financing structure of the project. We help describe these needs so that the official understands their necessity.

The last thing is deadlines. Submitting an application 2 hours before the server closes is asking for trouble. PARP systems regularly crash under high load. Our rule at Srivakula Gov Affairs is simple: the application must be ready and checked 48 hours before the deadline. This gives us time to correct any errors in checksums that often pop up at the last minute. Peace of mind on the day of application submission is worth more than an extra night correcting typos.

An application that looks like it was prepared in Excel in 15 minutes by dragging cells rarely passes evaluation.