How to Get a TÜBİTAK 1507 Grant: What We Learned With Postuby
The short answer
TÜBİTAK 1507 (the R&D Starter Support Programme for SMEs) is a grant programme funding a small company's first R&D project: part of the project's costs is covered without repayment, while the support rate and ceiling change by call period — so checking the current call text on tubitak.gov.tr before applying is essential. What decides acceptance isn't the money but the project's "R&D character": you must define work that cannot be solved with existing methods, that contains genuine technical uncertainty, and whose output is a new product or method. Ordinary software development, integrating off-the-shelf technology or building a website or app does not, on its own, count as R&D. The process runs roughly: writing the project definition and work packages, budgeting, online submission, referee evaluation, and — if accepted — periodic technical and financial reporting. Budget 4–8 weeks for preparation and a few months before you hear back.
First, set the expectation: this is not investment
Most founders discussing TÜBİTAK support think of it as a funding round, and that's where they go wrong. It's a grant: you give up no equity and repay nothing — but in exchange you must prove the work is genuinely R&D and document every lira you spend. You're buying discipline, not money.
Second point: the money arrives after you spend it. You can't build your cash flow on "we'll do it when the funding lands" — you spend first, then document, then get reimbursed. This is where a lot of early-stage startups get caught out.
Our advantage with Postuby was that we were genuinely wrestling with technical uncertainty in the area we applied for — we didn't invent a story for the application, we were already trying to solve that problem. End-to-end autonomous production of social media content wasn't something anyone could assemble from off-the-shelf parts at the time. That's the healthiest form a 1507 application takes: describing the hard work you're already doing. People who invent a project for the grant struggle to write it and then stall during reporting.
The difference between a project that's accepted and one that isn't
One question sits at the centre of the evaluation: is there R&D here? Concretely, that means your project must contain a technical problem whose outcome isn't known in advance. The table below shows how the same work reads depending on how it's written.
| NOT R&D | IS R&D |
|---|---|
| "We will build a social media management dashboard." | "We will develop a method that infers a brand's voice from examples and produces consistent content without human intervention — including a way to measure that consistency." |
| "We will integrate an off-the-shelf AI API into our app." | "We will develop a routing layer that automatically selects between models of differing cost and quality according to task type." |
| "We will redesign our e-commerce site." | "We will develop a method that personalises product imagery in real time based on user behaviour." |
| "We will add new features to our existing product." | "We will research a method to automate process X, currently done manually, keeping the error rate under 5%." |
Notice what the right column shares: every line names a method and a measurable target, not a product feature. Write "what problem will we solve and how will we measure success", not "what will we build".
The process: what actually happens
Eligibility check (1 day)
The programme targets SME-scale limited or joint-stock companies established in Turkey, prioritising firms running their first R&D project. If you're a sole trader or outside the size bracket, look at other programmes instead. Because conditions change per call period, step one is reading the current call text on tubitak.gov.tr.
Breaking the project into work packages (1–2 weeks)
This is the skeleton of the application. Each work package states what will be done, which uncertainty it resolves, who works on it, how long it takes and what counts as success. The most common mistake is packages that are too coarse: one eight-month package called "Development" is impossible for a referee to assess and impossible for you to report on.
Budget (3–5 days)
Personnel, equipment, outsourced services and materials are each justified separately. Personnel is usually the largest line and must be consistent with your actual payroll data. The rule is simple: the budget must map one-to-one onto the work packages. A budget that doesn't is what draws the most questions.
Submission and evaluation (a few months)
Submission is online; then referee evaluation follows, sometimes with an interview or site visit. The most valuable preparation here is that whoever presents the project genuinely understands the technical side. If a marketer presents it, the first technical question unravels everything.
After acceptance: reporting (throughout the project)
This is where the real weight sits. Periodic technical reports (what we did, which uncertainty we resolved) and financial reports (documentation of expenses); the financial report usually goes through a sworn financial advisor. Bring your accountant in from day one — reconstructing it later costs far more.
What made it easier for us was writing the technical side together with Kadir — he covered the software, I covered product and commercial. We were also in the TİM-TEB Entrepreneurship House programme at the time, and the concrete benefit of being inside a structure like that is having people who've been through it to ask. A founder writing the application alone usually gets stuck on "is this sentence R&D enough" — and only another reader resolves that.
What I'd do differently if I applied again
- I'd write smaller work packages. Small packages are clearer for the referee and a lifesaver at reporting time. Being able to say "this package is done" is a far better position than "we're 60% through this package".
- I'd set the financial process up with the accountant from the start. Tagging expenses to project codes as they happen is far cheaper than sorting invoices afterwards.
- I'd tie success criteria to numbers. Not "improve content quality" but "reduce the share of outputs needing human intervention from 40% to 10%". It helps in both the application and the reports.
- I'd tone down the commercial narrative. This isn't an investor pitch; the referee cares more about technical uncertainty than market size. The commercial part is necessary but not the lead.
- I'd decide about a consultant earlier. A good one doesn't write the text; they frame what you wrote correctly — and that costs less than a rejected application.
So is it actually worth it?
My honest answer: it's worth it more for the side effects than the money. The grant matters, but three things matter more:
- Writing the project clarifies you. Being forced to answer "which uncertainty are we resolving" is one of the most useful exercises a product team can do — even if you don't get the grant.
- You gain institutional discipline. Periodic reporting installs, early on, an order that an early-stage company doesn't develop on its own.
- It works as validation in investor conversations. "TÜBİTAK-backed" doesn't win funding on its own, but it shows an independent party assessed the project technically — that carried weight in Postuby's later rounds.
That said: if there's no genuine technical uncertainty in your work, applying is a waste of time. Building a good product by combining existing tools is deeply valuable work — but it isn't R&D, and dressing it up as such is unfair to you and to whoever evaluates it.
Key takeaways
- 1507 is a grant, not investment: no equity, but you must prove R&D and document every expense.
- The decisive question isn't "what will we build" but "which technical uncertainty will we resolve".
- Write small work packages — clearer for the referee, a lifesaver at reporting.
- The money comes after you spend it; plan your cash flow accordingly.
- Don't apply without genuine technical uncertainty — building a good product is valuable, but it isn't R&D.
Frequently asked
What's the support rate and ceiling?
These are updated per call period, so quoting a figure here would mislead — check the current call text on tubitak.gov.tr before applying. What doesn't change: the support is non-repayable, covers a set percentage of project costs, and you fund the rest. Your need for own capital doesn't disappear entirely.
Are software projects accepted?
Yes, but "developing software" alone isn't enough. Accepted software projects share one trait: they target a problem existing methods can't solve — a new algorithm, a new method, a measurable performance leap. Assembling an app from off-the-shelf libraries doesn't qualify.
Do I need a consultant?
Not mandatory, but valuable on a first application. A consultant's job isn't to invent the project but to frame the work you're actually doing the way the programme expects. Avoid anyone who says "I'll write it, you sign it" — you're the one who'll defend that text during reporting.
Can I reapply if I'm rejected?
Yes, and the rejection reasoning is usually instructive — most often on the theme of "the R&D character wasn't sufficiently demonstrated". Reframing the project with that feedback beats writing a new one from scratch. I know plenty of companies accepted on the second attempt.
How long until I hear back?
Budget 4–8 weeks of preparation and a few months from submission to outcome; it varies by call period and volume. Practical advice: don't tie your cash plan to the result. Plan as though you're doing the project anyway — with the grant you go faster, without it you go slower, but you don't stop.