TÜBİTAK 1507 mi 1501 mi? Ar-Ge başvurusu için karar rehberi

TÜBİTAK 1507 ile 1501 arasında seçim yaparken yalnızca destek tutarına bakmak yeterli değildir. Şirketin geçmiş projeleri, teknik hedefin kapsamı, ekip kapasitesi, çalışma süresi ve ilgili çağrının koşulları birlikte değerlendirilmelidir. 1507, KOBİ Ar-Ge Başlangıç Destek Programı; 1501 ise Sanayi Ar-Ge Destek Programı adıyla yürütülür. Bu yazı başvuruyu hangi programa hazırlamanız gerektiğini düşünmek için pratik bir karar çerçevesi sunar; nihai uygunluğu güncel çağrı dokümanı ve kurum değerlendirmesi belirler.

Karşılaştırmaya bütçe tavanından başlamayın

İlk soru “hangi program daha çok destek veriyor” olduğunda proje, şirketin gerçek ihtiyacından uzaklaşabilir. Ekip daha yüksek bir tutara ulaşmak için kapsamı gereksiz yere büyütebilir veya sırf daha kolay göründüğü için önemli teknik çalışmaları dışarıda bırakabilir. Doğru başlangıç, araştırılacak problemin ve proje sınırının netleşmesidir. Program seçimi bu teknik ihtiyacın üzerine kurulmalıdır. Aksi durumda dosya güçlü görünse bile uygulama döneminde yönetilmesi zorlaşır.

Önce destek olmadan da açıklayabileceğiniz bir proje özeti yazın. Hangi problemi çözeceksiniz, mevcut yaklaşım neden yetersiz, hangi belirsizlikleri araştıracaksınız ve sonuçta ne ortaya çıkacak? Sonra gerekli iş paketlerini ve kaynakları belirleyin. Bu çalışma tamamlandığında iki programın güncel koşullarıyla daha sağlıklı karşılaştırma yapılabilir. Başvuru sayısı, şirket geçmişi ve uygunluk gibi konuları varsaymak yerine ayrı kontrol satırlarında tutun. Bir programın adı size uygun görünse bile özel çağrı koşulları veya geçmiş projeleriniz değerlendirmeyi değiştirebilir. Karar dosyasında “uygun”, “uygun değil” ve “kurumdan açıklama bekliyor” durumları birbirinden ayrılmalıdır.

2026 ikinci çağrısındaki tarihleri ayrı kontrol edin

TÜBİTAK'ın 20 Temmuz 2026 tarihli ortak duyurusuna göre 1501 için kuruluş bazlı ön kayıt son tarihi 22 Ekim, çağrı kapanışı 26 Ekim 2026'dır. 1507 için ön kayıt son tarihi 9 Kasım, çağrı kapanışı 11 Kasım 2026 olarak açıklanmıştır. Bu bilgi 10 Ekim 2026 kontrolüyle aktarılmaktadır; başvuru öncesinde uzatma veya değişiklik duyurularını yeniden kontrol edin. Ön kayıt ile proje gönderim tarihini aynı sanmayın.

Aynı duyuru, ikinci çağrıdan itibaren bazı kuralların güncellendiğini belirtir. Bu nedenle önceki dönem dosyası veya eski danışman sunumu tek başına yeterli kaynak değildir. Şirket içinde güncel çağrı bağlantısını herkesin kullandığı ortak çalışma alanına ekleyin. Son tarih için yalnızca takvim hatırlatıcısı kurmak da yetmez; imza, yetkilendirme ve kuruluş bilgileri gibi hazırlıkların hangi gün tamamlanacağını belirleyin. Teknik dosya hazır olsa bile idari hazırlığın son güne kalması gereksiz risk yaratır. Başvuruyu gönderecek kişinin sisteme erişimini ve görevini önceden netleştirmek, teknik çalışmayı destekleyen basit ama önemli bir adımdır.

Şirketin proje geçmişini temiz bir tabloda toplayın

Program karşılaştırmasında şirket geçmişi soyut bir tanıtım paragrafı olarak kalmamalıdır. Daha önce başvurulan, desteklenen, tamamlanan ve devam eden projeleri ayrı durumlarda listeleyin. Her kaydın programı, konusu, tarihleri ve sonucu bulunabilir. Aynı projenin farklı aşamalarını yeni proje gibi saymak veya başvuruyla sözleşmeyi aynı olay kabul etmek karışıklık yaratabilir. Güncel çağrının hangi geçmiş kayıtları nasıl değerlendirdiğini ayrıca kontrol edin.

Bu tablo yalnızca uygunluk incelemesine hizmet etmez. Şirketin hangi teknik kabiliyetleri geliştirdiğini de gösterir. Önceki projede edinilen bilgi yeni projeye nasıl taşınıyor? Aynı teknik sorun tekrar mı yazılıyor, yoksa gerçekten yeni bir belirsizlik mi araştırılıyor? Yönetim bu soruları baştan cevaplamalıdır. Önceki çalışmanın başarılı sonuçlarını sahiplenmek kadar çözülmemiş konuları dürüstçe açıklamak da değerlidir. Geçmiş projelerin çıktıları ticarileşmediyse nedenlerini incelemek, yeni ekonomik planı güçlendirebilir. Sorun ürün kalitesi, müşteri erişimi veya iş modeli olabilir; hepsine aynı çözüm uygulanmaz. Program seçimi böylece geçmiş deneyimlerden öğrenen bir karara dönüşür.

Teknik kapsamı yönetilebilir büyüklükte tanımlayın

Bir projenin büyük olması, mutlaka daha güçlü olduğu anlamına gelmez. Çok sayıda bağımsız teknik hedefi tek dosyada birleştirmek, hem anlatımı hem uygulamayı zorlaştırabilir. Tersine aynı araştırma problemini yapay biçimde küçük parçalara ayırmak da bütünlüğü bozabilir. Kapsamın doğru büyüklüğü, hedefler arasındaki teknik bağlantı ve ekibin bunları yönetme kapasitesiyle ilgilidir. Program tercihi bu bütünlüğü korumalıdır.

İş paketlerini yan yana koyup hangilerinin aynı ana soruya hizmet ettiğini inceleyin. Bir paketin çıktısı diğerini besliyorsa aralarında güçlü ilişki vardır. Birbirinden bağımsız iki ürün fikri yalnızca aynı şirkette geliştirildiği için tek projeye alınmış olabilir. Böyle durumlarda önce teknik mimariyi tartışın, sonra program koşullarını değerlendirin. Kapsam daraltılacaksa yalnızca bütçeden kalem silmeyin; hedef, yöntem ve çıktı ilişkisini yeniden kurun. Bir test aşamasını çıkarmak toplam tutarı azaltabilir ama sonucun güvenilirliğini de zayıflatabilir. Her değişiklikte “proje sonunda neyi gerçekten öğrenmiş veya geliştirmiş olacağız” sorusuna geri dönün.

Ekip kapasitesini başvurunun merkezine yerleştirin

Uygun programı seçmek için şirketin kaç çalışanı olduğundan fazlasını bilmek gerekir. Kritik teknik yetkinliklerin kimde bulunduğu, bu kişilerin başka iş yükleri ve eksik uzmanlığın nasıl tamamlanacağı değerlendirilmelidir. Küçük ama odaklı bir ekip, kapsamı iyi tanımlanmış projeyi güçlü biçimde yürütebilir. Daha kalabalık bir ekip ise sorumluluklar belirsizse zorlanabilir. Sayı, kapasitenin yalnızca bir parçasıdır.

Proje takvimini kişilerle eşleştirirken gerçek çalışma düzenini kullanın. Mevcut müşterilere hizmet veren personelin bütün zamanını yeni araştırmaya ayıracağını varsaymayın. İşe alım planı varsa aday bulma ve uyum süresini düşünün. Dış uzman kullanılacaksa bilginin şirket içinde nasıl kalacağını açıklayın. Bu hazırlık, programlar arasında karar verirken “hangi kapsamı gerçekten taşıyabiliriz” sorusuna cevap verir. Başvuru dosyasına göre işe başlamaktan ziyade, şirketin gerçek kapasitesine göre başvuru hazırlamak daha sürdürülebilir bir yaklaşımdır. Gerekirse proje aşamalarını yeniden düzenleyin; ancak bunu yalnızca takvim görünümünü güzelleştirmek için değil, teknik bağımlılıkları gözeterek yapın.

Bütçeyi üç ayrı bakışla okuyun

Karşılaştırmada toplam proje maliyeti, destek kapsamında değerlendirilebilecek giderler ve şirketin nakit ihtiyacı ayrı ayrı görülmelidir. Bu üç tutar aynı olmak zorunda değildir. Bir gider proje için gerekli olabilir fakat ilgili program açısından farklı değerlendirilebilir. Destek oranı hakkında genel bir bilgi duymak da hesabı tamamlamaz; çağrıya, şirket geçmişine ve gider kapsamına ilişkin koşullar kontrol edilmelidir. Bu yazı sabit oran üzerinden karar vermeyi önermemektedir.

Bütçe çalışmasında önce teknik ihtiyaçları fiyatlandırın. Sonra her kalemin güncel program kurallarıyla ilişkisini inceleyin. Son aşamada ödeme zamanlamasını şirketin nakit planına yerleştirin. Böylece destek kararı beklenirken hangi harcamaların yapılabileceği ve hangi kaynakların gerekli olduğu anlaşılır. İki programı karşılaştırırken yalnızca olası destek büyüklüğünü değil, dosyanın hazırlanması ve yürütülmesi için gereken yönetim kapasitesini de düşünün. Küçük bir ekibin raporlama, satın alma takibi ve teknik koordinasyon yükünü sahiplenmesi gerekir. Bu işler proje başarısının dışındaki bürokrasi değil, çalışmanın izlenebilir şekilde yürütülmesinin parçalarıdır.

Hazırlık takvimini geriye doğru planlayın

Son başvuru gününden geriye doğru hazırlık planı yapmak, eksiklerin daha erken görünmesini sağlar. Teknik kapsam üzerinde uzlaşma, bütçe kontrolü, idari bilgiler, son okuma ve gönderim farklı aşamalardır. Her aşama için sorumlu belirlenmezse bütün görevler son hafta kurucunun üzerinde toplanabilir. Proje başvurusu ekip işidir; fakat ekip işi olması sorumluluğun belirsiz kalmasını gerektirmez.

Geriye doğru planlama yaparken iç kontrol için zaman bırakın. Teknik liderin metni bitirdiği gün mali kontrolün de biteceğini varsaymayın. Bütçedeki bir değişiklik iş paketini, iş paketindeki bir değişiklik personel planını etkileyebilir. Son sürümü tek bir yerde tutun ve herkesin hangi belge üzerinde çalıştığını bilin. Farklı eposta eklerinden yürüyen düzen, son anda eski metnin gönderilmesine yol açabilir. Bu öneriler resmî başvuru adımlarının yerine geçmez; şirket içi koordinasyonu iyileştirir. Resmî sisteme ilişkin güncel yönlendirme için TÜBİTAK program sayfalarını ve PRODİS açıklamalarını kullanın. Özellikle yeni başlayan ekipler, teknik yazım kadar bu koordinasyon disiplinine de ihtiyaç duyar.

Değerlendirmeye hazırlanırken sunumu dosyayla uyumlu tutun

Bir proje hakkında yapılacak görüşmede en güçlü anlatım, dosyadaki mantığın ekip tarafından doğal biçimde açıklanabilmesidir. Slayt sayısının fazla olması veya teknik terimlerin yoğunluğu tek başına güven sağlamaz. Problem, yöntem, belirsizlik, çıktı ve kaynak ilişkisini kısa sürede anlatabilmelisiniz. Teknik soruya satış sloganıyla, bütçe sorusuna genel vizyon cümlesiyle cevap vermek konuyu dağıtır.

Ekip içinde prova yaparken farklı roller kullanabilirsiniz. Bir kişi teknik yöntemi, diğeri kaynak planını, başka biri ticarileşme varsayımlarını sorgulasın. Cevap veremediğiniz soruları başarısızlık olarak değil dosyayı geliştirme fırsatı olarak görün. TÜBİTAK'ın 1507 program sayfası değerlendirme boyutları arasında Ar-Ge içeriğini, proje planını ve ekonomik yarara dönüşümü sayar. Bu başlıkları ezberlemek yerine dosyanızda nerede karşılandıklarını gösterebilin. Kendi geliştirdiğiniz katkı ile dışarıdan alınan hizmeti açık ayırın. Bir teknik sonuç henüz bilinmiyorsa bunu kesinmiş gibi söylemeyin; hangi deneyle öğrenileceğini anlatın. Araştırma projesinde belirsizlik bulunması olağandır, açıklanmaması ise değerlendirmeyi zorlaştırır.

Program seçimi için kısa karar notu yazın

Ekip iki seçenek arasında tartışırken konuşmalar tekrar edebilir. Tek sayfalık karar notu bu tekrarları azaltır. Notta projenin amacı, şirketin ilgili geçmişi, kritik uygunluk soruları, teknik kapsam, kaynak ihtiyacı ve seçilen yol bulunur. Her avantajın yanında dayanağı, her belirsizliğin yanında çözüm sorumlusu yazılmalıdır. “Daha kolay” veya “daha büyük” gibi ifadeler tek başına gerekçe sayılmamalıdır.

Karar notunda alternatif yolu da kısa biçimde açıklayın. Neden şu an tercih edilmediğini bilmek, koşullar değiştiğinde yeniden değerlendirmeyi kolaylaştırır. Örneğin teknik kapsam henüz yeterince netleşmemişse bir sonraki döneme hazırlanmak, acele ve zayıf başvurudan daha anlamlı olabilir. Bunun maliyetini de görün: bekleme süresi boyunca araştırmanın nasıl finanse edileceği ve ekip planının nasıl sürdürüleceği açıklanmalıdır. Erteleme otomatik olarak doğru ya da yanlış değildir; gerekçeli bir yönetim kararıdır. Program seçimini kurucunun sezgisine bırakmak yerine teknik ve mali sorumluların aynı not üzerinde uzlaşması, uygulama dönemindeki sahiplenmeyi artırır.

Başvuru sonrası çalışma düzenini önceden düşünün

Birçok ekip başvuruya yoğunlaşırken destek kararı sonrasında işi nasıl yöneteceğini düşünmeyi erteler. Oysa proje kayıtları, görev dağılımı ve gider takibi sonradan kurulursa geçmiş faaliyetleri toplamak zorlaşır. Başvuru hazırlığı sırasında kullanılabilir bir dosya düzeni oluşturmak bu yükü azaltır. Teknik günlükler, deney sonuçları ve mali belgeler birbirleriyle ilişkilendirilebilir biçimde tutulmalıdır.

Planlanan ile gerçekleşeni karşılaştırmak için basit bir dönem özeti hazırlanabilir. Hangi çalışma tamamlandı, hangi sonuç çıktı, hangi varsayım değişti ve sıradaki karar nedir? Bu özet resmî raporun yerine geçmez, fakat resmî raporlama için temiz bir kaynak oluşturabilir. Teknik sapma olduğunda programın değişiklik ve bildirim kuralları ayrıca incelenmelidir. Şirket içinde ise sapmanın etkisi hızlıca değerlendirilmelidir. Bir deneyin uzaması yalnızca takvimi değil, personel yükünü ve nakit ihtiyacını da etkiler. Program seçiminde bu yönetim kapasitesini hesaba katmak, başvuru başarısını proje başarısına bağlayan önemli adımdır. Dosyayı göndermek yolculuğun başlangıcıdır.

BİGG ile şirket Ar-Ge programlarını aynı aşama sanmayın

Girişim ekosisteminde farklı program isimleri aynı konuşmada geçebilir. BİGG, 1507 ve 1501 hakkında duyulan bilgiler bu yüzden birbirine karışabilir. Şirketin mevcut durumu, başvuranın kim olduğu ve desteklenen çalışma türü açısından ilgili program metinleri ayrı okunmalıdır. Bir arkadaşınızın başka programda yaşadığı süreç, sizin başvurunuzun aynı şekilde ilerleyeceğini göstermez. Benzer kurum adı ortak olsa da mekanizmalar farklı olabilir.

BİGG hakkında genel hazırlık için BİGG başvuru süreci rehberine bakabilirsiniz. Bu yazının odağı ise şirketlerin Ar-Ge proje hazırlığı sırasında 1507 ve 1501 seçimini nasıl sorgulayacağıdır. Önce hangi aşamada olduğunuzu dürüstçe tarif edin: fikir doğrulama mı, teknik prototip mi, mevcut üründe yeni araştırma mı? Ardından programın başvuru sahibi ve proje koşullarıyla eşleştirin. Sırf başlığı tanıdık olduğu için bir programa yönelmek zaman kaybettirebilir. Doğru eşleşme, hazırlık emeğinin gerçekten değerlendirilebilir bir dosyaya dönüşmesini sağlar. Gerekli açıklama bulunmuyorsa varsayım üretmek yerine resmî iletişim kanallarından soru iletin.

Karar öncesi son kontrol

Son kontrolde dört dosyayı birlikte açın: güncel çağrı metni, teknik proje özeti, şirketin proje geçmişi ve bütçe. Bu dosyalar aynı hikâyeyi anlatıyor mu? Tarihler güncel mi? Şirket geçmişine ilişkin kayıtlar doğrulanmış mı? Teknik kapsamın tamamı bütçede karşılanmış mı? Cevabı açık olmayan sorular için sorumlu belirleyin. Başvuru hazırlığında bütün belirsizliklerin yok olması beklenmez; hangi belirsizliğin teknik araştırmaya, hangisinin eksik bilgiye ait olduğunu ayırmak gerekir.

Orion TEKMER ile ilk değerlendirme görüşmesi yapmak isteyen ekipler ön başvuruda proje hedefini, mevcut aşamayı ve program seçimindeki sorularını paylaşabilir. Merkez veya danışman desteği hazırlığı kolaylaştırabilir; uygunluk ve destek kararı ise ilgili kurumun değerlendirmesine bağlıdır. Sağlam seçim, daha yüksek rakamı takip etmekten çok şirketin gerçekten yürütebileceği araştırmayı doğru çerçevede sunmaktır. Teknik doğruluk, kaynak gerçekçiliği ve uygulama disiplini bir araya geldiğinde başvuru dosyası şirketin gelişim planına hizmet eder. Bu yaklaşım tek bir çağrı için değil, sonraki Ar-Ge projeleri için de tekrar kullanılabilecek düşünme alışkanlığı kazandırır.

Sık sorulan sorular

1507 her yeni şirket için otomatik olarak doğru seçim midir?

Hayır. Şirketin yaşı veya yeni olması tek başına program seçimini tamamlamaz. Güncel çağrının başvuru sahibi, proje geçmişi ve diğer koşulları incelenmelidir. Teknik kapsam ve ekip kapasitesi de kararın önemli parçalarıdır.

1501 seçmek daha yüksek destek almayı garanti eder mi?

Hayır. Talep edilen bütçe, değerlendirilen gider ve sonuçta sağlanabilecek destek aynı kavramlar değildir. Çağrı koşulları ve kurum değerlendirmesi belirleyicidir. Program adından hareketle kesin mali sonuç çıkarılmamalıdır.

Ön kayıt tarihi ile çağrı kapanışı aynı mıdır?

Her zaman aynı değildir. Bu yazıda kontrol edilen 2026 ikinci çağrı takviminde ayrı tarihler bulunur. Şirket içi takviminizde iki adımı da görünür tutun ve güncel resmî duyuruyu gönderim öncesinde tekrar inceleyin.

Eski başarılı dosyayı değiştirip yeniden kullanmak yeterli olur mu?

Eski dosya yapı açısından yardımcı olabilir; ancak yeni teknik hedef, güncel kurallar, personel ve bütçe yeniden değerlendirilmelidir. Önceki projenin sonuçlarını yeni proje vaadi gibi sunmayın. Her yeni dosya kendi araştırma sorusunu açıkça taşımalıdır.

İki programı karşılaştırmak için hangi belgeyi önce hazırlamalıyız?

Program adından bağımsız kısa teknik proje özetini hazırlamak yararlı bir başlangıçtır. Bu özette problem, mevcut durum, teknik belirsizlik, önerilen yaklaşım ve beklenen çıktı yer alır. Daha sonra şirketin geçmiş proje tablosu ve kaynak planı eklenir. Böylece karşılaştırma soyut avantajlar üzerinden değil aynı somut proje üzerinden yapılır. Ekip görüş değiştirdiğinde hangi varsayımın değiştiğini de görebilir. Belgeyi uzun tutmak zorunda değilsiniz; önemli olan kararın dayanaklarının açık olmasıdır.

Başvuru yetişmiyorsa kapsamı hızla küçültmek doğru mudur?

Yalnızca son tarihe yetişmek için kritik deneyleri veya doğrulamaları çıkarmak projenin bütünlüğünü bozabilir. Kapsam değişikliği teknik hedefi yeniden tanımlamayı gerektiriyorsa bu çalışma için yeterli zaman ayırın. Erteleme, kapsam daraltma ve mevcut planla ilerleme seçeneklerinin kaynak etkisini karşılaştırın. Hangi yolu seçerseniz seçin, dosyanın gerçek çalışma planınızı yansıtması gerekir. Son güne yetişmiş fakat ekip tarafından sahiplenilmeyen bir metin, uygulama döneminde daha büyük zaman kaybı yaratabilir.