Kripto para borsası projelerinde en erken verilmesi gereken ve sonraki tüm kararları biçimlendiren soru, gerekli yazılımın kurum içinde mi geliştirileceği yoksa dışarıdan mı edinileceğidir. Literatürde build veya buy kararı olarak adlandırılan bu tercih, yalnızca bir tedarik kalemi değil; ekip yapısını, takvimi, maliyet eğrisini ve düzenleyici hazırlık sürecini birlikte belirleyen stratejik bir seçimdir.
Kararın zorluğu, iki seçeneğin de farklı zaman dilimlerinde farklı maliyetler üretmesinden kaynaklanır. Hazır ürün edinme yaklaşımı, başlangıç yükünü düşürürken sağlayıcıya bağımlılık ve özelleştirme sınırı getirir. Kurum içi geliştirme ise kontrolü artırırken, ilk sürüme ulaşma süresini ve kalıcı ekip maliyetini yükseltir. Bu nedenle karar, tek bir maliyet rakamı üzerinden değil, çok boyutlu bir değerlendirme çerçevesi üzerinden verilmelidir.
Bu analizde, build veya buy kararının hangi kriterler üzerinden değerlendirildiği, hangi bileşenlerin bu karara ayrı ayrı tabi tutulması gerektiği ve kararın hangi aşamada verilmesinin uygun olduğu ele alınmaktadır.
Kararın Doğru Kurgulanması
Build veya buy kararı çoğunlukla ikili bir tercih gibi sunulur; oysa uygulamada bu iki uç arasında geniş bir aralık bulunur. Çekirdek işlem altyapısının hazır ürün olarak edinilip uyum ve backoffice katmanlarının kurum içinde geliştirildiği karma yapılar, sektörde sıkça görülen bir konumlanmadır. Bu nedenle karar, platformun tamamı için tek seferde değil, bileşen düzeyinde verilmelidir.
Kararın sağlıklı verilebilmesi için önce gereksinimlerin netleştirilmiş olması gerekir. Hedef kullanıcı profili, desteklenecek varlık ve piyasa tipleri, beklenen işlem hacmi, faaliyet gösterilecek ülke ve tabi olunacak düzenleyici çerçeve tanımlanmadan yapılan karşılaştırmalar, ölçüsüz varsayımlar üzerine kurulur. Hazır yazılım ve sıfırdan geliştirme karşılaştırması, bu tercihin ürün perspektifinden ele alındığı tamamlayıcı bir çerçeve sunar.
Pazara Çıkış Süresi
Zaman, kararın en somut ölçülebilir boyutudur. Hazır ürün edinme yaklaşımında süre büyük ölçüde entegrasyon, özelleştirme ve uyum hazırlığı kalemlerinde birikirken; kurum içi geliştirmede çekirdek bileşenlerin üretilmesi de bu sürenin parçası olur. Matching engine, ledger ve cüzdan altyapısı gibi katmanların olgunlaşması, ilk çalışan sürümün üretilmesinden sonra da devam eden bir süreçtir.
Zaman değerlendirmesinde sık yapılan hata, ilk sürüme ulaşma süresinin faaliyete geçme süresiyle eşitlenmesidir. Düzenleyici hazırlık, bağımsız denetim, güvenlik testleri ve operasyon ekibinin kurulması, yazılım hazır olduktan sonra da devam eden ayrı bir takvim oluşturur.
Not: Takvim karşılaştırması yapılırken her iki seçenek için de aynı bitiş tanımı kullanılmalıdır. Hazır ürün için "canlıya alınabilir sürüm", kurum içi geliştirme için "ilk demo" ölçüldüğünde karşılaştırma anlamını yitirir.
Maliyetin Zaman İçindeki Davranışı
Maliyet karşılaştırmasının yalnızca başlangıç kalemi üzerinden yapılması, kararın en yaygın çarpıtılma biçimidir. Toplam sahip olma maliyeti; lisans veya geliştirme bedelinin yanında altyapı, bakım, güvenlik, uyum operasyonu ve ekip giderlerini de kapsar. Kurum içi geliştirmede maliyet zamana yayılmış ve büyük ölçüde ekip merkezli iken, hazır ürün edinmede önemli bölümü öne yığılmış ve sözleşmeye bağlı biçimde davranır.
- Kurum içi geliştirmede kalıcı ekip gideri, proje tamamlandıktan sonra da devam eden bir kalem olarak planlanmalıdır; borsa yazılımı bakım gerektirmeyen bir varlık değildir.
- Hazır ürün edinmede, lisans bedelinin dışında kalan özelleştirme ve entegrasyon kalemleri sözleşme öncesinde kapsam olarak netleştirilmelidir.
- Her iki seçenekte de uyum, denetim ve güvenlik giderleri ortak kalemdir; bu giderlerin build veya buy tercihiyle önemli ölçüde değişmediği dikkate alınmalıdır.
Lisans maliyeti ile yazılım maliyeti arasındaki ayrımın karıştırılması da değerlendirmeyi bozan bir başka etkendir. Düzenleyici faaliyet izni süreçlerinin gerektirdiği giderler, yazılım tedarik kaleminden bağımsız olarak planlanmalıdır.
Kontrol, Özelleştirme ve Veri Sahipliği
Kontrol boyutu; kaynak koda erişim, yol haritasına yön verebilme ve verinin nerede tutulduğunu belirleyebilme başlıklarında değerlendirilir. Kurum içi geliştirme bu üç başlıkta en geniş hareket alanını sağlar. Hazır ürün edinmede ise özelleştirme sınırlarının ve veri yerleşim seçeneklerinin sözleşme aşamasında netleştirilmesi gerekir.
Özelleştirme ihtiyacının gerçekçi ölçülmesi önemlidir. Kurumlar başlangıçta kendi süreçlerini kendine özgü varsayma eğilimindedir; oysa emir eşleştirme ve bakiye muhasebesi gibi çekirdek işlevler büyük ölçüde standarttır. Farklılaşma çoğunlukla uyum akışları, ürün paketleme ve müşteri deneyimi katmanlarında ortaya çıkar. White label yaklaşımının kapsamı, bu sınırların anlaşılması bakımından yararlı bir referans oluşturur.
Düzenleyici Hazırlık Boyutu
Türkiye'de kripto varlık hizmet sağlayıcıları, SPK kriterlerine tabi bir çerçevede faaliyet gösterir ve teknik altyapı açısından TÜBİTAK kriterlerine uygunluk beklenir. Bu gereksinimler, seçilen tedarik modelinden bağımsız olarak karşılanmak zorundadır. Hazır ürün edinmenin düzenleyici yükümlülüğü sağlayıcıya devrettiği varsayımı hatalıdır; yükümlülük faaliyet gösteren kuruluşta kalır.
Bu nedenle değerlendirmede sorulması gereken soru, ürünün uyumu sağlayıp sağlamadığı değil; denetim gereksinimlerine göre yapılandırılmış bir işletim düzenini ne ölçüde desteklediğidir. Denetim izi üretimi, raporlama kabiliyeti, veri saklama süreleri ve erişim kontrolü bu desteğin somut göstergeleridir. Hazırlık süreci SPK uyum hazırlığı ve TÜBİTAK KVHS hazırlığı başlıkları altında ayrıca ele alınmaktadır.
Bağımlılık ve Süreklilik Riski
Her iki seçenek de kendi bağımlılık biçimini üretir. Hazır ürün edinmede risk, sağlayıcının ticari sürekliliği, yol haritası önceliklerinin farklılaşması ve çıkış maliyetinin yüksekliği etrafında toplanır. Kurum içi geliştirmede ise bağımlılık, kilit teknik personel ve kurumsal bilgi birikimi üzerinde yoğunlaşır; ekip değişimleri doğrudan süreklilik riski doğurur.
Uyarı: Sağlayıcı değerlendirmesinde çıkış senaryosu çoğunlukla atlanır. Sözleşme sona erdiğinde verinin hangi biçimde devralınacağı ve platformun hangi koşullarda işletilmeye devam edileceği baştan tanımlanmadığında, bağımlılık kalıcı hâle gelir.
Bileşen Bazlı Değerlendirme
Kararın bileşen düzeyine indirilmesi, uygulamada en verimli sonucu üreten yaklaşımdır. Ayırt edici olmayan ve yüksek standardizasyon gösteren bileşenlerde hazır ürün edinme; kurumun rekabet alanını oluşturan ve sık değişen bileşenlerde kurum içi geliştirme tercih edilebilir.
| Bileşen | Standardizasyon düzeyi | Eğilim |
|---|---|---|
| Matching engine | Yüksek | Hazır ürün edinme |
| Cüzdan ve saklama | Yüksek | Hazır ürün veya saklama hizmeti |
| KYC ve AML | Yüksek | Hizmet olarak kullanım |
| Backoffice ve operasyon | Orta | Karma yaklaşım |
| Ürün paketleme ve arayüz | Düşük | Kurum içi geliştirme |
Tablodaki eğilimler kategori düzeyinde genel yönelimleri gösterir; her kurumun kaynak yapısı, ekip olgunluğu ve hedef takvimi bu yönelimi değiştirebilir.
Sonuç
Build veya buy kararı, tek bir maliyet karşılaştırmasına indirgenebilecek bir tercih değildir. Zaman, toplam sahip olma maliyeti, kontrol düzeyi, düzenleyici hazırlık ve bağımlılık riski birlikte değerlendirildiğinde, çoğu kurum için sonuç saf bir uçta değil; bileşen bazlı ayrıştırılmış bir karma modelde ortaya çıkar. Kararın gereksinim analizi tamamlanmadan verilmesi, sonraki tüm aşamalarda düzeltilmesi pahalı sapmalar üretir. Değerlendirmenin, kurumun ekip kapasitesi ve düzenleyici takvimiyle birlikte yapılması uygun olur.
Build veya buy kararı, gereksinim analizi tamamlandıktan sonra bileşen düzeyinde verilmelidir. Karar çerçevesinin kurum yapısına göre oluşturulması için teknik değerlendirme desteği sağlanmaktadır.