TL;DR
Most Malta Enterprise grant applications are weaker than they need to be. The common problems are vague project descriptions, missing documentation, and financial projections that don't add up. This guide covers what evaluators actually assess, how to structure your investment proposal, and the specific mistakes that get applications rejected or delayed. Whether you're applying for Digitalise Your SME or Business START, the principles are the same.
Grant applications fail for predictable reasons. Not because the projects are bad, but because the proposals don't communicate the project well enough. Malta Enterprise evaluators can only assess what you put on paper. If your proposal is vague, incomplete, or doesn't address their criteria, it doesn't matter how strong your actual business case is.
This guide is about closing that gap. It covers what evaluators look for, how to structure your proposal, and the specific mistakes that cause delays and rejections.
Understanding What Evaluators Want
Before writing anything, you need to understand what Malta Enterprise is testing your application against. This isn't a mystery. The assessment criteria are published in the scheme guidelines, but most applicants don't read them carefully enough.
The Three Feasibility Tests
Every application goes through three feasibility checks.
Commercial feasibility asks whether your product or service addresses a real market gap. Can it compete? Is there actual demand, or are you building something nobody asked for? Evaluators want evidence that you understand your market, not just enthusiasm about your idea.
Financial feasibility asks whether the numbers make sense. Will the project generate returns after accounting for costs? Are your assumptions realistic, or have you inflated projections to make the case look stronger? Evaluators can spot unrealistic numbers quickly. They've seen hundreds of applications.
Technological feasibility asks whether the project is technically sound. Does the team have access to the required technology and expertise? Is the proposed solution based on proven concepts, or is it speculative?
Quality Factors
Beyond the pass/fail feasibility tests, applications are scored on quality. Four factors matter most.
Innovation is about differentiation. How does your project stand out from what's already available? This doesn't mean you need to invent something entirely new. It means you need to explain what's different about your approach.
Market understanding means showing you've identified your target market clearly. Who are your customers? How will you reach them? What's your acquisition strategy? General statements about "serving SMEs" or "targeting the Maltese market" don't score well.
Process clarity means your business model is explained. Evaluators want to understand your workflows, your value chain, how the proposed investment fits into your operations. If they can't follow how your business works, they can't assess whether the project makes sense.
Team capability means the people involved have relevant knowledge and experience. For Business START in particular, founder experience is explicitly assessed. For Digitalise Your SME, it's about whether your team can actually implement and use what you're proposing to build.
Before You Write: Preparation
The biggest mistake applicants make is starting to write before they've properly thought through their project. The proposal isn't the place to figure out what you want to build. That should be settled before you open the application form.
Get Clear on Your Own Project
Before writing a single word, you should be able to answer these questions clearly:
- What specific problem does this project solve?
- How do you currently handle this problem (or why can't you)?
- What will the solution look like in practice?
- Who will use it and how?
- What measurable improvements do you expect?
- What does success look like after 12 months?
If you can't answer these concisely, your proposal will be vague. Vague proposals get sent back for rectification, or rejected.
Gather Documentation Early
Don't leave documentation to the last minute. For Digitalise Your SME, you'll typically need:
- Completed application form
- Investment proposal or feasibility report
- Company registration documents
- Financial statements (if applicable)
- Supplier quotations (minimum requirements vary)
- Evidence of digital intensity level (for the +5% bonus)
For larger projects, you may also need a business plan, technical specifications, market research, and CVs of key personnel.
Missing a single required document means your application is marked incomplete. Incomplete applications are either sent back (adding weeks to the timeline) or rejected outright.
Get Your Quotes Ready
For Digitalise Your SME, quotations are a critical part of the application. The number of quotes required depends on the project size, and they need to meet specific formatting requirements. Your supplier (whether that's a software development company, hardware vendor, or both) should provide detailed, itemized quotes that clearly show what's included.
If your quotes are vague or don't break down costs properly, expect a rectification request.
Writing Your Investment Proposal
Structure
A strong investment proposal follows a logical structure. While Malta Enterprise doesn't mandate a specific format, the best proposals cover these areas in order:
- Executive summary (what you're proposing and why)
- Company background and current situation
- Problem statement (what's not working today)
- Proposed solution (what you plan to do)
- Technical approach (how it will be built or implemented)
- Market context (who benefits and why it matters)
- Financial analysis (costs, expected returns, payback)
- Implementation timeline
- Team and capabilities
The Problem-Solution Framework
The core of your proposal is explaining what problem exists and how your project solves it. This sounds obvious, but most proposals fail here. They describe what they want to buy without explaining why.
Every section of your proposal should connect back to a specific, concrete problem. If you can't explain what problem a particular feature or system solves, it probably doesn't belong in the proposal.
Specificity vs. Vagueness
This is the single most important difference between proposals that get approved quickly and those that get sent back for rectification.
A weak project description:
"We want to digitise our business operations to become more competitive in the modern marketplace. This investment will help us grow and serve our customers better."
This tells evaluators nothing. What operations? How will you digitise them? What does "more competitive" mean in measurable terms?
A strong project description:
"We will replace our manual inventory tracking (currently done via spreadsheets updated weekly) with a real-time inventory management system integrated with our POS. This addresses two specific problems: stockouts that cost us approximately EUR 2,400 per month in lost sales, and overstocking that ties up roughly EUR 8,000 in dead inventory at any given time."
The difference is specificity. The second version tells evaluators exactly what the problem is, what the solution looks like, and what the expected impact is. They can assess it. They can verify the logic. They can score it.
Quantifying Benefits
Every claimed benefit should have a number attached to it, or at least a reasonable estimate with stated assumptions. "This will save time" is not a benefit statement. "This will save approximately 15 hours per week of manual data entry, based on current volumes" is.
A weak financial justification:
"The investment will pay for itself through improved efficiency and increased sales."
A strong financial justification:
"Implementation cost: EUR 24,000. Expected annual savings: EUR 9,600 (breakdown: EUR 4,800 reduced stockout losses, EUR 2,400 inventory carrying cost reduction, EUR 2,400 staff time savings at 10 hours per month at EUR 20 per hour). Payback period: 2.5 years without accounting for the grant, or under 12 months with 60% coverage."
You don't need perfect precision. You need reasonable estimates based on stated assumptions. If your numbers are based on current data (order volumes, staff hours, error rates), say so. Evaluators respect honest estimates more than impressive-sounding figures that don't hold up to scrutiny.
Financial Projections That Don't Get Rejected
The financial section trips up more applicants than any other part. Three mistakes are especially common.
Inflated revenue projections. Don't project hockey-stick growth to make the case look stronger. Evaluators know what realistic growth looks like in Malta. If your projections show tripling revenue in year one with no clear explanation of how, it damages your credibility for the entire application.
Missing cost items. If you budget for software development but forget training, data migration, or ongoing maintenance, your financial picture looks incomplete. Account for all costs, even the ones that aren't eligible for funding.
No stated assumptions. Every number in your financial section should trace back to an assumption. "Revenue of EUR 50,000 in Year 1" means nothing without explaining how many customers, at what price, through which channels. State your assumptions explicitly, and make sure they're consistent with what you've written in other sections.
Your aid intensity (the percentage of costs covered by the grant) depends on which state aid route applies to you. Make sure your financial projections account for the correct grant percentage, not the maximum theoretical rate.
Common Mistakes to Avoid
The "Wish List" Proposal
Some applicants treat the grant as an opportunity to buy everything they've ever wanted. New laptops, new software, new monitors, new everything. The proposal reads like a shopping list rather than a strategic investment.
Evaluators see through this. Every item needs a clear justification tied to the project's objectives. A new laptop is justified if the current one can't run the software you're implementing. It's not justified just because you'd like an upgrade.
Missing the Scheme's Purpose
Each scheme has specific objectives. Digitalise Your SME is about digital transformation, not general business improvement. Your proposal needs to show how the investment changes your digital capabilities, not just how it helps your business generally.
For Business START, the purpose is developing a business plan and validating a concept, not executing a fully-formed idea. If your proposal reads like you already know exactly what you're building and just need money to do it, you're positioning yourself wrong for this scheme.
Inconsistent Information
This is surprisingly common and always causes problems. Your executive summary says the project costs EUR 30,000 but your cost breakdown totals EUR 34,500. Your timeline says six months but your implementation plan describes nine months of work. Your problem statement mentions three issues but your solution only addresses two.
Read your proposal as a whole before submitting. Check that numbers, timelines, and claims are consistent across all sections. Evaluators notice inconsistencies, and they raise questions about how well you actually understand your own project.
Over-promising
If your project genuinely solves a problem and generates reasonable returns, that's enough. You don't need to claim it will "revolutionise your industry" or "transform the Maltese economy." Grand claims without evidence weaken your proposal. Stay grounded in what you can actually demonstrate.
After Submission: What to Expect
Timeline
For Digitalise Your SME, expect three to four months from submission to approval. This isn't because the evaluation itself takes that long, but because most applications require at least one round of rectification.
Applications are processed in batches after each cut-off period (every two to three weeks). Your application joins the queue after the next cut-off date following submission.
Rectification Requests
Getting a rectification request is normal. It doesn't mean your application is bad. It means the evaluators need more information or clarification on specific points.
Common rectification requests include: more detail on the technical approach, clarification of cost breakdowns, additional evidence for claimed benefits, missing or incomplete documentation, and explanation of how specific items relate to the project objectives.
You typically have up to two months to respond. Take the time to provide thorough answers. Rushing a rectification response often leads to a second request, which adds more delay.
How to Respond Well
When you receive a rectification request, address each point specifically and completely. Don't provide general answers to specific questions. If they ask about a particular cost item, explain that specific item. If they want evidence for a claim, provide the evidence, not a restatement of the claim.
Scheme-Specific Tips
Digitalise Your SME
This scheme focuses on digital transformation. Your proposal should emphasize how the investment changes your operations, not just adds technology. The difference matters. Buying software is not digital transformation. Using software to fundamentally change how you handle inventory, customer relationships, or business processes is.
Keep in mind the three-year durability requirement. You must keep using the funded assets for at least three years after project completion. Your proposal should show that the investment has lasting value, not that it's a short-term fix.
The 7% indirect costs allowance covers some administrative costs, including grant consultant fees for larger projects. Factor this into your planning.
Quotes need to be detailed and itemized. Your technology partner should be prepared to provide documentation that meets Malta Enterprise's requirements, not just a lump-sum price.
Business START
This scheme is about developing a plan, not executing one. Your Feasibility Report should focus on validating a business concept. Show that you understand the market opportunity, that your approach is sound, and that you have the skills to pursue it.
Founder experience is explicitly assessed. If your background is relevant to the business you're proposing, highlight it prominently. If you're entering a new field, explain what transferable skills you bring and what gaps you plan to address (through hiring, partnerships, or training).
International potential matters. Malta Enterprise looks for businesses that can serve customers beyond Malta. If your product or service is purely local, this scheme may not be the right fit.
The Business Plan template for Tranche 2 is mandatory and must meet Malta Enterprise's standards. It's not a formality. Plan for it from the beginning, not as an afterthought when the deadline approaches.
When to Get Help
DIY vs. Consultant
Not every application needs a grants consultant. If your project is straightforward, the amount is modest, and you're comfortable with documentation, you can apply yourself. Read the guidelines carefully, follow them precisely, and be thorough.
Consultants become more valuable when the project is complex, when the amounts are larger, or when you've been rejected before and aren't sure what went wrong. A good consultant knows what evaluators expect and can help you frame your proposal in a way that addresses the assessment criteria directly.
What a Good Consultant Does
A grants consultant handles the application paperwork, structures your proposal to align with the scheme's criteria, and manages the back-and-forth with Malta Enterprise during evaluation. They don't (or shouldn't) invent information. They help you present your actual project more effectively.
For the technical side, your technology partner provides the specifications, quotes, and technical documentation. For Digitalise Your SME, we provide all the technical documentation needed for your application, whether you work with your own consultant or one we recommend.
Red Flags
Be cautious of consultants who guarantee approval (nobody can guarantee that), who suggest inflating numbers to hit thresholds, or who seem unfamiliar with the specific scheme you're applying for. A good consultant asks detailed questions about your project before agreeing to take it on.
Next Steps
A strong proposal is specific, consistent, well-documented, and honest about what the project will achieve. It doesn't need to be perfect. It needs to be clear enough that an evaluator who has never met you can understand your project, verify your claims, and score your application fairly.
If you're preparing to apply for Digitalise Your SME and need technical documentation, specifications, or quotes for a software project, we can help with that side of the application. For early-stage founders, Business START provides EUR 10,000 to develop your business plan before pursuing larger investments.
