Startup Grants and Incentives: An Application Guide

Prepare the grant before the idea

When a team starts a company, the funding conversation often arrives immediately after the product idea. Which program should we apply to? How much support is available? When does the call close? Those are sensible questions. The trouble starts when a grant is treated as a form to complete in exchange for free money. A weak application usually reveals that assumption on its first page.

I see an application as three connected jobs: matching the project to the right program, building a measurable plan, and managing expenses so they can be proved later. Leave out one of those pieces and even a promising idea looks unfinished. Technical teams are usually good at explaining what they want to build. They are less consistent at explaining which risk each activity will reduce.

Program names, budgets, call dates, and eligible-cost rules can change in Türkiye. Check the current announcement and official guidance before using any detail below to prepare a budget. Trusting an old blog post for eligibility rules is an expensive way to miss a deadline.

Choose the right type of support

Start by identifying what the money is for. Company formation, research and development, employees, machinery, software licences, prototypes, and market entry may belong to different programs. There is no single public-funding bucket called “startup support.” Institutions publish programs for different purposes.

These categories are a useful first filter:

KOSGEB’s entrepreneur-focused programs may assess company age, activity code, founder training, and proposed expense categories. TÜBİTAK programs such as BiGG and TEYDEB examine the technology and R&D character more directly. Development agencies, ministries, and other public institutions may publish time-limited calls too.

Here is the distinction that causes trouble: writing an application does not turn a project into R&D. Giving a familiar e-commerce product different colours is not a convincing innovation claim. You need a technical uncertainty, a method to test it, and a measurable result.

That distinction has saved me from recommending the wrong funding route more than once. A feature list is not a research plan.

Check eligibility before applying

Before opening the application form, make an eligibility table. Include the company type, incorporation date, NACE code, ownership structure, tax and Social Security status, previous support received, project duration, and expense categories. Two hours spent here can prevent days of writing for a program you cannot use.

Company age and activity code

Some programs target newly formed companies; others require a business to have operated for a defined period. The activity code is not merely a line on a tax certificate. If the business model, budget, and registered activity point in different directions, a reviewer will reasonably ask why.

Suppose a software company is registered primarily for manufacturing while the application describes an AI-based SaaS product. Explain that difference. Ask your accountant whether the registered activity accurately represents the project before applying. Assuming that changing the code later will solve every eligibility issue is not a safe plan.

Founders and the applicant

Age, education, ownership percentage, management role, and previous company experience can all matter, depending on the program. Listing every founder does not mean every founder should be presented as a project owner. The application should show who leads the technology, who owns the commercial work, and who manages the budget and operations.

Clean up the ownership structure before applying. If a founder’s shares, voting rights, or responsibilities appear differently in different documents, that creates needless risk in a grant review and in an investment discussion. The post What Is a Startup Cap Table? Equity Structure Explained covers how to read this structure.

Compare programs using official sources

An old announcement ranking highly in Google does not mean the call is still open. I start with the institution’s official program page, application guide, question-and-answer document, and appendices. I mark more than the closing date: eligible expenses, payment method, reporting requirements, and contract terms each get their own notes.

Do not prepare a budget until you have written answers to these questions:

• Is the application submitted by the company, or through an implementing or intermediary organisation?
• Is the support paid in advance, repayable, or reimbursed after expenses?
• Are VAT, salaries, consultancy, hosting, licences, travel, and marketing eligible?
• Are purchases from founders or related companies restricted?
• Can the project period be extended, and is prior approval required for changes?
• What format is required for invoices, bank receipts, payroll records, or technical reports?

The presence of an expense category in a list does not mean the entire expense will be covered. A maximum amount, support ratio, and call-specific conditions may apply separately. If a rule is unclear, ask the institution in writing. I do not make a phone conversation my only evidence.

That small habit matters when the person who gave the answer is no longer handling the file.

Explain the project to a reviewer

A strong application does not begin with “our platform uses artificial intelligence.” Start with the customer, the problem, the limits of current solutions, and the technical or commercial uncertainty your project will reduce.

Define the problem and customer

Avoid broad statements. Instead of saying “small businesses cannot manage their data,” describe what a specific user group does today, how many steps the process takes, where time or money is lost, and how your product changes that flow.

Customer interviews, pilot registrations, pre-orders, letters of intent, and measured usage data make the claim more credible. If you do not have customers yet, say so. Explain your validation plan and which experiment will test each assumption.

Show technical novelty and risk

Risk is not a weakness in an R&D application. Pretending that no risk exists is the real weakness. Examples include whether a model will remain accurate with inconsistent data, whether latency will hold under high traffic, or whether the product can integrate with existing systems.

For every risk, state the method, success measure, and fallback plan. “We will improve performance” is weak. “After load testing, we will keep p95 response time below the defined threshold” is measurable. Choose the threshold from the real usage scenario rather than inventing a number that merely looks impressive.

I once reviewed a plan where “scalability” appeared as a risk but had no test, metric, or owner beside it. The word sounded technical; the plan was not. Adding those three missing pieces made the project much easier to assess.

Build the budget from the work

A budget is not a shopping list. It is the financial expression of the project activities. Write the work packages first, then calculate the people, software, hardware, and services each package requires.

A work package might cover data collection and anonymisation, a prototype algorithm, integration, security testing, pilot use, and commercialisation. Give each package an owner, start and end date, deliverable, and estimated cost. The budget and schedule can then check each other.

For staff costs, use the calculation method accepted by the program rather than listing only gross salary. For hosting and licences, avoid a vague line such as “cloud costs.” State which service is needed, for what period, and for how many users or what capacity.

My practical rule is simple: if you cannot defend an expense in one sentence in the application, it is not ready for the budget. Plan for delayed payments too. If you are expected to spend first, model that cash requirement separately. A project funded on paper but unsupported by the bank balance does not run very far.

Short version: the work comes first, and the expense follows it.

Support the application with evidence

A review team often knows your company only through the file in front of it. Put evidence beside important claims. Interview notes, prototype screens, a technical architecture, competitor comparisons, pilot letters of intent, team CVs, and revenue data can be organised into one coherent package.

More attachments do not automatically mean better quality. Two pages proving a critical assumption are more useful than fifteen pages of repetition. Use clear filenames. WP3_security_test_plan_v1.pdf creates fewer mistakes than final_final2.pdf.

An architecture diagram is especially useful for technical ventures. Where is user data stored? Which services communicate? How are backups and access permissions managed? If you process personal data under KVKK, explain data minimisation and retention as well. Security belongs in the product plan, not in a paragraph added at the end.

I have seen applications describe security as “SSL enabled” and stop there. That says very little about access control, backups, logging, or retention. A reviewer does not need a security textbook, but they do need to see that the risks have an owner.

Manage time and cash together

The application deadline is not the project start date. Evaluation, contract signing, revisions, and the first payment can create a gap. During that period, salaries, hosting, accounting, and customer operations continue.

Prepare at least three monthly cash-flow scenarios: support arrives early, support is delayed, and support is rejected. Write down which expenses you will postpone in each case. That plan gives you room to think instead of forcing a product change in a panic.

Making the project schedule artificially short is another common mistake. A short timeline may look ambitious, but unrealistic hiring, procurement, and testing dates increase the chance of revisions. An unnecessarily long schedule can make the team look unable to deliver. Every date should have a reason.

Cash flow is part of technical planning. A server, contractor, or test environment cannot be paid with an approved budget that has not reached the company bank account.

Approval starts the audit trail

Approval does not end the work; it starts the record-keeping. Keep required invoices, bank transactions, payroll records, purchasing documents, delivery notes, and technical evidence in the project folder. Paying with a personal card and reconstructing the paperwork later creates unnecessary questions.

If something must change, check the program’s approval procedure first. A staff change, budget transfer, schedule slip, or new supplier may require advance notice. “The total is unchanged” is not a safe argument.

A simple folder structure is enough:

project-files/
  00-contract-and-guidance/
  01-application/
  02-budget-and-invoices/
  03-payroll-and-staff/
  04-technical-reports/
  05-procurement/
  06-correspondence-and-approvals/

This does more than sort files. It makes every expense traceable to a work package and an approval. Keep the backups somewhere else too.

I once found a project archive stored on one founder’s computer. When its disk failed, most files were recovered, but older versions of the purchasing approvals were gone. Since then, I do not consider a project folder ready without version names, access permissions, and a separate backup. A file that exists but cannot be opened is not evidence.

Common first-application mistakes

• Forcing the idea into a program: Stretching a project to fit a budget even though it does not match the call’s purpose.
• Confusing R&D with a feature list: Adding five screens to an application is not, by itself, technical innovation.
• Writing unsupported revenue forecasts: Claiming thousands of customers in year one without explaining channels, cost, and capacity.
• Leaving the team vague: Failing to show who will deliver the project and whether the required skills exist.
• Underestimating cash needs: Ignoring repayable support or reimbursement-after-spending rules.
• Collecting documents on the last day: Trying to gather tax records, signatures, quotes, ownership records, and bank documents as the portal closes.
• Listing every expense: Inflating the budget with equipment or marketing costs that have a weak connection to the project.

The single-computer archive mistake taught me another version of the same lesson. Invoices were present, but nobody could tell which work package each invoice supported or who had approved it. We rebuilt the folders, version names, and approval records from the beginning. Storing a document is not enough; its connection to the activity must survive too.

Connect the grant to the business plan

A grant application is not an investor pitch, but it cannot be detached from the business model. The first release in the product roadmap, the pilot customer, and technical debt should appear in the same order as the funded activities. The post How to Build a Product Roadmap for a Startup covers this ordering alongside product decisions.

Keep market-entry plans concrete too. Which customer segment comes first? What is the sales channel? How will you find pilot users? How will you measure the move from a trial to paid use? The questions in How to Build a Go-to-Market Strategy for a Startup can make the commercialisation section more specific.

When calculating customer acquisition cost, do not count advertising alone. Sales calls, demo preparation, onboarding, and support time are real costs. How to Calculate Startup CAC: Customer Acquisition Cost explains why those items should be separated. The reviewer also needs to see how the product will survive after the support ends.

A grant should buy progress, not just activity. If the funded work ends but the company has no customer, operating plan, or next technical milestone, the budget was never connected to the business.

Run a final pre-application check

Before submitting, ask someone outside the project to read the file. Someone who does not understand the technical details may be the best reviewer because they will mark every unclear passage. Then run three separate checks with your technical team, accountant, and someone familiar with the application rules.

• Do the company, founder, and activity-code requirements match?
• Does every activity have a measurable output and an owner?
• Do the budget, timeline, and work packages tell the same story?
• Is there evidence for the revenue and market claims?
• Is there a cash plan for the unsupported share?
• Have you read the eligible-cost, procurement, and reporting rules?
• Do all attachments open, with correct signatures and dates?
• Have you stored the submission number and receipt safely?

I would focus on one program first, build the eligibility table, and prepare a three-month activity and cash plan before opening the form. Ask yourself one question before applying: if the support is rejected, what evidence and what small next step would still move this project forward?

Frequently asked questions

Must I form a company to apply?

It depends on the program. Some entrepreneurship supports require a company at the application or contract stage, while some pre-incubation and entrepreneurship programs accept teams that are still at the idea stage. Check the current call’s applicant and incorporation clauses.

Does a grant have to be repaid?

Non-repayable support may not require repayment when spending and reporting follow the rules. Repayable support, co-financing, and breaches of contract can create different repayment obligations. Do not rely on the word “grant” without reading the program contract.

Are hosting and software licences eligible?

Some programs accept these costs, while others restrict them or accept them only when tied to specific project activities. Show the service period, capacity, invoice, and intended project use clearly in the budget.

Can I apply to several programs at once?

Applying and receiving two supports for the same expense are different matters. Check the rules on duplicate financing, ongoing projects, and overlap with public support. Showing the same employee or invoice in two projects can create a serious problem.