Startup Hibe ve Teşvikleri: Başvuru Rehberi

Hibe başvurusu fikirden önce hazırlanır

Startup kurarken para bulma konusu çoğu ekipte ürün fikrinin hemen ardından açılıyor. Hangi programa başvuralım, ne kadar destek alırız, başvuru ne zaman kapanıyor? Sorular yerinde. Fakat startup hibe ve teşviklerini yalnızca bir form doldurup karşılıksız para beklemek sanmak, dosyada daha ilk sayfadan kendini belli ediyor.

Ben başvuruyu üç parçalı bir iş olarak ele alıyorum: doğru programa uygunluk, ölçülebilir proje planı ve harcamaların kanıtlanabilir biçimde yönetilmesi. Bir parça eksikse iyi fikir bile zayıf görünür. Teknik ekipler genellikle ürünün ne kadar iyi olduğunu anlatıyor; projenin hangi riski, hangi faaliyetle azaltacağını ise yeterince açıklamıyor.

Türkiye’de program adları, bütçeler, çağrı tarihleri ve uygun gider kuralları değişebilir. Bu nedenle aşağıdaki çerçeveyi kullanırken güncel şartları ilgili kurumun resmi duyurusundan kontrol edin. Eski bir blog yazısındaki uygunluk maddesine güvenerek bütçe kurmak, takvimi kaçırmanın pahalı yollarından biri.

Hangi destek türü size uyuyor?

İlk ayrım, aradığınız paranın ne için kullanılacağıdır. Şirket kuruluşu, Ar-Ge, personel, makine, yazılım lisansı, prototip veya pazara çıkış aynı programın içinde bulunmayabilir. “Startup desteği” diye tek bir torba yok; farklı kurumların farklı amaçlara göre hazırladığı programlar var.

KOSGEB’in girişimci odaklı programları şirketin kuruluş süresi, faaliyet kodu, girişimcinin eğitimi ve gider kalemlerine göre değerlendirilir. TÜBİTAK’ın BiGG ve TEYDEB kapsamındaki programları ise teknoloji ve Ar-Ge niteliğini daha belirgin biçimde sorgular. Kalkınma ajansları, bakanlıklar ve bazı kamu kurumları dönemsel çağrılar açabilir.

Buradaki ayrım kritik: Yalnızca bir uygulama geliştiriyor olmanız projenin otomatik olarak Ar-Ge olduğu anlamına gelmez. Daha önce herkesin kullandığı bir e-ticaret uygulamasını farklı renklerle sunmak yenilik iddiasını desteklemez. Çözülmesi gereken teknik belirsizlik, denenecek yöntem ve ölçülebilir çıktı gerekir.

Başvurmadan önce uygunluğu kontrol edin

Başvuru formunu açmadan bir uygunluk tablosu hazırlayın. Şirket türü, kuruluş tarihi, NACE kodu, ortaklık yapısı, vergi ve SGK durumu, daha önce alınan destekler, proje süresi ve harcama kalemleri bu tabloda yer alsın. İki saatlik bu çalışma, günlerce yazılan ama programa uymayan bir dosyayı engelleyebilir.

Şirket yaşı ve faaliyet kodu

Bazı destekler yeni kurulan işletmeleri, bazıları belirli bir süre faaliyet gösteren şirketleri hedefler. Faaliyet kodu da yalnızca vergi levhasındaki teknik bir satır değildir. Başvurudaki iş modeli, bütçe ve şirket faaliyet kodu birbiriyle çelişirse değerlendirici doğal olarak soru sorar.

Bir yazılım şirketinin ana faaliyet kodu üretim, projesi ise yapay zekâ tabanlı SaaS olarak anlatılıyorsa bu farkı açıklamak gerekir. Gerekirse mali müşavirle faaliyet kodunun projeyi doğru yansıtıp yansıtmadığını baştan görüşün. Sonradan kod değiştirmenin her programda uygunluk sorununu çözeceği varsayımı güvenli değildir.

Ortaklar ve başvuru sahibi

Girişimcinin yaşı, eğitimi, şirketteki payı, yönetimdeki rolü ve önceki şirket deneyimi programdan programa değişen koşullardır. Kurucu ekipte herkesin adı geçiyor diye herkesin proje sorumlusu olması gerekmez. Kim teknik lider, kim ticari sorumlu, kim bütçe ve operasyonu yönetecek; dosya bunu açıkça göstermeli.

Başvuru öncesinde ortaklık yapısını da temizleyin. Bir kurucunun payı, oy hakkı veya görev tanımı belgelerde farklı görünüyorsa bu durum yatırım görüşmelerinde olduğu kadar hibe değerlendirmesinde de gereksiz risk yaratır. Startup Cap Table Nedir? Hisse Dağılımı Rehberi başlıklı içerikte bu yapının nasıl okunacağını ayrıca anlatmıştık.

Programları resmi kaynaklardan karşılaştırın

Google’da üst sıralarda çıkan eski bir duyuru, bugün açık bir çağrı anlamına gelmez. Ben önce kurumun resmi program sayfasını, başvuru kılavuzunu, soru-cevap dokümanını ve varsa eklerini indiriyorum. Sonra son başvuru tarihiyle yetinmeyip uygun gider, ödeme yöntemi, raporlama ve sözleşme maddelerini ayrı ayrı işaretliyorum.

Şu soruların yazılı cevabını bulmadan bütçe hazırlamayın:

• Başvuru yalnızca şirket tarafından mı, yoksa uygulayıcı kuruluş veya aracı kurum üzerinden mi yapılıyor?
• Destek peşin mi, geri ödemeli mi, yoksa harcama sonrası ödeme şeklinde mi?
• KDV, maaş, danışmanlık, sunucu, lisans, seyahat ve pazarlama giderleri uygun mu?
• Ortaklardan veya ilişkili şirketlerden yapılan alımlar için sınırlama var mı?
• Proje süresi uzatılabiliyor mu ve değişiklik için ön onay gerekiyor mu?
• Harcama belgesi, banka dekontu, bordro veya teknik rapor hangi formatta isteniyor?

Bir destek kaleminin listede bulunması, bütçenin tamamının karşılanacağı anlamına gelmez. Üst limit, destek oranı ve çağrı koşulları ayrıca uygulanabilir. Kılavuzda anlaşılmayan bir madde varsa kuruma yazılı soru sorun; telefon görüşmesindeki sözlü yorumu tek dayanak yapmayın.

Proje fikrini değerlendiriciye anlatın

İyi bir başvuru “platformumuz yapay zekâ kullanıyor” cümlesiyle başlamaz. Önce hangi müşterinin hangi problemini çözdüğünüzü, mevcut çözümlerin neden yetersiz kaldığını ve projenin hangi teknik veya ticari belirsizliği azaltacağını anlatın.

Problem ve müşteri

Problemi genel ifadelerle bırakmayın. “KOBİ’ler verilerini yönetemiyor” yerine, belirli bir kullanıcı grubunun bugün hangi işlemi kaç adımda yaptığı, nerede zaman veya para kaybettiği ve çözümünüzün bu akışı nasıl değiştirdiği daha değerlidir.

Müşteri görüşmeleri, pilot kullanıcı kayıtları, ön siparişler, niyet mektupları veya ölçümlenmiş kullanım verileri bu iddiayı güçlendirir. Henüz müşteriniz yoksa bunu saklamaya çalışmayın; doğrulama planınızı ve hangi varsayımı hangi deneyle test edeceğinizi yazın.

Teknik yenilik ve risk

Ar-Ge dosyasında risk bulunması zayıflık değildir. Asıl sorun, hiç risk yokmuş gibi yazmaktır. Modelin farklı veri kalitesinde kabul edilebilir doğruluk verip vermeyeceği, yüksek trafik altında gecikmenin korunup korunamayacağı veya mevcut sistemlerle entegrasyonun nasıl yapılacağı teknik risk olarak yazılabilir.

Her risk için yöntem, başarı ölçütü ve alternatif plan belirtin. “Performansı artıracağız” yerine “yük testi sonunda p95 yanıt süresini belirlenen eşik altında tutacağız” gibi ölçülebilir bir hedef kurun. Eşiği ürünün gerçek kullanım senaryosuna göre seçin; sırf güzel görünsün diye ölçülemeyecek hedef yazmayın.

Bütçeyi ihtiyaçtan türetin

Bütçe, almak istediğiniz ürünlerin listesi değildir. Proje faaliyetlerinin mali karşılığıdır. Önce iş paketlerini yazın, sonra her paketin gerektirdiği insan gücü, yazılım, donanım ve hizmeti hesaplayın.

Örnek bir iş paketi şu şekilde kurulabilir: veri toplama ve anonimleştirme, prototip algoritma, entegrasyon, güvenlik testleri, pilot kullanım ve ticarileştirme. Her pakette sorumlu kişi, başlangıç-bitiş tarihi, çıktı ve tahmini maliyet yer alsın. Böylece bütçe kalemiyle proje takvimi birbirini doğrular.

Personel bütçesinde yalnızca brüt maliyeti değil, destek programının kabul ettiği hesap yöntemini dikkate alın. Sunucu ve lisans giderlerinde de “bulut maliyeti” gibi geniş bir ifade kullanmayın. Hangi hizmet, hangi dönem, kaç kullanıcı veya hangi kapasite için alınacak; bunları açıklayın.

Benim pratik kuralım şu: Bir gideri başvuru metninde tek cümleyle savunamıyorsanız, o gider henüz olgunlaşmamıştır. Ayrıca hibe ödemesi gecikebilir. Harcamayı önce sizin yapmanız bekleniyorsa nakit akışını ayrı bir tabloyla planlayın. Kâğıt üzerinde finanse edilen ama banka hesabında karşılığı olmayan proje, uygulamada yürümüyor.

Başvuru dosyasını kanıtlarla güçlendirin

Değerlendirici ekibin sizi tanıma şansı çoğu zaman dosyayla sınırlıdır. Bu nedenle iddiaların yanına kanıt koyun. Kullanıcı görüşme notları, prototip ekranları, teknik mimari, rakip karşılaştırması, pilot niyet mektubu, ekip özgeçmişi ve varsa gelir verileri tek bir düzen içinde sunulabilir.

Ek belge sayısını artırmak tek başına kalite değildir. On beş sayfalık tekrar yerine, kritik varsayımı kanıtlayan iki sayfalık bir ek daha etkilidir. Dosya adlarını anlaşılır tutun; örneğin WP3_guvenlik_test_plani_v1.pdf adı, son_son_final2.pdf isminden daha az hata üretir.

Teknik girişimlerde mimari şema da yararlı olur. Kullanıcı verisi nerede tutuluyor, hangi servisler birbiriyle konuşuyor, yedekleme ve erişim yetkileri nasıl yönetiliyor? KVKK açısından kişisel veri işleniyorsa veri minimizasyonu ve saklama yaklaşımınızı da açıklayın. Güvenlik sonradan eklenen bir paragraf değil, ürün planının parçası olmalı.

Takvimi ve nakit akışını birlikte yönetin

Başvuru tarihi projenin başlangıç tarihi değildir. Değerlendirme, sözleşme, revizyon ve ilk ödeme arasında bekleme olabilir. Bu dönemde ekip maaşı, sunucu, muhasebe ve müşteri operasyonu devam eder.

Aylık nakit akışında en az üç senaryo hazırlayın: destek beklenenden erken gelirse, gecikirse ve hiç onaylanmazsa. Her senaryoda hangi harcamayı erteleyeceğiniz önceden yazılı olsun. Böylece başvuru sonucu geldiğinde panikle ürün yönünü değiştirmezsiniz.

Başvuru dosyasında proje süresini gereksiz yere kısa tutmak da hata. Kısa takvim iddialı görünür ama personel, tedarik ve test süreleri gerçekçi değilse revizyon ihtimali artar. Gereksiz uzun takvim de ekibin işi bitiremeyeceği izlenimi yaratabilir. Her tarihin bir gerekçesi olsun.

Başvuru sonrası denetim başlar

Destek onaylandığında iş bitmez; kayıt düzeni başlar. Sözleşmede istenen faturaları, banka hareketlerini, bordroları, satın alma belgelerini, teslim tutanaklarını ve teknik ilerleme kanıtlarını proje klasöründe tutun. Harcamayı kişisel kartla yapıp sonradan düzeltmeye çalışmak ileride açıklama yükünü artırır.

Değişiklik ihtiyacı doğarsa önce programın onay prosedürünü kontrol edin. Personel değişikliği, bütçe aktarımı, takvim kayması veya yeni tedarikçi kullanımı bazı programlarda ön bildirim ister. “Nasıl olsa aynı tutar” yaklaşımı burada güvenli değildir.

Basit bir klasör yapısı iş görür:

proje-dosyasi/<br>  00-sozlesme-ve-kilavuz/<br>  01-basvuru/<br>  02-butce-ve-faturalar/<br>  03-bordro-ve-personel/<br>  04-teknik-raporlar/<br>  05-satin-alma/<br>  06-yazisma-ve-onaylar/

Burada yaptığımız şey yalnızca dosyaları sınıflandırmak değil; her harcamanın hangi iş paketine ve hangi onaya bağlı olduğunu sonradan izlenebilir hale getirmek. Yedekleri de aynı bilgisayarda bırakmayın.

Bir ekipte proje arşivini tek bir kurucunun bilgisayarında bulmuştuk. Bilgisayarın diski arızalanınca dosyalar geri geldi ama satın alma onaylarının eski sürümleri yoktu. O günden beri proje klasörlerinde sürüm adı, erişim yetkisi ve ayrı bir yedek kopya olmadan dosya teslim etmiyorum. Var görünen dosya, açılamıyorsa kanıt değildir.

İlk başvuruda sık yapılan hatalar

• Programı fikre uydurmak: Çağrının amacıyla örtüşmeyen projeyi yalnızca bütçe var diye zorlamak.
• Ar-Ge ile özellik listesini karıştırmak: Uygulamaya beş yeni ekran eklemek, tek başına teknik yenilik sayılmaz.
• Gelir tahminini kanıtsız yazmak: İlk yılda binlerce müşteriye ulaşma hedefini kanal, maliyet ve kapasiteyle açıklamamak.
• Ekibi belirsiz bırakmak: Projeyi kimin yürüteceği ve kritik yetkinliğin ekipte bulunup bulunmadığını göstermemek.
• Nakit ihtiyacını küçümsemek: Geri ödeme veya harcama sonrası destek yapısını hesaba katmamak.
• Belgeleri son güne bırakmak: Vergi, imza, teklif, ortaklık ve banka kayıtlarını başvuru ekranı kapanırken toplamaya çalışmak.
• Her gideri yazmak: Projeyle ilişkisi zayıf ekipman veya pazarlama harcamalarıyla bütçeyi şişirmek.

Bir ekipte proje arşivinin tek bilgisayarda tutulması, başvuru sonrası denetimde eksik belge sorununa dönmüştü. Sunucu faturaları duruyordu ama hangi faturanın hangi iş paketine bağlandığı ve kim tarafından onaylandığı belli değildi. Klasör yapısını, sürüm adlarını ve onay kayıtlarını baştan kurduk. Benim orada aldığım ders basitti: Belgeyi saklamak yetmiyor; belgeyle faaliyet arasındaki bağlantıyı da saklamak gerekiyor.

Başvuru dosyasını iş planıyla bağlayın

Hibe dosyası yatırımcı sunumu değildir, fakat iş modelinden kopuk da olamaz. Ürün yol haritasında yer alan ilk sürüm, pilot müşteri ve teknik borçlar bütçedeki faaliyetlerle aynı sırada görünmeli. Startup Ürün Yol Haritası Nasıl Hazırlanır? başlıklı içerikte bu sıralamayı ürün kararlarıyla birlikte ele almıştık.

Pazara çıkış planında da soyut hedeflerden kaçının. Hangi müşteri segmentine önce ulaşacaksınız, satış kanalı nedir, pilot kullanıcıyı nasıl bulacaksınız, deneme süresinden ücretli kullanıma geçişi nasıl ölçeceksiniz? Startup İçin Go-to-Market Stratejisi Nasıl Kurulur? içeriğindeki sorular, hibe dosyasının ticarileşme bölümünü somutlaştırmak için kullanılabilir.

Müşteri edinme maliyetini hesaplarken yalnızca reklam harcamasını dikkate almayın. Satış görüşmeleri, demo hazırlığı, kurulum ve destek zamanı da gerçek maliyettir. Startup CAC Nasıl Hesaplanır? Müşteri Edinme Maliyeti yazısında bu kalemleri ayrı tutmanın neden gerekli olduğunu örneklemiştik. Hibe ile geliştirilen ürünün destek bittikten sonra nasıl yaşayacağı, değerlendiricinin görmek istediği temel cevaplardan biridir.

Başvuru öncesi son kontrol

Formu göndermeden önce dosyayı projeye dışarıdan bakan birine okutun. Bu kişi teknik ayrıntıyı bilmiyorsa daha iyi; anlaşılmayan yerleri işaretler. Sonra teknik ekibiniz, mali müşaviriniz ve başvuru koşullarını bilen bir danışmanla üç ayrı kontrol yapın.

• Şirket, ortak ve faaliyet kodu şartları sağlanıyor mu?
• Her faaliyet için ölçülebilir çıktı ve sorumlu kişi var mı?
• Bütçe, takvim ve iş paketleri aynı hikâyeyi anlatıyor mu?
• Gelir ve pazar iddialarının kanıtı bulunuyor mu?
• Destek oranı dışında kalan tutar için nakit planı hazır mı?
• Uygun gider, satın alma ve raporlama kuralları okunmuş mu?
• Başvuru ekleri açılıyor, imzalar ve tarihler doğru görünüyor mu?
• Başvuru numarası ve gönderim kaydı güvenli bir yerde saklandı mı?

Startup hibe ve teşvikleri, iyi kurulmuş bir iş planının yerine geçmez. Doğru kullanıldığında teknik riski azaltırken ekibin daha kontrollü ilerlemesini sağlayabilir. Ben olsam önce tek bir programa odaklanır, uygunluk tablosunu çıkarır, ardından üç aylık faaliyet ve nakit planını hazırlamadan form ekranına geçmezdim. Başvuru öncesinde kendinize şu soruyu sorun: Destek onaylanmasa bile bu proje hangi kanıtla ve hangi küçük adımla ilerleyebilir?

Sık Sorulan Sorular

Startup hibe başvurusu için şirket kurmak zorunlu mu?

Programa göre değişir. Bazı girişimcilik desteklerinde başvuru veya destek sözleşmesi aşamasında şirket şartı aranırken, bazı ön kuluçka ve girişim programlarında fikir aşamasındaki ekipler de sürece dahil olabilir. Güncel çağrının başvuru sahibi ve şirket kuruluşu maddelerini kontrol edin.

Hibe desteği geri ödenir mi?

Karşılıksız destekler, şartlara uygun harcama ve raporlama yapıldığında geri ödeme gerektirmeyebilir. Geri ödemeli destekler, eş finansman veya sözleşmeye aykırılık halinde doğabilecek iade koşulları farklıdır; programın sözleşmesini okumadan “hibe” kelimesine güvenmeyin.

Sunucu ve yazılım lisansı giderleri desteklenir mi?

Bazı programlar bu giderleri uygun kabul eder, bazıları sınırlar veya yalnızca belirli proje faaliyetleriyle ilişkilendirildiğinde kabul eder. Hizmetin süresi, kapasitesi, faturası ve projedeki kullanım amacı bütçede açıkça gösterilmelidir.

Birden fazla startup desteğine aynı anda başvurulabilir mi?

Başvuru yapmak ile aynı gider için iki ayrı destek almak farklı konulardır. Programların mükerrer finansman, devam eden proje ve kamu desteğiyle çakışma kurallarını kontrol edin; aynı personel veya faturayı iki projede göstermek ciddi sorun çıkarabilir.