Hazır E-Ticaret Altyapısı mı Özel Yazılım mı?

E-ticaret altyapısı konuşulurken sık duyulan bir varsayım vardır: Özel yazılım daha gelişmiş, hazır altyapı daha basittir. Bu varsayım kararı yanlış yerden başlatır.

Özel yazılım daha gelişmiş, hazır altyapı daha basit değildir. Doğru karar; işletmenin gerçekten standart dışı hangi süreçlere sahip olduğuna ve bu farklılığın maliyetini taşımaya değip değmediğine bağlıdır.

Şirketin büyük olması, aylık lisans ödemek istememek veya çok sayıda entegrasyona ihtiyaç duymak tek başına model kararı vermez. Büyük bir şirket hazır bir sistemle sorunsuz çalışabilir; küçük bir işletmenin tek bir kritik süreci ise standart çözümlerin dışında kalabilir. Yanlış kararın iki pahalı sonucu vardır: gerek olmayan özel kodun yıllarca bakımını taşımak ya da sınırına gelmiş bir hazır sistemi elle yapılan işlerle ayakta tutmaya çalışmak.

Bu rehber, altyapı kararından önce netleştirilecek ihtiyaçlar belli olduğunda bir sonraki soruya odaklanır: Hangi model sizin için uygun? Sonunda dört seçenek arasında gerekçeli bir tercih yapabilmeniz amaçlanır: hazır sistemle devam etmek, onu desteklenen yollarla genişletmek, hibrit bir yapı kurmak veya özel geliştirmeye gitmek.

Hazır, SaaS, Açık Kaynak ve Özel Yazılım Aynı Eksende Değildir

Bu kavramlar çoğu zaman tek bir merdivenin basamakları gibi anlatılır. Oysa farklı soruları cevaplarlar.

Hazır altyapı ve SaaS

"Hazır", işlevlerin önceden geliştirilmiş olduğunu anlatır: ürün, sepet, ödeme, sipariş ve iade akışları sizden önce yazılmıştır. SaaS (Software as a Service) ise sunulma ve işletilme modelidir: yazılım sağlayıcının altyapısında çalışır, güncelleme ve barındırma onun sorumluluğundadır, siz abonelikle kullanırsınız. Her hazır çözüm SaaS değildir; kendi sunucunuza kurduğunuz lisanslı bir paket de hazır altyapıdır. Aradaki fark, sunucunun, güncellemelerin ve güvenlik yamalarının kimin sorumluluğunda olduğudur.

Açık kaynak ve hibrit

Açık kaynak bir e-ticaret çekirdeği kullanmak sıfırdan yazmak değildir. Temel işlevler hazırdır; fark, kodun size açık olması ve değiştirilebilmesidir. Bu, maliyeti ve bakımı ortadan kaldırmaz: barındırma, güncelleme ve eklentilerin güvenliği işletmeye geçer. Açık kaynak lisansları da birbirinin aynı değildir; kodu değiştirme ve dağıtma koşulları lisansa göre değişir. Hibrit yaklaşım ise hazır bir çekirdeğin yanına özel bir modül veya entegrasyon katmanı eklemektir; çekirdek SaaS da olabilir, açık kaynak da.

Headless, composable ve özel geliştirme

Headless, müşterinin gördüğü ön yüzü ticaret çekirdeğinden ayırır; ön yüz ayrı geliştirilir, ticaret işlevleri API üzerinden kullanılır. Composable ise arama, ödeme, içerik gibi işlevleri ayrı bileşenlerden seçip birleştirme yaklaşımıdır. İkisi eş anlamlı değildir ve hem SaaS hem açık kaynak üzerinde uygulanabilir.

Özel geliştirme de tek bir şey değildir: tek bir modülü, bir entegrasyon katmanını veya tüm sistemi kapsayabilir. Tamamen sıfırdan yazmak, olası seçeneklerden yalnızca biridir.

Hangi İşletme Koşullarında Hazır Altyapı Daha Rasyoneldir?

Ürün, kampanya, ödeme, sipariş ve iade akışınız hazır sistemin desteklediği özelliklerle karşılanıyorsa, hazır altyapı güçlü bir adaydır. Bu, işletmenin basit olduğu anlamına gelmez; yalnızca ticaretin mekaniğinin standart olduğu anlamına gelir.

Şu koşullar birlikte varsa hazır sistem genellikle daha rasyonel bir başlangıçtır:

• Satışa hızlı başlamak ve öğrenmek öncelikli.
• Kalıcı bir teknik ekip yok veya sınırlı.
• Barındırma, güvenlik güncellemeleri ve altyapı bakımının sağlayıcıda kalması isteniyor.
• Destek kapsamı ve sorumluluk sınırları yazılı olarak tanımlı.

Ekip ve bakım kapasiteniz sınırlıysa, küçük işletmenin başlangıç modelini ayrıca inceleyin.

Bu koşullarda hazır sistem, sınırların nerede olduğunu gerçek siparişlerle görmenin de en düşük maliyetli yoludur. İlk aylarda hangi işlerin elle yapıldığı, hangi kampanyanın kurulamadığı ve hangi raporun eksik kaldığı kaydedilirse, ileride model değişikliği gerekip gerekmediği tahminle değil veriyle tartışılır.

Hazır sistem "ek maliyetsiz" demek değildir. Uygulama abonelikleri, entegrasyon ücretleri, tema uyarlaması ve operasyon emeği hazır modelde de bütçenin parçasıdır.

Kontrol sorusu basittir: Bugün elle yapılan veya çevresinden dolaşılan işler, desteklenen bir özellik ya da uygulamayla kapatılabiliyor mu? Cevap evetse, model değiştirmek için henüz bir gerekçe yoktur.

Hazır altyapı kullanmak işletmenin farklılaşmasını da engellemez. Farklılık çoğu zaman ürünün kendisinde, fiyatlama mantığında, içerikte, hizmet kalitesinde ve operasyon hızındadır; sepetin teknik olarak nasıl çalıştığında değil.

Hazır Altyapının Sınırına Gerçekten Ne Zaman Gelinir?

Net cevap şudur:

İşletme, kritik bir sürecini mevcut altyapının desteklenen özellikleri, API'leri ve sürdürülebilir ek çözümleriyle kabul edilebilir maliyet, performans ve güvenilirlikte yürütemediğini kanıtladığında o altyapının sınırına gelmiştir.

"Kanıtladığında" kelimesi önemlidir. Sınır bir his değil, dört koşulun birlikte sağlandığı bir test sonucudur:

1. İhtiyaç kritik: Süreç; gelir, operasyon veya işletmeye uygulanan zorunlu koşullar açısından önemlidir. "Olsa iyi olur" düzeyindeki bir özellik bu testi geçmez.
2. Sorun tekrarlanabilir: Sorun yanlış bir ayardan, geçici bir arızadan veya kullanım hatasından kaynaklanmıyor; aynı koşulda her seferinde ortaya çıkıyor.
3. Desteklenen çözüm yolları incelenmiş: Mevcut özellikler, üst paketler, API'ler, uygulama mağazası çözümleri, bir entegrasyon katmanı ve uygun başka hazır adaylar gerçekten denenmiş.
4. Sonuç kabul edilemez: Doğruluk, gecikme, elle yapılan iş, maliyet veya güvenilirlik açısından önceden belirlenmiş eşik karşılanmıyor.

Eşiği testten önce yazın. Örneğin "sipariş başına elle düzeltme ayda belirli bir sayıyı geçmemeli" veya "stok bilgisi tüm kanallarda belirli bir süre içinde eşitlenmeli" gibi ölçülebilir bir kabul kriteri yoksa, aynı sonucu bir kişi kabul edilebilir, bir başkası kabul edilemez bulur. Her koşul için bir kanıt da saklayın: sürecin gelir veya operasyon etkisi, sorunun tekrar adımları, denenen çözüm yollarının listesi ve ölçülen sonuç.

Bu testte iki ayrıma dikkat edin. Birincisi, bir sağlayıcının sınırı tüm SaaS modelinin sınırı değildir; başka bir hazır aday aynı ihtiyacı karşılayabilir. İkincisi, dört koşulun sağlanması özel geliştirmeyi değerlendirmeyi gerektirir; tüm sistemi yeniden yazmayı otomatik olarak gerektirmez.

Örnek (hipotetik): Bir B2B işletmesinde müşteriye özel fiyatlar ERP'de hesaplanıyor, ancak bu fiyat ödeme anına doğru taşınmıyor. Önce altyapının desteklediği fiyat listeleri, müşteri grupları ve fiyat API'leri test edilir; ardından ERP ile senkronizasyon gözden geçirilir. Sorunu yalnızca özel bir fiyat katmanı çözebiliyorsa, çekirdek yeniden yazılmaz; o katman geliştirilir. Kritik işlem tutarlılığı hiçbir sürdürülebilir yolla sağlanamıyorsa, ancak o zaman model değişimi masaya gelir. Buradaki "sürdürülebilir", çözümün her sürüm güncellemesinde elle onarılmasını gerektirmemesi, izlenebilmesi ve sahibinin belli olması demektir.

Aday sistemleri ayrıntılı test etmek için aday altyapıyı gerçek sipariş akışıyla değerlendirmek üzerine hazırladığımız rehberdeki sipariş testini ve karar matrisini kullanabilirsiniz.

Özel Geliştirme Gerektirebilecek Gerçek Sinyaller

Aşağıdaki durumlar, sınır testinin olumlu sonuç verme ihtimalinin yüksek olduğu alanlardır:

• Fiyat ve teklif kuralları: Standart fiyat listeleri, müşteri grupları veya kampanya araçlarıyla ifade edilemeyen ve gelire doğrudan etki eden kurallar.
• Üretim ve kapasite bağlantısı: Siparişin kabulü, teslim tarihi veya fiyatı üretim planına ya da anlık kapasiteye bağlıysa.
• Kurumsal onay akışı: Çok aşamalı onay, bütçe limiti ve yetki kurallarının desteklenmemesi.
• Sipariş bölme ve birleştirme: Siparişin depo, tedarikçi veya teslim penceresine göre özgün kurallarla bölünmesi, dağıtılması ya da birleştirilmesi.
• İşlem tutarlılığı ve gecikme: Stok, fiyat veya ödeme verisinin gereken tutarlılıkla ve gecikmeyle mevcut API modeli üzerinden sağlanamaması.
• Veri erişimi ve denetlenebilirlik: Gerekli veri erişimi, kayıt tutma veya denetim koşullarının uygun hiçbir adayda karşılanamaması.
• Sürdürülemez elle işlem: Elle yapılan işin ve hatanın maliyetinin ölçülmüş ve kabul edilemez bulunmuş olması.

Etiketler tek başına kanıt değildir. "B2B satıyoruz", "ürün konfigüratörümüz var" veya "birden fazla depomuz var" demek özel geliştirme gerektiğini göstermez; birçok hazır sistem bu ihtiyaçları farklı düzeylerde karşılar. Her sinyal için dört şey aranmalıdır: yazılı iş kuralı, test sonucu, ticari veya operasyonel etki ve geliştirildikten sonra bu parçanın bakımını kimin üstleneceği. Sinyalleri tek bir ekip doğrulamamalıdır. Operasyon sorunun gerçek sıklığını, finans ticari etkisini, teknik ekip ise desteklenen yolların neden yetmediğini ortaya koymalıdır.

Örneğin "kurumsal müşterilerde belirli bir tutarın üzerindeki siparişler satın alma müdürü onayı olmadan kesinleşmemeli" cümlesi bir iş kuralıdır; "onay akışı istiyoruz" ise henüz bir istektir.

Özel Yazılım Gerektirmeyen Ama Öyle Sanılan Durumlar

Bazı varsayımlar, sınır testine hiç girmeden özel yazılım kararına götürür:

• "Büyük şirket özel yazılım kullanmalıdır." Model kararını şirket büyüklüğü değil, süreçlerin standart dışı olup olmadığı belirler.
• "Aylık lisans yoksa daha ucuzdur." Lisansın yerini geliştirme, barındırma, bakım ve ekip maliyeti alır. Karşılaştırma toplam maliyetle yapılmalıdır.
• "Hazır altyapı ölçeklenmez." Ölçek tek bir sayı değildir; aşağıda açıklandığı gibi farklı yük türleri vardır ve her aday ayrı test edilmelidir.
• "Özel yazılımda vendor lock-in yoktur." Vendor lock-in, bir sağlayıcıya ayrılması zor biçimde bağlı kalmaktır. Özel yazılımda bağımlılık ortadan kalkmaz; geliştiren ekibe, belgelemeye ve kod üzerindeki haklara kayar.
• "Çok entegrasyon varsa özel yazılım şarttır." Entegrasyon sayısı değil, entegrasyonun gerektirdiği tutarlılık ve kurallar belirleyicidir. Birçok entegrasyon bir ara katmanla çözülebilir.

Özgün tasarım, yüksek ürün (SKU) sayısı, standart bir bayi akışı, yavaş bir tema veya mevcut sağlayıcıdan memnun olmamak da tek başına özel yazılım gerekçesi değildir. Bunların çoğu tema, yapılandırma, uygulama veya sağlayıcı değişikliğiyle çözülür. Mevcut sağlayıcıyla yaşanan sorun bir destek, fiyat veya performans sorunuysa, önce başka bir hazır adayla aynı testi yapmak çoğu zaman daha kısa ve daha düşük riskli yoldur.

Ölçeği yalnızca trafik veya ciroyla açıklamak da yanıltıcıdır. Katalog büyüklüğü, eşzamanlı ödeme sayısı, stok güncelleme sıklığı, API çağrı limitleri ve arka planda çalışan işler farklı yük türleridir. Bir sistem yüksek trafiği rahat karşılarken binlerce ürünün fiyatını aynı anda güncellerken zorlanabilir. Hazır ya da özel, her aday için gerçek yük ve süreç kabul kriterleri tanımlanmalı ve test edilmelidir.

Açık Kaynak, Hibrit ve Headless Ne Zaman Anlamlıdır?

Bu yaklaşımlar ancak çözdükleri ihtiyaç belliyse anlamlıdır:

• Açık kaynak: Uygun bir çekirdeği koruyup belirli noktalarda koda müdahale etmeniz gerekiyorsa. Bu tercih, güvenlik ve güncelleme sorumluluğunun barındırma, eklenti seçimi ve sürüm takibiyle birlikte sizde olması demektir.
• Hibrit: Sizi farklılaştıran tek bir modül veya entegrasyon, hazır çekirdeğin dışında çözülebiliyorsa. Çekirdek standart kalır, özel kod yalnızca gereken yerde yazılır.
• Headless: Özgün bir ön yüze veya mağaza dışında uygulama, kiosk gibi birden fazla temas noktasına ihtiyaç varsa. Headless, arka uçtaki fiyat veya sipariş sınırlarını kendiliğinden çözmez. Ayrı bir ön yüz uygulamasının yayınlanması, izlenmesi ve güncellenmesi de ayrı bir iş yüküdür.
• Composable: Arama, içerik veya ödeme gibi bileşenleri bağımsız seçip değiştirebilmek önemliyse. Karşılığında bileşenleri birbirine bağlayan orkestrasyon, uçtan uca izleme ve her bileşen için açık bir ekip sorumluluğu gerekir. Örneğin arama hizmeti yanıt vermediğinde ürün listesinin ne göstereceği, hangi ekibin uyarı alacağı ve sağlayıcı değiştiğinde hangi bağlantıların yeniden yazılacağı önceden belli olmalıdır.

Hibrit veya headless her zaman daha iyi değildir; her bileşen yeni bir bakım ve izleme yükü getirir. Karar sorusu şudur: Bu yaklaşımın çözdüğü sorun, getirdiği ek sorumluluktan daha değerli mi? SEO ve performans da mimari etiketten değil uygulamadan etkilenir: aynı mimariyle hızlı da yavaş da bir site kurulabilir.

Modelleri Aynı İşletme Koşuluyla Karşılaştırın

Modelleri soyut olarak değil, aynı işletme koşulu üzerinden karşılaştırın. Aşağıdaki tablo bir sıralama değil, her modelde neyin sorulacağını gösterir:

Bu tabloda hız ve maliyet için kesin bir sıralama yoktur; çünkü sonuç, kapsamın ve ekibin özelliklerine göre değişir. Headless ve composable bu tablonun dördüncü bir sütunu değildir; üç modelden herhangi biri üzerine uygulanabilen mimari tercihlerdir.

12 ve 36 Aylık Toplam Sahip Olma Maliyetini Hesaplayın

Toplam sahip olma maliyeti (TCO), bir sistemi yalnızca kurmanın değil, belirli bir süre boyunca çalıştırmanın ve gerektiğinde bırakmanın maliyetidir. Model karşılaştırması için şu formül yeterlidir:

Başlangıç + çalıştırma + bakım/değişiklik + iç ekip emeği + planlanan geçiş/çıkış

Tablodaki ağırlıklar modele göre değişir. Hazır sistemde lisans ve uygulama giderleri öne çıkarken, özel geliştirmede başlangıç ve bakım; açık kaynakta barındırma ve iç ekip emeği belirleyici olur. Bu yüzden hiçbir model her kalemde ucuz değildir.

Karşılaştırmanın güvenilir olması için birkaç kural uygulayın:

• Modelleri aynı işlev, aynı hacim ve aynı destek kapsamıyla karşılaştırın.
• Yenileme, kur ve büyüme varsayımlarını açıkça yazın.
• Aynı işi hem iç personelde hem dış bakım sözleşmesinde sayarak iki kez hesaplamayın.
• Çıkış gerçekleşmeyecekse onu ana hesaba katmayın; ayrı bir senaryo olarak gösterin.
• Kesinti ve yayına çıkış gecikmesini maliyet kalemi değil, ayrı bir risk hesabı olarak tutun.
• Beklenen faydayı maliyetten ayrı gösterin; brüt ciroyu yatırım geri dönüşü olarak saymayın.

Bu hesap model kararı içindir. Seçtiğiniz modelin ilk 12 ayını kalem kalem doldurmak için ilk yıl TCO çalışma modelini, kurulum ve ilk satışa hazırlık kalemleri için e-ticaret sitesi kurma maliyeti rehberini kullanabilirsiniz.

Bakım, Güvenlik ve Bus-Factor: Sistemi Kim Sürdürecek?

Bus-factor, kritik bilginin az sayıda kişide toplanması nedeniyle bu kişilerden biri ayrıldığında işin durma riskidir. Ekipte beş kişinin olması bu riski kendiliğinden azaltmaz; önemli olan bilginin ve yetkinin paylaşılıp paylaşılmadığıdır.

Hangi model seçilirse seçilsin, şu sorular yazılı cevap gerektirir:

• Bakım sahipleri: Çekirdek, özel kod, entegrasyonlar ve barındırma için ayrı ayrı kim sorumlu?
• Güncelleme ve sürüm takibi: Çekirdek ve eklenti güncellemeleri ile kullanılan API sürümlerinin kullanımdan kaldırılma takvimi kim tarafından izleniyor?
• Yetki ve sır yönetimi: API anahtarları, ödeme bilgileri ve yönetici yetkileri nerede tutuluyor ve kimde?
• Yedekleme: Yedek alınıyor mu ve geri yükleme gerçekten test edildi mi?
• İzleme ve olay müdahalesi: Bir hata veya kesinti kim tarafından, nasıl fark ediliyor?
• Test ve geri alma: Her değişiklik test ortamında doğrulanıp sorun çıkarsa geri alınabiliyor mu? Güvenli yayın pratikleri bu adımı standart bir süreç haline getirmeyi önerir.
• Kod erişimi ve haklar: Kaynak koduna erişim ve kodu kullanma, değiştirme hakları kimde?
• Teknik borç: Hızlı ama kalıcı olmayan çözümlerin ileride yeniden ele alınma ihtiyacıdır. İyileştirme için ayrılmış bir bütçe var mı?

Basit bir devralma testi uygulayın: Ana geliştirici yardım etmeden, başka yetkili bir kişi veya ekip test ortamını kurabilir, küçük bir değişikliği yayımlayabilir ve geri alabilir mi? Cevap hayırsa risk yüksektir. Bu test, özel yazılımda olduğu kadar özel entegrasyonları olan hazır sistemlerde de geçerlidir.

Teknik borç yalnızca özel yazılımda oluşmaz. SaaS üzerine yazılmış özel entegrasyonlar ve açık kaynakta birbirine bağımlı eklenti zincirleri de bakım ister. "Kaynak kodu bizde" demek de bağımsızlık veya güvenlik anlamına otomatik olarak gelmez; güvenlik kontrollerinin OWASP ASVS gibi bir standarda göre doğrulanması ve kodun devralınabilir olması ayrıca sağlanmalıdır.

Geçiş ve Çıkış Maliyetini Satın Almadan Önce Kontrol Edin

Bir sistemden ayrılmanın maliyeti, genellikle o sisteme girerken belirlenir. Satın almadan veya geliştirmeye başlamadan önce şunları kontrol edin:

• Alan adı, yönetici hesapları ve bulut hesapları işletmenin kontrolünde mi?
• Kodu kullanma ve değiştirme hakları ile kullanılan lisanslar sözleşmede açık mı?
• Ürün, müşteri, sipariş ve iade verileri arasındaki ilişkiler korunarak alınabiliyor mu?
• Açık siparişler ve devam eden iadeler geçiş sırasında nasıl yönetilecek?
• Özel alanlar, görseller ve gerekli izin kayıtları taşınabiliyor mu?
• Müşteri şifreleri, ödeme token'ları gibi taşınamayan veriler için ne yapılacak?
• Entegrasyonların yeni sistemde yeniden kurulması ne gerektiriyor?
• URL, canonical ve yönlendirme envanteri hazır mı?
• Analitik ve dönüşüm ölçümünün sürekliliği nasıl sağlanacak?
• Paralel çalışma ve geri dönüş planı var mı?
• Veriyi alma süresi, ücreti ve sağlayıcı desteği ne?
• Yeni bir ekibin sistemi devralma maliyeti ne?

Burada üç kabiliyeti ayrı tutun: verinin dışa aktarılması, başka bir sisteme eksiksiz taşınması ve aynı sisteme geri yüklenmesi. Bir sistemin dışa aktarım sunması diğer ikisini garanti etmez. Örneğin bir sağlayıcının kendi belgelerinde, mağaza kopyalanırken siparişlerin ve indirim kodlarının yönetim panelinden aktarılamadığı belirtilir. Sözleşme haklarını da evrensel varsaymayın; her adayda bu koşulları ayrıca kontrol edin. Bu listedeki maddelerin cevabı belirsizse, çıkış maliyeti TCO hesabında sıfır değil, bilinmeyen bir risk olarak yer almalıdır.

Kararı İşletmenin Farkına ve Taşıyabileceği Sorumluluğa Göre Verin

Bu değerlendirmenin sonunda dört olası karar vardır:

• Hazır sistemle devam etmek, çünkü ihtiyaçlar desteklenen özelliklerle karşılanıyor.
• Desteklenen bir modül veya entegrasyonla genişletmek, çünkü sınır tek bir noktada.
• Uygun başka bir hazır veya açık kaynak modele geçmek, çünkü sınır mevcut sağlayıcıya özgü.
• Gerekçeli özel geliştirme yapmak, çünkü kritik süreç sınır testini geçti ve maliyeti taşınabilir.

Hangi karar verilirse verilsin, kısa bir karar notu yazın: kritik süreç, test kanıtı, 12 ve 36 aylık maliyet, bakım sahibi, kabul edilen risk ve çıkış koşulları. Bu not, kararı kişilerden bağımsız hale getirir. Kararı da kalıcı saymayın: sipariş hacmi, kanal sayısı veya iş modeli belirgin biçimde değiştiğinde ya da elle yapılan işler kabul edilen eşiği aşmaya başladığında aynı testi yeniden uygulayın.

Altyapı tek başına sonuç üretmez; ürün, operasyon ve müşteri edinme ile birlikte çalışır. Bu nedenle model kararını altyapıyı çalışan satış sistemi içinde değerlendirmek yaklaşımıyla ele almak, yanlış yerde yapılan yatırımın önüne geçer.