You don't need a grant for a website. You need a project that will actually change your company

The cover image of this article was generated by AI (Gemini 3 Pro Image model on the FOTOhub.app platform). Labelled in accordance with Article 50 of the AI Act.

Polish companies today have access to digitalization funding that simply did not exist just a few years ago. You can secure a grant that covers part of your software costs, take out a preferential loan for a larger transformation, get co-funding for AI training, or start with an audit and a roadmap prepared with the help of a European Digital Innovation Hub. It sounds great. The problem is that finding a program does not answer the most important question: what exactly should the company digitalize so that two years from now it is not left with an expensive system nobody uses.

That is exactly why I don't treat funding as the goal. Funding is a financial tool. The goal has to be a concrete business outcome: faster order handling, less manual retyping of data, fewer errors, quicker quoting, better production control, automated reporting, a more secure document workflow, or a sales process that doesn't end in one employee's inbox.

This distinction matters because public programs don't fund technology for its own sake. They fund change. If a project starts with the sentence "we want to buy a system," it is usually still too early to write an application. First, you need to be able to say which process isn't working today, how much that problem costs, and how you will know that the implementation actually solved it.

Poland is digitalizing fast, but still superficially

According to the European Commission's 2025 report, 68.95% of Polish SMEs reached at least a basic level of digital intensity. That is major progress, but still below the EU average of 72.91%. The gap is even wider for advanced technologies. In 2024, 5.9% of Polish enterprises used AI, while the EU average was 13.48%. Among SMEs alone, the Polish figure dropped to 4.92%, while among large enterprises it reached 32.95%.

These numbers show clearly where we really stand. In many companies, digitalization already means cloud email, a website, PDF invoices, and a few SaaS subscriptions. But that is not yet digital transformation. Transformation begins when systems exchange data without manual copying, a process can be measured from start to finish, and technology changes the way work is done instead of simply moving the same mess from paper to a computer.

At the same time, readiness to invest is growing. The report "Cyfrowy puls polskich MŚP 2026" (The Digital Pulse of Polish SMEs 2026) found that only 12% of the Polish companies surveyed had no plans for digitalization. The report's authors also identify AI, implementation barriers, and expectations toward vendors as some of the main areas of SME investment decisions. The market no longer needs another presentation explaining that "AI will change business." It needs people who can translate that slogan into scope, architecture, budget, timeline, and measurable impact.

Funding can accelerate this change. It will not, however, fix a poorly prepared project. If a company doesn't know which data is reliable, who owns the process, how the system should connect to the ERP, or which decisions AI is allowed to make, an additional budget will only make it possible to make a bigger mistake.

Three kinds of money, three different mechanisms

The biggest mistake in conversations about funding digitalization is throwing everything into a bag labeled "grant." A grant, a preferential loan, and training co-funding work differently. They affect cash flow differently, they are settled differently, and they require different kinds of projects.

Dig.IT: reimbursement of part of the cost of a real transformation

The Dig.IT program was designed for micro, small, and medium-sized companies in manufacturing and production services. The published terms of the second edition specified grants ranging from PLN 150,000 to PLN 850,000 and co-funding of up to 50% of net eligible costs. The project must concern production processes, production services, or processes that directly support them, such as warehousing, quality control, sales, or internal transport. Supported areas include software, automation, analytics, cloud, AI, machine learning, and cybersecurity, among others.

So this is not a simple program "for buying laptops" or "for a new website." The core of the project must be a change based on a digital solution. Hardware and training can support the implementation, but they should not replace a meaningful technology project.

The pilot call received 146 applications. Of the 143 that were evaluated, 51 received a positive score, while 92 were rejected at the formal or merit-based stage. The final value of funding for the recommended projects exceeded PLN 21.6 million. That is an important signal. Simply meeting the SME definition and putting the word "digitalization" in the title is not enough. The project has to hold up from a business, technical, and financial standpoint.

With a grant, the company should also be prepared to finance expenses before they are reimbursed. In practice, this means planning for its own funds, a bank loan, a lease, or another source of liquidity. "50% co-funding" does not mean that the contractor will deliver half of the project for free. It means that, after proper implementation and settlement, part of the eligible costs may be reimbursed in accordance with the program's terms.

For example, a project worth PLN 400,000 net may, at the maximum support intensity and with full cost eligibility, lead to a reimbursement of up to PLN 200,000. This is, however, an illustrative model, not a promise. The final amount of support depends on, among other things, the program rules, the de minimis aid limit, the company's situation, the scope of costs, and the evaluation result.

The PARP loan fund: a bigger project, cheap capital, and a conditional grant

The second instrument is the Loan Fund for the Digital and Green Transformation of Enterprises. PARP (the Polish Agency for Enterprise Development) announced that the total value of European funds allocated to the instrument is PLN 792 million, and that in the first tranche, financing partners are to make PLN 500 million available to businesses. The program is aimed at micro, small, medium-sized, and large companies from all over Poland.

The loan can range from PLN 2.5 million to PLN 15 million. In the preferential variant, the interest rate is 0.5% per year, the repayment period can be up to 15 years, and the grace period on principal repayment is 24 months. The instrument also provides for a conditional grant toward repaying part of the principal, which may amount to 5%, 10%, or 15% of the investment costs, depending on the type of project and its location.

This is a solution for larger investments, where a company needs money to carry out the project rather than a reimbursement once it is finished. Financing can cover, among other things, ERP, MES, SCADA, systems integration, AI, the Internet of Things, data analytics, cloud, cybersecurity, automation, and robotics. A project can also combine digitalization with environmental goals, such as reducing energy or raw material consumption.

Here, too, technology cannot be a random shopping list. An investment worth several million zlotys requires a business plan, a coherent scope, a benefits model, a financial analysis, a solution architecture, and a set of indicators that can be proven later. The bigger the project, the more expensive vague requirements become. A mistake made in a PLN 5,000 specification can turn into a change costing hundreds of thousands once a tender is launched or a contract is signed.

KFS: people first, then tools

The third mechanism is the National Training Fund (KFS). In 2026, the development of digital skills, including skills related to the use of artificial intelligence, is among the fund's spending priorities.

The new rules provide for funding of up to 90% of costs for entities with no employees or up to nine employees, and up to 70% for all other entities. The limit per participant cannot exceed 200% of the average salary in a given year. Starting in 2026, training can only be delivered by a provider registered in the Development Services Database (BUR), and applications are submitted electronically via praca.gov.pl to the competent county labor office.

KFS matters because many digital projects don't fail because of bad code. They fail because the team doesn't understand the new process, doesn't trust the automation, doesn't know how to verify an AI model's answers, or goes back to the old Excel spreadsheet at the first sign of trouble. You can implement an excellent system and still achieve no results if people don't change the way they work.

That is why training should not be a two-day showcase of dozens of tools. It should be part of the implementation. The team needs to learn to work on its own cases, its own documents, and its own procedures. Otherwise, the company is paying for an interesting presentation, not for a skill.

What is actually worth digitalizing

The best digitalization project rarely starts with choosing a technology. It starts with a process in which the company regularly loses time or money.

A good candidate is a process that is repetitive, measurable, and frequent enough. If employees retype data from emails into the ERP every day, compare documents by hand, produce the same reports, assemble quotes from five different files, or answer similar customer questions, there is real room for automation. If a problem occurs once a quarter and looks different every time, building a dedicated system may never pay off.

In practice, I see the greatest potential in a few classes of projects. The first is custom software that replaces spreadsheets, messages, and manually maintained registers. This could be an operations dashboard, a customer portal, a job workflow system, a quote configurator, an app for sales reps, a quality control tool, or a system that handles a specific production process.

The second class is integrations. In many companies, the ERP, CRM, online store, warehouse, accounting, and production systems exist side by side, but they don't form a single environment. Data is exported to CSV, sent by email, and imported by yet another employee. API integration is not spectacular in a presentation, but it often delivers a bigger impact than buying another system. It eliminates delays, errors, and situations where the company doesn't know which version of the data is current.

The third class is automation and AI agents. This is not about adding a chatbot to a website. It is about a system that can receive a document, classify it, extract data, compare it against a database, prepare a proposed action, and hand over cases that require a decision to a human. In a well-designed process, AI doesn't pretend to be an infallible expert. It operates within defined boundaries, leaves an audit trail, works within its permissions, and knows when it should stop.

The fourth class is analytics and reporting. A company often has data but no answers. A report takes several days to produce, everyone calculates the metric differently, and management receives the information too late. A well-built data layer and management dashboard can bring sales, costs, production, inventory, and quality together into a single model. Only on such a foundation does it make sense to add forecasting or generative AI.

The fifth class is cybersecurity and operational resilience. Digitalization without backups, access management, event logs, updates, and incident response procedures increases a company's dependence on technology, but not its security. The more processes move into systems, the less cybersecurity is a separate project. It becomes a requirement of every project.

The sixth class is digital sales and B2B customer service. A website on its own is usually not a transformation. A portal that lets a customer configure a product, see individual pricing, place an order, download documents, track fulfillment, and file a complaint can change the entire sales process. The difference is not in how the interface looks. It is in what happens to the data after the button is clicked.

Don't buy a system. Buy an outcome

A funding application forces you to describe costs, scope, and indicators. This is not a bureaucratic add-on. It is a test of whether the company knows why it is carrying out the project.

Instead of writing "CRM system implementation," it is better to describe what will change after implementation: all inquiries will be logged automatically, the sales rep will receive the contact history and a task, the quote will be generated from the current price list, and management will see the conversion rate at every stage. Instead of "AI implementation," it is worth writing that the system will classify documents of specified types, extract designated fields, flag the confidence level, and route ambiguous cases to an operator.

A good specification should answer at least the following questions, even if they are not written down as a list in the application. Which process does the project cover? Who owns it? What does the current state look like? Where do errors occur? Which systems are already in place? What data will be needed? Who can read and change it? What needs to be integrated? What result will be measurable? How will the solution be maintained after the funding period ends?

It is at this stage that the success of the entire undertaking is most often decided. Code can be fixed. A poorly defined goal cannot be fixed with another sprint.

The most expensive grant is the one spent on the wrong project

Funding changes the psychology of buying. The company starts looking at the maximum amount available instead of the minimum scope needed to achieve the result. Modules appear "because they can be included," hardware "because it is eligible," and features nobody needed before.

This is a straight path to a system that is large, costly, and difficult to maintain. A grant covers only part of the price. The full cost of a bad decision stays with the company: its own contribution, employee time, data migration, training, delays, maintenance, and the cost of going back to the old process when the new tool doesn't work.

That is why, before starting a project, it is worth calculating not only the investment budget but also the total cost of ownership. Licenses, cloud infrastructure, AI model APIs, monitoring, integration maintenance, security patches, backups, and further development after process changes do not disappear once the eligibility period ends.

You also need to be careful about declaring results that cannot be demonstrated later. If the application states a specific time saving, a number of automated processes, or an increase in productivity, the system should make it possible to measure those effects. Otherwise, the company may have working software but a problem documenting that the goal was achieved.

Five ways to lose money before the first line of code

The first is starting the project too early. Eligibility rules depend on the specific instrument, so the program rules need to be checked before signing a contract, placing a binding order, or paying an advance. An action taken before the right moment may cause an expense to be deemed ineligible.

The second is choosing a contractor "on their word." If the project is subject to the competitiveness principle, the procurement must be carried out in accordance with the program's requirements, and notices are published in the Competitiveness Database (Baza Konkurencyjności). The database is used both to publish procurement procedures and to document their outcomes. A good relationship with a contractor is no substitute for the proper procedure.

The third is a vague specification. "An AI-based system for automating the company" says practically nothing. It is unclear what data the system takes in, what operations it performs, where the model's responsibility ends, what the level of integration is, and when a stage can be considered accepted. The more general the description before a contractor is selected, the bigger the conflict at acceptance.

The fourth is confusing digitalization with a purchase. Buying licenses can be part of a project, but a license alone does not change a process. Someone has to design the configuration, data migration, integrations, roles, permissions, procedures, and training. Without that, the company is buying access to possibilities, not an outcome.

The fifth is having no plan for after implementation. The system will require updates, user support, changes on the API side, monitoring, and incident response. Grant-funded projects also carry an obligation to maintain the results for the period specified in the documentation. If the cost of support doesn't fit the company's business model, the project is poorly planned, regardless of the amount of funding.

An audit before a grant may be worth more than the grant itself

A company that is not yet ready for a large project doesn't have to start with a big application. European Digital Innovation Hubs act as one-stop shops and help businesses assess their digital maturity, prepare a transformation plan, test solutions before investing, and draw on experts, laboratories, and training.

That is a very sensible starting point. An audit should show not only what the company is missing, but also what is not worth implementing right now. Sometimes the first step is to clean up data dictionaries. Sometimes it is to build an API for an existing system. Sometimes it is to change who is responsible for what in a process. And sometimes, instead of a million-zloty project, a well-executed integration at a fraction of that cost is enough.

EDIHs use tools for a systematic assessment of digital maturity before support and at subsequent measurement points, which makes it possible to compare the company's condition and the effects of the transformation over time. An audit report alone, however, will not implement change. The recommendations still need to be turned into a backlog, an architecture, a budget, and a sequence of work.

How I prepare a project before the application is written

I don't start with a grant application form. I start with a conversation about the company. I want to see how information flows today, where employees perform the same operation several times, which decisions wait on a single person, and what data exists only in private spreadsheets.

Next, I separate the business problem from the idea for a solution. A client may come in needing to "implement AI," and after analysis it turns out that the greatest value will come from integrating the ERP with the warehouse and streamlining the document workflow. It can also be the other way around: the process works correctly, but its scale means that document classification and an agent working on a controlled dataset deliver a real return.

On this basis, I prepare a technical concept. I describe the scope, modules, integrations, data model, user roles, security requirements, stages, acceptance criteria, timeline, budget, and indicators. This document is meant to be useful regardless of whether it goes to a grant consultant, the management board, a financing institution, or potential contractors.

If the company is applying with a consultant, I prepare the technical part in a form that can be used in the application documentation. I don't guarantee that funding will be granted, because the decision is made by the institution running the call. Nor do I call every cost eligible before it has been checked against the current program rules. My responsibility is to make sure the technical part of the project is concrete, feasible, and capable of being accepted. If the implementation goes ahead, I deliver it in stages. Each stage ends with a defined result and acceptance documentation. Scope changes are logged, and the architecture cannot be a black box dependent on a single person.

Once the work is complete, I prepare the technical documents needed for settlement on the contractor's side: descriptions of the delivered features, acceptance reports, a change log, and a summary of the stages. I don't replace the accountant or the grant consultant, but I don't leave the client with an invoice and the sentence "the system works." In a project financed with public funds, a working solution is only part of the success. The other part is being able to prove what was actually delivered.

What I can do as part of your company's digitalization

I build custom software that replaces spreadsheets, manual registers, and processes that depend on email inboxes. I build operations dashboards, customer portals, case management systems, configurators, reporting tools, B2B platforms, and applications tailored to a specific process. I don't try to force an off-the-shelf product where the company has unusual operational logic.

I connect existing systems through APIs. ERP, CRM, online store, warehouse, accounting, payments, KSeF (Poland's National e-Invoicing System), production systems, and external suppliers don't have to function as separate islands. If an integration can eliminate the daily copying of data, it is usually one of the first elements worth costing out.

I implement automation and AI agents in processes where they have a clearly defined role. They can analyze documents, draft responses, classify requests, create draft quotes, check data for completeness, or trigger subsequent operations in other systems. In doing so, I design validation, logs, permission levels, and an escalation path to a human. An agent without controls can make an impressive demo. A business needs an accountable system.

I help companies prepare for KSeF, design integrations, automate document flow, and build middleware layers where the standard ERP module is not enough. In cybersecurity, I can carry out a technical analysis and implement basic safeguards related to access, backups, monitoring, and application protection, and for projects that require a formal audit or certification, the appropriate specialist partner is brought in.

I also run training on the practical use of AI, automation, and digital tools. If the training is to be funded by KFS, the provider must meet the program's requirements, including registration in BUR. That is why such a project requires prior confirmation of the partner and the terms of the specific call. I don't sell the fiction that any workshop can simply be "put under funding."

I also provide post-implementation support. This includes maintenance, monitoring, updates, user support, and further development of the system. This is especially important when a project must maintain its results for the durability period. A business system is not a brochure website you can hand over and forget. Integrations, regulations, data, AI models, and the way the company works all change.

I don't sell grants. I build a project that can benefit from one

This distinction is fundamental to me. I don't "get you the money," and I don't promise a positive decision. I can assess the project's initial fit, help choose a funding direction, prepare its technical part, and work with the consultant responsible for the application. I can also bid in a properly conducted contractor selection procedure. If a competitive procedure applies, the client cannot guarantee me the contract just because we prepared the concept together.

This kind of honesty is important for the client as well. The promise of "a grant for everything" sounds good until the first audit. A professional project assumes that every feature, cost, invoice, stage, and report has a logical place in the overall undertaking.

The first stage of cooperation may cover a diagnosis and a technical concept. The document stays with the company even if the call is postponed, the funding is not awarded, or the board decides to implement the solution in stages without a grant. A good concept is not a text written solely for one form. It is a plan for a technology investment.

I have many years of experience designing and delivering systems, integrations, automation, and AI-powered solutions. I work without the heavy structure of a typical software house, which lets me retain direct technical responsibility and keep delivery costs competitive. The client doesn't talk to a salesperson who passes the requirements on to a third party. They talk to the person who designs the architecture and takes part in building it.

That doesn't mean one person does everything. Where a project requires a grant consultant, an auditor, a BUR partner, a lawyer, a cybersecurity specialist, or a specific certification, the scope is divided according to expertise. The difference is that the technology is not described by a random chain of intermediaries.

Where to start

Don't start by asking "how much can we get." Start by asking "which process is holding the company back the most today." Bring together the people who actually do this work. Write down the successive steps, the systems used, the manual operations, exceptions, delays, and errors. Measure the scale of the problem over a month, not on the basis of one perfect day.

Then check whether the company meets the conditions of a specific instrument: company size, industry, PKD (Polish Classification of Activities) code, time in business, location, financial results, aid limits, and deadlines. With Dig.IT, you need to pay particular attention to the business profile and the scope of the process. With the PARP loan, the investment scale starts at PLN 2.5 million, so you need a project of the right size and the financial capacity to carry it. With KFS, the deadline and the availability of funds depend on the competent labor office.

Next, prepare a minimum and a target version. The minimum version should deliver a business result on its own. The target version can include extensions that make sense once data and processes have been put in order. This split reduces the risk of building a large system before its key assumptions have been tested.

Finally, plan the financing for the entire cycle. Funding does not eliminate VAT, ineligible costs, maintenance, or the risk of a delayed reimbursement. A preferential loan is still a liability that has to be repaid. Training will not replace implementation. An audit will not replace a decision. Each instrument solves a different part of the problem.

The money is available. Good projects are still in short supply

In 2026, there is no shortage of instruments supporting digitalization. PARP has launched a fund with a total value of PLN 792 million for large digital and green investments. Dig.IT offers specialized SMEs an opportunity to recover part of their transformation costs, but the outcome of the pilot showed that the selection is real. KFS makes it possible to significantly reduce the cost of developing digital and AI skills. EDIHs help assess a company's maturity and test a direction before investing.

The biggest constraint, however, is not the lack of yet another program. It is the lack of a well-prepared project. Companies often know they want to digitalize, but they don't have a documented process, architecture, indicators, budget, or maintenance plan. And that is exactly the gap that can be closed before a call opens, or before the board signs a contract for a system it doesn't need.

If you want to find out whether your company has a project that could qualify for funding, let's start with a short conversation. We will review your company profile, the business problem, the scale of investment, and a possible support mechanism. If the idea is too small, too early, or doesn't fit the program, I will tell you so directly. If it makes sense, I will prepare the technical concept, budget, stages, indicators, and documentation needed for further work on the application.

I can then deliver the software, integrations, automation, AI solutions, KSeF, an operations dashboard, a B2B platform, or any other element of the transformation. In procedures that require a competitive selection of the contractor, I will submit an offer on the same terms as everyone else. After implementation, I will provide the acceptance documentation and technical support needed to maintain the results.

I don't promise grants. I promise that the technology project will be described in a way that makes it clear what we are building, why we are doing it, how much it costs, and how we will verify the result. In digitalization, that is worth far more than another form full of buzzwords.

Let's find out whether your company has a project worth funding. Book a free consultation or send a short description of your process using the form at mateuszulewicz.pl/dofinansowanie.

Information current as of September 28, 2026. Terms, deadlines, and cost eligibility must always be confirmed in the current program rules and with the institution running the call. Funding decisions are not made by the project contractor.