Malta’s Digitalise your SME grant: how to prepare a fundable digitalisation project

If you are looking at Malta’s Digitalise your SME scheme and wondering whether a CRM integration, internal tool, ecommerce system, automation workflow or AI project could fit, the right starting point is not the software.

It is the business problem you are trying to solve. A vague intention to “go digital” is difficult to scope, quote and measure. A clear project is much easier: this process is slow or unreliable today, this is how we want it to work, these systems need to connect, and this is how we will know the investment improved the business.

Digitalise your SME: the short version

The current Call 2 is aimed at micro, small and medium-sized enterprises and provides non-repayable grant support for investments that digitalise business operations. FONDI.eu currently lists support of up to €120,000 for standard digitalisation investments, with an additional €100,000 available for eligible AI-related interventions and a 7% flat-rate contribution towards indirect costs. The overall Call 2 budget is €15 million.

The scheme is being run as a rolling call with periodic cut-off dates. At the time of writing, the next published cut-off is 30 September 2026, with further announced dates through 14 December 2026, subject to budget availability.

The Government announcement describes aid intensity of up to 50% for investments in Malta and 60% in Gozo. It also gives a maximum support figure of €235,400 where the AI-related component applies.

Public summaries are helpful for understanding the opportunity, but the current Guidance Notes, User Guide and Practical Guidelines should be treated as the source of truth when preparing an application. The scheme details are specific enough that eligibility should be checked against the actual project rather than inferred from a headline.

Could your project fit?

The current Guidance Notes list eligible digital solutions including commercial off-the-shelf software, custom software, analytical tools, cybersecurity systems, cloud computing, IoT, AI, big data, hardware and related installation and training costs. They also state that the investment has to relate to the applicant’s economic activity, have a productive purpose and be procured from external and unrelated sources.

In practical terms, projects may include things such as:

• internal workflow systems;
• customer portals;
• eCommerce or booking improvements;
• CRM and website integrations;
• product-data management;
• reporting and analytical tools;
• document-processing workflows;
• inventory, ordering or fulfilment systems;
• cybersecurity improvements;
• AI-assisted classification, extraction, analytics or automation.

That does not mean every software purchase or website project will qualify. The important question is whether the investment creates or improves a real business capability.

“A new software platform” is vague. “A customer onboarding system that collects documents, validates required fields, assigns cases to staff and reduces manual follow-up” is a project.

Start with the problem, not the technology

A good digitalisation project usually starts with a process that is already causing friction. Maybe leads arrive from several places and somebody copies them manually into a spreadsheet. Maybe stock, bookings or orders are maintained across several disconnected systems. Maybe supplier data has to be cleaned by hand before it can enter the ecommerce system. Maybe reports require several exports every week before management can see what is happening.

Those are much better starting points than deciding in advance that the business needs “AI”, “a new CRM” or “an app”. A way to describe the project is:

Current problem → proposed digital change → measurable result

For example:

Supplier files arrive in different formats and staff spend several hours normalising them manually → build an import and validation workflow → reduce processing time and data errors.

Or:

Customer onboarding currently happens through email threads and attachments → introduce a portal with required fields, document upload and internal status tracking → reduce follow-up work and shorten onboarding time.

Once the problem is expressed that way, the technology becomes much easier to choose.

What should you prepare before talking to suppliers?

You do not need a full technical specification before contacting a developer or software provider. You should, however, be able to explain how the process works today and what you want to improve. A useable project brief should cover:

• the process being improved;
• who currently performs it;
• the tools and spreadsheets involved;
• where the data comes from;
• what information needs to leave the process;
• where mistakes or delays occur;
• how much time the current process takes;
• which customers, staff or departments are affected;
• what the future workflow should roughly look like;
• which systems may need to integrate;
• who will own the system internally;
• how success will be measured.

That is enough for a competent supplier to start asking the right questions. Compare these two requests:

We need a CRM.

and:

Leads currently arrive through the website, email and Facebook. Two employees copy them into Excel. We want one place to collect the leads, assign an owner, track follow-up status and report on which sources eventually produce customers.

The second request still leaves plenty of room for technical discussion, but it gives the supplier something concrete to solve.

Do you need three quotations?

The current application material allows more than one way of establishing the investment and its expected cost.

The User Guide describes an Investment Proposal route where the applicant explains the required investment, sets technical specifications, describes what is available on the market, identifies potential suppliers and price ranges, and compares suitable options. The guidance explicitly recognises that a solution may be off-the-shelf, custom-built or a hybrid.

The Practical Guidelines should be checked for the exact procurement route applying to your project, particularly where quotations are used. The general principle is that specifications must be clear enough for alternatives to be compared meaningfully, and suppliers need to be external and unrelated to the applicant.

This matters because three quotations for three completely different ideas are not particularly helpful. If one supplier quotes for a SaaS licence, another proposes a fully custom platform and the third prices only an API integration, the numbers are not really comparable.

The business requirements should come first. Suppliers can then respond to the same underlying problem.

Does the supplier have to be an approved provider?

The current scheme documentation focuses on the eligibility of the investment, procurement, independence and supporting documentation rather than presenting the scheme simply as a purchase from one fixed approved-provider list.

That means the supplier choice still needs proper attention. The supplier should be external and unrelated to the applicant, and the proposed expenditure should correspond to the approved project. Before relying on a supplier proposal, I would check whether it clearly explains:

• what will actually be delivered;
• which parts are software licences, integration and custom work;
• which systems are included;
• what data needs to be migrated or cleaned;
• what assumptions are built into the price;
• what staff training is required;
• how hosting, security and access will work;
• what documentation will be handed over;
• what happens after launch.

A funded project still has to work once the funding process is over.

What should a supplier quote look like?

A quotation should map clearly to the project rather than simply saying “digital platform development”. For a custom or integrated system, I would expect enough detail to understand the main components. For example:

• customer portal;
• administrator interface;
• CRM integration;
• payment integration;
• data migration;
• reporting;
• user permissions;
• hosting or cloud services;
• testing;
• training;
• documentation;
• support period.

The current User Guide also expects enough technical specification and market context to establish comparability and justify the proposed investment. That does not mean every project needs a fifty-page specification. It means the quote should be detailed enough that somebody reviewing it can understand what the money is buying.

Buy, integrate or build?

A digitalisation project does not automatically require custom software. If the workflow is common and an existing product handles it well, buying the product is usually sensible. If the existing systems already do most of what the business needs but do not communicate properly, integration may be the better project.

If the process is specific to the business and valuable enough that generic tools create constant workarounds, a focused custom application may make more sense. And if nobody can clearly describe the process yet, the business may need discovery before committing to any of those options. A helpful set of rules is:

Generic process → buy

Good tools, poor connection → integrate

Specific and valuable process → consider custom development

Unclear process → understand it first

The funding should support the solution that fits the workflow, not push the business towards the most expensive category of software.

If the project includes AI, the questions become more specific

Call 2 includes a dedicated AI component, and FONDI.eu explicitly refers to AI-powered solutions, intelligent automation, advanced analytics, AI-enabled software applications, supporting infrastructure, cybersecurity measures and related implementation services.

That can make AI projects attractive, but the project still needs to be operationally clear. Before proposing an AI component, I would define:

• what task the AI performs;
• which data it uses;
• what happens before and after the AI step;
• whether personal or sensitive information is involved;
• which outputs can be checked automatically;
• which outputs require human review;
• what happens when the result is wrong;
• how quality will be measured;
• what productivity improvement is expected.

The Government announcement also states that the AI-related top-up is to be disbursed one year after project completion, subject to a productivity gains report and an ethical AI and societal well-being report. That makes measurement and governance part of the project design rather than something to think about after implementation.

A project such as:

Use AI to improve customer service.

is too broad. Something like:

Classify incoming support messages, extract order references, suggest a category and route uncertain cases to a staff member, with the aim of reducing manual triage time.

is much easier to test and measure.

Define success before the project starts

Digitalisation projects should have a before-and-after. That does not mean every project needs a complicated KPI framework. It means there should be some way to tell whether the investment improved the process it was supposed to improve.

Appropriate measures might include:

• hours of staff time saved;
• reduction in manual data entry;
• fewer errors;
• faster response times;
• shorter customer onboarding;
• better visibility over orders, leads or stock;
• reduced dependency on one employee;
• faster reporting;
• more complete product data;
• higher conversion rates;
• percentage of AI output accepted without correction.

This also gives the supplier something to optimise for. Without a measurable target, a project can technically launch successfully while changing very little for the business.

Internal ownership matters

A supplier can design and build the system. Someone inside the company still has to own the process. That person does not need to be technical, but somebody should understand why the system exists, who uses it, which data matters and what should happen when the workflow changes.

Many digital projects become awkward because nobody owns the system after launch. Users work around it, integrations break, reports are ignored and the supplier becomes the only person who remembers how everything fits together.

A proper handover should therefore include the relevant admin access, documentation, configuration details, training and a clear support arrangement. The business should not replace a fragile spreadsheet with software that becomes a different kind of dependency.

Common mistakes when preparing a project

The first is choosing the technology before defining the problem. “We want to use AI” or “we need an app” gives the supplier very little information. The second is underestimating the data. A new workflow may depend on customer, product or operational data that is duplicated, incomplete or stored differently across several systems. Data preparation can become a substantial part of the project.

The third is trying to digitise everything at once. A smaller workflow with a clear result is often easier to implement, test and justify than a large transformation containing several loosely connected ideas. The fourth is treating launch as the end of the project. Staff still need to use the system, the results need to be monitored and the workflow may need adjustments once it encounters real cases.

The fifth is assuming that a website redesign automatically represents meaningful digitalisation. A website may absolutely form part of a digitalisation project, but the stronger case is usually tied to a specific capability such as ecommerce, booking, customer self-service, integration or operational efficiency.

A practical preparation checklist

Before applying or asking suppliers to prepare detailed quotations, I would have the following ready:

• a short description of the business problem;
• the current workflow;
• the existing tools, spreadsheets and data sources;
• the main points of friction;
• the desired future workflow;
• the systems that may need to connect;
• the people who will use the solution;
• any security or data-protection requirements;
• the AI use case, if relevant;
• one or more measurable outcomes;
• an internal project owner;
• a rough implementation timeline;
• the current scheme documents.

The application material also asks for supporting items including an implementation schedule and evidence that the applicant has access to the necessary private match funding. Doing this preparation before supplier selection makes both the application and the implementation much easier.

Turning an idea into a project

You do not need to arrive with the architecture already designed. If you already know that a process is slow, repetitive, difficult to scale or dependent on several disconnected systems, that is usually enough to start.

For Tooling & Automation, I can help turn that current process into a technical scope, work out whether the sensible solution is existing software, integration or a custom tool, and build the system where custom development is justified.

The best outcome is not simply getting funding for technology. It is ending up with a system that removes a real operational problem and that the business can continue to use after the funded project is complete.

Official references: FONDI.eu Digitalise your SME, the current Guidance Notes, the current User Guide, and the Government Call 2 announcement.