Yazılım firması seçerken dikkat edilmesi gerekenler: KOBİ rehberi

Yazılım firması seçmek, ihtiyacınızı yazıya döktüğünüz, aynı kapsamı birkaç firmaya sorduğunuz, cevapları ortak ölçütlerle puanladığınız ve sonucu sözleşmeyle güvenceye aldığınız bir satın alma sürecidir. Yazılım firması seçerken dikkat edilmesi gerekenler dört başlıkta toplanır: kapsamın netliği, firmanın bu kapsamı yapabileceğine dair kanıt, tekliflerin karşılaştırılabilirliği ve kod, hesap ve fikri haklar üzerindeki kontrolünüz.

Öne çıkanlar

• İlk karar firmayla ilgili değil: önce hazır bir ürünün işinizi görüp görmediğini sorun. TÜBİTAK BİLGEM'in tedarik rehberi de buradan başlar.
• Teklifleri karşılaştırılabilir kılmanın yolu, tüm firmalara aynı ihtiyaç belgesini göndermektir.
• Referans kontrolü, referans listesini okumak değil; o referanslarla konuşmaktır.
• Fikir ve Sanat Eserleri Kanunu md. 52'ye göre mali haklara dair sözleşmeler yazılı olmalı ve devredilen haklar ayrı ayrı gösterilmelidir.
• Kod deposu, alan adı, bulut ve mağaza hesaplarının kimin adına açılacağı, sözleşmeden önce konuşulması gereken konulardır.

Önce ne alacağınızı netleştirin: hazır ürün mü, geliştirme mi?

Doğru firmayı aramadan önce doğru işi tanımlamak gerekir. Muhasebe, bordro ya da çağrı merkezi gibi standart işler için iyi hazır ürünler vardır; bu durumda aradığınız şey bir yazılım geliştirme firması değil, bir ürün ve onu kuracak bir iş ortağıdır.

TÜBİTAK BİLGEM'in Uygulama Yazılımı Tedariki Rehberi (yeni sekmede açılır) (2017), kontrol sorularının başına bunu koyar: alınacak yazılımın paket mi, yoksa ihtiyaçlar doğrultusunda hazırlanacak özel yazılım mı olacağı sorgulanmalıdır. Bu kararı nasıl vereceğinizi hazır yazılım mı özel yazılım mı yazımızda toplam maliyet üzerinden anlattık.

Aşağıdaki bölümler, özel geliştirme ya da kapsamlı bir uyarlama için firma seçtiğiniz durumu ele alır. Pek çok küçük işletme bu kararı teknik bir çalışan olmadan verir. TÜİK'in Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, 2026 (yeni sekmede açılır) bültenine göre 10–49 çalışanlı girişimlerin %10,8'i bilgi ve iletişim teknolojileri uzmanı istihdam ediyor (10 Eylül 2026'da yayımlandı). Aşağıdaki adımlar, bu açığı yöntemle kapatmak için yazıldı.

Seçim süreci adım adım

Sıra şöyledir: ihtiyacı yazın, kısa liste çıkarın, herkese aynı belgeyi gönderin, aynı ölçütlerle puanlayın, referansları arayın ve sözleşmeyi imzalamadan önce hakları netleştirin.

1. İhtiyaç belgesini hazırlayın. Kimler kullanacak, hangi işleri yapacak, hangi sistemlerle konuşacak, hangi tarihe yetişmeli? Mükemmel olması gerekmez; bildiğiniz kadarı yeterlidir. Şablon için yazılım ihtiyaç analizi yazımıza bakabilirsiniz.
2. Uzun listeden kısa listeye inin. Benzer büyüklükte ve benzer türde iş yapmış firmaları arayın. Kısa liste, karşılaştırma yapabileceğiniz kadar geniş, görüşmelerini yürütebileceğiniz kadar dar olmalıdır.
3. Gerekirse gizlilik sözleşmesi imzalayın. İş fikriniz ya da verileriniz hassassa ayrıntıları paylaşmadan önce karşılıklı NDA isteyin. Neyi koruyup neyi korumadığını gizlilik sözleşmesi (NDA) yazımızda anlattık.
4. Herkese aynı belgeyi ve aynı soru listesini gönderin. Farklı brif alan firmalar farklı işleri fiyatlar; o zaman teklifler yan yana konamaz.
5. Teknik görüşme yapın. Sunumu dinlemek yerine projenizden bir senaryoyu birlikte konuşun. Firmanın nasıl soru sorduğu, nasıl cevap verdiğinden çok şey söyler.
6. Referansları arayın. Aşağıdaki soru listesini kullanın.
7. Puanlayın ve kararı yazılı kaydedin. BİLGEM'in Yazılım Geliştirme Rehberi (yeni sekmede açılır) (2017) de değerlendirmenin önceden belirlenen ölçütlere göre yapılmasını ve kararın yazılı olarak kayıt altına alınmasını önerir.
8. Sözleşmeyi hazırlayın. Kapsam, kabul, haklar, bakım ve çıkış koşulları yazılmadan işe başlamayın.

Teklifleri karşılaştırmak: fiyattan önce kapsamı okuyun

Aynı işe verilen iki teklif arasındaki farkı önce kapsamda arayın. Bu yüzden teklif karşılaştırması toplam rakamla değil, "bu teklif neyi kapsıyor, neyi kapsamıyor?" sorusuyla başlar.

Her teklifte şu satırları arayın:

• Kapsam ve varsayımlar. Hangi ekranlar, roller ve entegrasyonlar dahil? Firma neyi varsaymış?
• Hariç tutulanlar. İyi bir teklif kendi dışında kalanları da adıyla yazar: barındırma, lisanslar, içerik girişi, veri temizliği gibi.
• Teslimler. Kaynak kod, teknik doküman, kurulum notları ve test sonuçları teslimin parçası mı?
• Takvim. Takvim kapsamla birlikte mi verilmiş, yoksa kapsamdan bağımsız bir söz mü?
• Çalışma modeli. Sabit fiyat mı, zaman ve kaynak mı, aylık ekip mi? Her biri riski farklı paylaştırır; ayrıntılar fiyatlandırma modelleri yazımızda.
• Ödeme planı. Ödemeler teslimlere ve kabul adımlarına bağlı mı?
• Bakım teklifi. BİLGEM'in rehberi bakım fiyat teklifinin de istenmesini ve teklifin geçerlilik süresinin hizmet alımı sonrasına denk gelmesine dikkat edilmesini önerir.

Geliştirme teklifi bütçenin yalnızca bir satırıdır. Teklifte görünmeyen kalemleri yazılım projesi bütçe planlama yazımızda 12 başlıkta topladık.

Teknik görüşmede sorulacak sorular

Teknik görüşme, firmanın sizin projenizi nasıl yürüteceğini somut sorularla sınadığınız toplantıdır. Amaç teknik ayrıntıyı denetlemek değil, cevabın netliğini görmektir. Belirsiz bir soruya "duruma göre" demek normaldir; ama durumun neye bağlı olduğunu da söyleyebilmek gerekir.

Şu soruları sorun ve cevapları not alın:

• Projemizde sizce en riskli kısım hangisi? Bu riski nasıl küçültürsünüz?
• Projede kimler çalışacak? Bu kişilerle tanışabilir miyiz?
• Çalışan sürümü ne sıklıkla görebileceğiz? Nereden izleyeceğiz?
• Bir değişiklik istediğimizde süreç nasıl işler? Fiyat ve takvime etkisi nasıl yazılır?
• Testleri kim, nasıl yapıyor? Kabul testlerinde bizden ne bekliyorsunuz?
• Güncellemeler canlı sisteme nasıl çıkıyor? Bir şey bozulursa nasıl geri dönülüyor?
• Kişisel verileri nasıl koruyorsunuz? Kimin hangi veriye erişeceğini nasıl sınırlıyorsunuz?
• Proje bittiğinde elimizde hangi belgeler, erişimler ve hesaplar olacak?

İyi bir cevap bazen bir soruyla başlar. Firma sizin işinizi anlamadan çözüm anlatıyorsa, bu da bir bilgidir.

Puanlama matrisi şablonu

Puanlama matrisi, firmaları aynı ölçütlerle ve önceden belirlenmiş ağırlıklarla değerlendirmenizi sağlayan bir tablodur. Ağırlıkları teklifler gelmeden önce yazın; sonra yazılan ağırlıklar, beğenilen teklife göre ayarlanır.

Her ölçüte 1 ile 5 arasında puan verin, ağırlıkla çarpın ve toplayın. Aşağıdaki ağırlıklar yalnızca bir örnektir; kendi önceliklerinize göre değiştirin.

Fiyatı tek başına en ağır ölçüt yapmayın. Fiyat, kapsam ve risk birlikte okunduğunda anlam kazanır.

Referans kontrolünde sorulacak sorular

Referans kontrolü, firmanın gösterdiği bir müşteriyle doğrudan konuşup projenin nasıl yürüdüğünü öğrenmektir. BİLGEM'in tedarik rehberi de referans listesindeki kurumlardan görüş alınmasını değerlendirme ölçütleri arasında sayar.

Görüşmede şu soruları sorun:

1. Proje ilk planlanan kapsamla mı bitti? Kapsam değiştiyse bu nasıl yönetildi?
2. Takvim kaydığında firma bunu ne zaman ve nasıl haber verdi?
3. Proje boyunca muhatabınız aynı kişi miydi?
4. Çalışan sürümü proje sırasında görebiliyor muydunuz?
5. Teslimde kaynak kod, dokümantasyon ve hesap erişimleri eksiksiz verildi mi?
6. Yayından sonra hata bildirdiğinizde neler oldu?
7. Bugün aynı işi yeniden yaptıracak olsanız neyi farklı yapardınız?
8. Bu firmayla tekrar çalışır mıydınız? Neden?

Yalnızca memnun müşterilerin referans olarak verilmesi doğaldır. Bu yüzden genel övgüyü değil, somut olayları dinleyin: bir sorun nasıl çözüldü, kim üstlendi, ne kadar açık konuşuldu?

Riski küçük bir ilk aşamayla azaltın

Bütün projeyi tek seferde bağlamak yerine kısa ve ücretli bir ilk aşamayla başlamak, seçimi işin içinde sınamanın pratik bir yoludur. Bu aşama genellikle bir keşif çalışmasıdır: süreç birlikte incelenir, kapsam belgesi yazılır ve ana akışlar bir prototiple denenir.

Bu yöntemin iki faydası vardır. Birincisi, firmayla gerçekten çalışmanın nasıl olduğunu sunumdan değil, işin içinden görürsünüz. İkincisi, aşamanın sonunda elinizde başka bir firmaya da verebileceğiniz bir kapsam belgesi kalır.

BİLGEM'in Yazılım Geliştirme Rehberi de kilometre taşlarının kısa tutulmasını ve arada gözden geçirmelere pay bırakılmasını önerir. Sözleşmeyi aşamalara bölmek, her aşamanın sonunda devam etme ya da durma kararını size bırakır.

Hazır ürün ve kurulum ortağı seçiyorsanız

Hazır bir ürün alıp onu bir iş ortağıyla kuruyorsanız, firma seçimine ürün seçimi de eklenir. BİLGEM'in Uygulama Yazılımı Tedariki Rehberi bu durum için birkaç somut kontrol önerir:

• Lisanslama modeli. Ücretin kullanıcı, sunucu, işlemci ya da çekirdek başına mı hesaplandığını; yönetici ve görüntüleyici gibi farklı kullanıcı tipleri için farklı lisans olup olmadığını sorun. Uzun vadedeki olası artışları da düşünün.
• Entegrasyon yeteneği. Ürünün kullandığınız ERP, CRM gibi sistemlerle hazır bağlantısı var mı? Yoksa bu bağlantı ek maliyet mi doğuracak?
• Modülerlik. İhtiyacınız olmayan modülleri satın almadan kullanabilir misiniz?
• Demo ya da kavram ispatı. Ürünü kendi senaryonuzla, bir deneme ortamında görün.
• Kurulum ortağının deneyimi. Benzer projelerdeki referanslar ve referans projelerin büyüklüğü, karmaşıklığı ile hangi noktalarda dış kaynak kullanıldığı.
• Kendi ekibiniz. Devreye alma ve işletme sırasında süreci yürütecek yeterli ve yetkin personeliniz var mı? Yoksa eğitim ya da dış destek anlaşmanın parçası olmalı.

Sizin tarafınızda hazır olması gerekenler

İyi bir firma seçmek, projenin yalnızca yarısıdır; diğer yarısı sizin tarafınızda yürür. BİLGEM'in Yazılım Geliştirme Rehberi de yüklenici kullanılacaksa kurumun yüklenici yönetimindeki tecrübesinin ve olgunluğunun göz önünde bulundurulmasını önerir.

Sözleşmeyi imzalamadan önce şunları belirleyin:

• Ürün sahibi. Firmanın sorularını cevaplayacak ve öncelik kararını verecek tek bir kişi. Bu kişinin takviminde projeye yer açılmalı.
• Karar yetkisi. Hangi kararları ürün sahibi tek başına verebilir, hangileri yönetimden geçer?
• Test verisi ve test kullanıcıları. Kabul testlerini gerçek senaryolarla yapacak çalışanlar.
• Erişimler. Entegre edilecek sistemlerin bağlantı bilgileri, test hesapları ve karşı firmaların iletişim kişileri.
• Geri bildirim ritmi. Çalışan sürümü kimin, ne sıklıkla inceleyeceği.

Bu hazırlık eksik kaldığında iyi bir teklifin takvimi de tutmaz. Bir gecikmenin sebebi bazen kodda değil, beklenen bir kararın ya da erişimin gelmemesindedir.

Resmî kayıtlardan neyi kontrol edebilirsiniz?

Bir firmanın tüzel kişiliğini ve temel değişikliklerini resmî kayıtlardan görebilirsiniz. Bu kontrol kaliteyi ölçmez, ama sözleşme yaptığınız tarafın kim olduğunu netleştirir.

• Ticaret sicili ilanları. TOBB'un yürüttüğü Türkiye Ticaret Sicili Gazetesi (yeni sekmede açılır) sitesinde, üye girişiyle 1957'den bu yana yayımlanan ilanlara ücretsiz erişilebiliyor; ticaret unvanı sorgulama da ayrı bir hizmet olarak sunuluyor (13 Ekim 2026'da kontrol edildi). Kuruluş, unvan, adres ve ortaklık değişikliklerini buradan izleyebilirsiniz.
• Sözleşmedeki unvan. Teklif ile sözleşmedeki ticaret unvanı ve vergi bilgileri aynı olmalı. Proje bir alt yükleniciye verilecekse bu da yazılı olmalı.
• Kişisel verideki rol. Firma sizin adınıza kişisel veri işleyecekse 6698 sayılı KVKK (yeni sekmede açılır) md. 3'e göre veri işleyen olur. Aynı Kanun'un 12. maddesine göre veri sorumlusu, güvenlik tedbirleri konusunda veri işleyenle birlikte müştereken sorumludur. Bu rolün sözleşmede tanımlanmasını isteyin.

BİLGEM'in rehberi uzun süreli projelerde yüklenicinin finansal durumunun, işi belirlenen süre içinde yürütmeye yeterli olup olmadığının da değerlendirilmesini önerir.

Sözleşme, kaynak kod ve devir

Sözleşme, seçim sürecinde öğrendiğiniz her şeyin bağlayıcı hâle geldiği belgedir. Yazılım geliştirme genellikle bir eser sözleşmesidir: 6098 sayılı Türk Borçlar Kanunu (yeni sekmede açılır) md. 470'e göre eser sözleşmesinde yüklenici bir eser meydana getirmeyi, iş sahibi de karşılığında bedel ödemeyi üstlenir.

Fikri haklar tarafında iki kural özellikle önemlidir:

• 5846 sayılı Fikir ve Sanat Eserleri Kanunu (yeni sekmede açılır) md. 52'ye göre mali haklara dair sözleşmelerin yazılı olması ve konusu olan hakların ayrı ayrı gösterilmesi şarttır. Bedeli ödemek tek başına bu şartı karşılamaz.
• Aynı Kanun md. 48, mali hakların devri ile yalnızca kullanma yetkisinin bırakılmasını (ruhsat, yani lisans) birbirinden ayırır. Sözleşmede hangisinin yapıldığı açıkça yazmalıdır.

Firma işin bir kısmını serbest çalışanlara ya da başka bir firmaya veriyorsa hak zinciri de önem kazanır. FSEK md. 18'e göre memur, hizmetli ve işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki hakları, aksi kararlaştırılmadıkça onları çalıştıranlar kullanır. Dışarıdan çalışan bir geliştirici bu kapsamda değildir; onun haklarının firmaya geçmesi için md. 52'deki yazılı sözleşme gerekir.

FSEK md. 49 da bir mali hakkı ya da kullanma ruhsatını eser sahibinden edinen kişinin, bu hakkı başkasına ancak eser sahibinin yazılı muvafakatiyle devredebileceğini söyler. Bu yüzden firmaya, işte kimlerin çalışacağını ve haklarını size devredebilecek durumda olup olmadığını sorun. Cevabı sözleşmeye bir beyan olarak yazdırın.

Ayrıntılı madde listesi için yazılım geliştirme sözleşmesi, hak devri için yazılım kaynak kodu kime aittir yazılarımıza bakabilirsiniz. Hukuki değerlendirme için sözleşmeyi bir avukata da okutun.

Sözleşmede şu konuların karşılığını arayın:

• Kapsam belgesine atıf ve değişiklik talebi süreci
• Kabul testleri ve kabul ölçütleri
• Mali hakların ya da lisansın tek tek sayılması
• Kod deposu, alan adı, bulut ve mağaza hesaplarının kimin adına olacağı
• Kullanılan açık kaynak bileşenlerin listesi
• Bakım ve destek kapsamı ya da ayrı bakım sözleşmesine atıf
• KVKK kapsamındaki roller ve yükümlülükler
• Teslim belgeleri ve devir koşulları
• Yüklenicinin işi bırakması ya da ortadan kalkması hâlinde ne olacağı

Son madde kolayca gözden kaçabilir. BİLGEM'in Yazılım Geliştirme Rehberi, çıktı taahhütlü işlerde kodların kuruma alınmasına dair maddelerin sözleşmeye eklenmesini ve kod emaneti (escrow) gibi seçeneklerin değerlendirilmesini önerir. Aynı rehber, yüklenicinin iş bitmeden ortadan kalkması durumunun da sözleşmede ele alınmasını ister.

Uyarı işaretleri

Bazı işaretler tek başına eleme nedeni değildir, ama açıklama istemeyi gerektirir.

• İhtiyaç belgesini okumadan ya da hiç soru sormadan verilen teklif.
• Kapsamı belirsizken verilen kesin takvim ve kesin fiyat.
• "Her şeyi yaparız" cevabı; hariç tutulan hiçbir şeyin yazılmaması.
• Projede kimlerin çalışacağının söylenmemesi.
• Kodun ve hesapların firmanın adına kalacağının, sözleşmede değil ilk teslimde ortaya çıkması.
• Referanslarla konuşma isteğinin geri çevrilmesi.
• Çalışan sürümün proje bitene kadar gösterilmemesi.

Seçimden sonraki kararlar

Firma seçimi, yazılım satın almanın ilk kararıdır; sonrasında sözleşme, haklar, bakım ve mimari kararları gelir. Bu kümedeki yazılar her birini ayrı ele alır.

Sözleşme ve haklar

• Yazılım geliştirme sözleşmesi: eser sözleşmesinin yapısı, kabul testi, açık kaynak listesi ve kaynak kod emaneti dahil olması gereken maddeler.
• Yazılım kaynak kodu kime aittir?: FSEK'e göre mali hak devri ile lisans arasındaki fark ve sözleşmede nasıl yazılacağı.
• Gizlilik sözleşmesi (NDA): fikrinizi bir yazılım firmasıyla paylaşmadan önce NDA'nın neyi koruduğu, neyi korumadığı.

Fiyat, bütçe ve bakım

• Yazılım projesi fiyatlandırma modelleri: sabit fiyat, zaman ve kaynak, aylık ekip; riskin kimde kaldığı ve hangi projeye hangisinin uyduğu.
• Yazılım projesi bütçe planlama: geliştirme teklifinde görünmeyen 12 maliyet kalemi ve bütçe tablosu.
• Yazılım bakım sözleşmesi: SLA tablosu, yanıt ve çözüm hedefleri, kapsam dışında kalanlar.

Teslim ve devir

• Yazılım teslim dokümanları: dokümantasyon, erişimler ve devir listesi.
• Yazılım devralma kontrol listesi: başka bir firmanın yazdığı yazılımı devralırken teknik inceleme.

Mimari ve kalite

• Yazılımı baştan yazmak mı, iyileştirmek mi?: yeniden yazma kararı için ölçütler ve adım adım değiştirme deseni.
• Mikroservis mi monolit mi?: küçük ekipler için mimari seçimde ekip büyüklüğü ve işletim yükü.
• Yapay zekâ araçlarıyla geliştirilen kodun riskleri: bu araçlarla yazılan kodda inceleme, test, bağımlılık ve lisans kontrolü.

Bizim deneyimimiz

Meybrain olarak bu sürecin iki tarafında da bulunuyoruz. Bir yazılım şirketi olarak teklif hazırlıyoruz; teknoloji danışmanlığı hizmetimizde ise şirketlerin farklı firmalardan aldığı teklifleri kapsam, risk ve maliyet açısından inceliyoruz.

Bu ikinci rolde bağımsızlık sorusunu baştan açık konuşuyoruz. Önerdiğimiz çözümü bizden almak zorunda değilsiniz. Uygun bir hazır ürün varsa onu öneriyoruz. Yol haritasını başka bir ekibin de uygulayabileceği açıklıkta yazıyoruz.

Kendi çalışma biçimimizde de yukarıdaki listenin bir kısmını varsayılan hâle getirdik. Alan adı, barındırma, uygulama mağazası ve bulut hesaplarını müşterinin adına açıyoruz. Geliştirme süresince çalışan sürüm bir test adresinden izlenebiliyor. Kod sahipliği, bakım ve destek koşullarını ise her projenin sözleşmesinde birlikte belirliyoruz. Web, mobil ve bulut tarafında neler yaptığımızı yazılım ve platformlar sayfasında anlattık.

Sık sorulan sorular

En düşük teklifi seçmek mantıklı mı?

Teklifler aynı kapsamı kapsıyorsa fiyat önemli bir ölçüttür. Ama en düşük teklif çoğu zaman bir şeyi dışarıda bırakmıştır. Önce hariç tutulanları ve varsayımları karşılaştırın, sonra fiyatı.

Teknik bilgim yok; teklifleri nasıl değerlendiririm?

İhtiyaç belgesi, puanlama matrisi ve referans soruları, teknik bilgi gerektirmeyen araçlardır. Teknik kısımlar için firmalardan cevapları sade dille yazmalarını isteyin. Gerekirse bağımsız bir teknik görüş alın.

Büyük bir firma mı, küçük bir firma mı?

Büyüklükten çok uyum önemlidir. Projenizin o firma için ne kadar önemli olduğunu, kimlerin çalışacağını ve benzer işi daha önce yapıp yapmadığını sorun. BİLGEM'in tedarik rehberi de firmanın ilgili çözüm ve projeyi stratejik olarak görüp görmediğinin değerlendirilmesini önerir.

Firmanın bizimle aynı şehirde olması gerekir mi?

Şart değildir, ama nasıl çalışılacağı baştan konuşulmalıdır. BİLGEM'in tedarik rehberi, kurulum ve destek verecek firmalarda yerleşik ofis ve yakında çalışan personeli de değerlendirme ölçütleri arasında sayar. Web tabanlı yazılımlar uzaktan da geliştirilebilir. Önemli olan; düzenli toplantılar, çalışan sürümü izleme imkânı, yazılı karar kaydı ve gerektiğinde yüz yüze görüşmenin birlikte planlanmasıdır.

Sözleşmede kaynak kod bize geçmezse ne olur?

Yazılımı kullanabilirsiniz, ama değiştirme, başka bir ekibe devretme ya da çoğaltma haklarınız sözleşmede tanınanlarla sınırlı kalır. FSEK md. 52 nedeniyle bu hakların yazılı ve tek tek sayılmış olması gerekir. Bu konuyu imzadan önce netleştirin.

Kaynaklar

• TÜBİTAK BİLGEM YTE, "Uygulama Yazılımı Tedariki Rehberi", 2017. bilgem.tubitak.gov.tr (yeni sekmede açılır)
• TÜBİTAK BİLGEM YTE, "Yazılım Geliştirme Rehberi", 2017. bilgem.tubitak.gov.tr (yeni sekmede açılır)
• TÜİK, "Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, 2026", 10 Eylül 2026. veriportali.tuik.gov.tr (yeni sekmede açılır)
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu, md. 18, 48, 49 ve 52, Resmî Gazete 13 Aralık 1951. mevzuat.gov.tr (yeni sekmede açılır)
• 6098 sayılı Türk Borçlar Kanunu, md. 470, Resmî Gazete 4 Şubat 2011. mevzuat.gov.tr (yeni sekmede açılır)
• 6698 sayılı Kişisel Verilerin Korunması Kanunu, md. 3 ve 12, Resmî Gazete 7 Nisan 2016. mevzuat.gov.tr (yeni sekmede açılır)
• TOBB, Türkiye Ticaret Sicili Gazetesi, 13 Ekim 2026'da erişildi. ticaretsicil.gov.tr (yeni sekmede açılır)