Talep Üzerine Pazaryeri Yazılımı Geliştirme
Hazır çözüm yetmediğinde kuruma özel pazaryeri ve entegrasyon yazılımı: keşiften canlıya kadar aşamalı ilerleyen, ERP/muhasebe köprüsü ve özel iş kurallarını içeren mikroservis/API mimarisi.
Hazır pazaryeri yazılımları katalog, satıcı yönetimi ve sipariş gibi standart akışları hızlıca çözer. Ancak kurumun özgün komisyon modeli, sektöre özel onay hiyerarşisi, mevcut ERP ile derin bütünleşme veya olağandışı ölçek ihtiyaçları devreye girdiğinde hazır ürünün sınırlarına gelinir. Bu sayfa, talep üzerine (kuruma özel) pazaryeri geliştirmeyi değerlendiren operasyon, e-ticaret, lojistik ve tedarik ekipleri için kapsamı, karar çerçevesini ve mimari kriterleri anlatır.
Ne zaman talep üzerine geliştirme? (build vs buy)
Karar bir his değil, ölçülebilir bir eğilimdir. Basit bir eğilim ölçütü: Build eğilimi = Σ(özgün gereksinim ağırlığı) ÷ (hazır ürün kapsama oranı). Oran bire yaklaştıkça veya aştıkça özel geliştirme öne çıkar; belirgin biçimde birin altındaysa hazır ürün + yapılandırma yeterlidir. Bu oranı stratejik önem ve veri sahipliği ihtiyacı ile birlikte okuyun.
| Kriter | Hazır ürün (buy) | Talep üzerine (build) |
|---|---|---|
| Başlangıç hızı | Yüksek | Düşük–orta (aşamalı hızlanır) |
| Özel iş kuralları | Yapılandırma ile sınırlı | Tam esneklik |
| Veri sahipliği | Tedarikçiye bağlı | Kurumda |
| Vendor lock-in | Yüksek olabilir | Mimariyle azaltılır |
| Bakım sorumluluğu | Tedarikçide | Kurumda / geliştirme ekibinde |
Aşamalı yol haritası: keşif → PoC → MVP → canlı
Talep üzerine geliştirme, riski öne çekerek ilerler. Önce belirsizliği en yüksek varsayımlar doğrulanır, sonra çekirdek akış üretime taşınır. Aşağıdaki süreler temsilidir; kapsam, entegrasyon sayısı ve karar hızıyla değişir.
| Aşama | Çıktı | Süre (temsili) |
|---|---|---|
| Keşif | Gereksinim ve kapsam dokümanı, risk haritası, entegrasyon envanteri | 1–2 hafta |
| PoC | En riskli varsayımın (kanal API, komisyon, senkron) doğrulandığı ispat | 2–4 hafta |
| MVP | Canlıya yakın çekirdek akış: satıcı, katalog, sipariş, ödeme ayrıştırma | 6–12 hafta |
| Canlı | Üretim, izleme/uyarı, SLA, kademeli açılım ve iterasyon | Sürekli |
Entegrasyon eforu nasıl tahmin edilir?
Pazaryerinin gerçek yükü çoğunlukla entegrasyonlardadır. Kaba bir tahmin için: Toplam entegrasyon eforu ≈ uç nokta sayısı × uç nokta başına ortalama efor (adam-gün). Bu formül yanıltıcı olabilir; çünkü her uç nokta yalnızca "veri çekmek" değildir. Her bağlantı için ek eforu unutmayın:
- Kimlik doğrulama, yetkilendirme ve anahtar/token yenileme.
- Hız sınırları (rate limit), tekrar deneme (retry) ve idempotensi.
- Hata yönetimi, mutabakat (reconciliation) ve tutarlılık kontrolleri.
- Kargo, ödeme ve e-belge tarafında kenar durumların (iade, kısmi sevkiyat, iptal) ele alınması.
Bu nedenle uç nokta başına eforu, geçmiş verinizle kalibre edilmiş bir karmaşıklık katsayısı ile çarpmak daha gerçekçi bir tahmin verir.
PoC başarı kriteri
PoC, "güzel görünen bir demo" değil, bir karar aracıdır. Net bir başarı tanımı olmadan başlatılmamalıdır: PoC başarılı = (kritik varsayım doğrulandı) ∧ (ölçülen metrik ≥ önceden tanımlı eşik) ∧ (süre/bütçe sınırı aşılmadı). Eşik ve metrik baştan yazılır (ör. "1.000 ürünlük katalog 5 dakikada senkronize olmalı"). Üç koşuldan biri sağlanmıyorsa PoC "başarısız" değil, "karar verdiren" sonuçtur: kapsamı daraltır veya build kararını gözden geçirtir.
Mimari ve kapsam
- Mikroservis/API mimarisi: Katalog, satıcı, sipariş, ödeme ayrıştırma ve bildirim gibi alanların gevşek bağlaşımlı, bağımsız ölçeklenebilir servisler olarak kurgulanması.
- Özel kanal entegrasyonu: Standart olmayan tedarikçi/pazaryeri/kanal API'lerine adapter (soyutlama) katmanıyla bağlanma; kanal ekleme maliyetini sabitleme.
- ERP/muhasebe köprüsü: Stok, cari, sipariş ve fatura verisinin çift yönlü senkronu; GİB e-Fatura/e-Arşiv/e-İrsaliye belge akışının otomasyonu.
- Özel iş kuralları: Komisyon/tahsis modelleri, kademeli fiyatlandırma, onay hiyerarşisi ve kural motoru.
- Ölçek: Olay/iş kuyruğu, önbellek, yatay ölçekleme ve gözlemlenebilirlik (log/metrik/izleme).
Sektörden örnek: kendi platformuyla ölçeklenen model (model analizi)
Özel geliştirmenin ölçekte nasıl karşılık bulduğunu görmek için halka açık verisi olan yerli bir platforma bakılabilir. Nasdaq'ta işlem gören Hepsiburada'nın 2024 yıl sonu finansal sonuçlarına göre platformdaki işlem hacminin (GMV) yüzde 69,8'i üçüncü taraf satıcıların oluşturduğu pazaryeri modelinden gelmiştir (2023: yüzde 66,9); aktif satıcı sayısı 100,2 bin, aktif müşteri sayısı 12,2 milyon olarak açıklanmıştır (Hepsiburada 4Ç/2024 finansal sonuçları, 2025).
Bu tablo bizim işimiz değil, kamuya açık verinin analizidir; ancak build-vs-buy kararına dair iki net ders içerir. Birincisi, ölçekli bir pazaryerinin gelir motoru kendi (1P) satışından üçüncü taraf (3P) modeline kaymaktadır; bu kayma komisyon, hakediş, satıcı puanlama ve lojistik seçenekleri gibi platforma özgü iş kuralları gerektirir — tam da hazır paketlerin şablon sınırlarına takıldığı alanlar. İkincisi, yüz bin satıcı ve milyonlarca müşteriyi aynı anda taşıyan bir sistem, iş modelinin gereksinimlerine göre evrilen, sahibi belli bir yazılım mimarisi olmadan yönetilemez. Niş bir dikeyde kurulacak platform bu ölçekte başlamaz; ama aynı kural motorlarının küçük ölçekli, büyüyebilir versiyonuna ilk günden ihtiyaç duyar.
Temsili proje kapsamı
Aşağıdaki kapsam temsilidir; gerçek kapsam keşif çıktılarıyla netleşir ve fiyat bilgisi içermez. Talep üzerine geliştirilen tipik bir pazaryeri/entegrasyon projesinin iskeleti şöyledir:
- Keşif ve karar: Gereksinim envanteri, build-vs-buy analizi, risk haritası ve aşama planı.
- PoC: En riskli varsayımın (kanal API sınırı, senkron gecikmesi, komisyon doğruluğu) ölçülebilir eşikle doğrulanması.
- MVP çekirdeği: Satıcı/katalog/sipariş akışı, ödeme ayrıştırma ve temel raporlama; gerçek kullanıcıya açılabilir sürüm.
- Entegrasyon katmanı: ERP/muhasebe köprüsü, GİB e-belge akışı ve adapter mimarisiyle özel kanal bağlantıları.
- Kural motoru: Komisyon/tahsis modelleri, kademeli fiyatlandırma ve onay hiyerarşisinin yapılandırılabilir kurgusu.
- Canlıya geçiş: İzleme/uyarı altyapısı, kademeli açılım, yük testi ve geri dönüş planı.
- Devir: Kaynak kodu teslimi, teknik dokümantasyon, ekip eğitimi ve bakım SLA çerçevesi.
Seçim ve şartname kriterleri
- Veri sahipliği: Tüm verinin (şema dahil) kurumda kalması ve tam dışa aktarımın sözleşmede garanti edilmesi.
- Vendor lock-in önlemi: Açık standartlar, adapter katmanları ve standart formatlarla tedarikçi değişiminin tüm sistemi yeniden yazmadan mümkün olması.
- API-first: Her yeteneğin dokümante, sürümlenmiş API ardında sunulması; entegrasyonun sonradan eklenen değil, tasarımın çekirdeği olması.
- KVKK-by-design: 6698 uyumunun tasarım aşamasında kurgulanması — veri minimizasyonu, rol/yetki, denetim izi, saklama süreleri; ticari ileti için İYS onay yönetimi.
- Mevzuat uyumu: 6563 sayılı Kanun kapsamında ATHS/ETHS sorumluluk ayrımı, ETBİS kayıt/bildirim yükümlülükleri ve ödeme tarafında PCI DSS kapsamının (mümkünse ödeme kuruluşuna devrederek) daraltılması.
Süreçlerinizi birlikte inceleyip hazır çözümün mü yeterli olduğunu yoksa talep üzerine geliştirmenin mi doğru olduğunu netleştirelim; gerekiyorsa keşif ve PoC ile riski önce doğrularız. Aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.
Merak edilenler
Hazır pazaryeri yazılımı mı, talep üzerine geliştirme mi?
Standart satıcı, katalog ve sipariş akışları için hazır bir pazaryeri yazılımı hızla değer üretir. Ancak süreçleriniz özgünse, mevcut ERP/muhasebeye derin entegrasyon gerekiyorsa veya sektöre özel iş kuralları (fiyatlandırma, komisyon, tahsis, onay hiyerarşisi) varsa talep üzerine geliştirme ya da hazır çekirdek + özel modül daha doğrudur. Basit bir eğilim ölçütü: özgün gereksinimlerin ağırlığı ile hazır ürün kapsama oranını karşılaştırmaktır; oran bire yaklaştıkça özel geliştirme öne çıkar.
PoC ile MVP arasındaki fark nedir?
PoC (kavram kanıtı) tek bir amaç taşır: en riskli varsayımı (ör. bir kanalın API sınırları, stok senkron gecikmesi, komisyon hesabının doğruluğu) sabit süre ve bütçe içinde doğrulamak; sıklıkla atılabilir koddur. MVP ise üretim hattına giren, canlıya en yakın çekirdek akıştır: gerçek satıcı onboarding, sipariş, ödeme ayrıştırma ve temel raporlama ile sınırlı ama gerçek kullanıcıya açılabilir. PoC "yapılabilir mi?", MVP "en küçük değerli sürüm nedir?" sorusunu yanıtlar.
Pazaryerimizi hangi mevzuata göre kurgulamalıyız?
Pazaryeri işletmecisi 6563 sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun kapsamında aracı hizmet sağlayıcı (ATHS) konumundadır; platformda satan taraf ise elektronik ticaret hizmet sağlayıcı (ETHS) sayılır ve sorumluluk paylaşımı bu ayrıma göre kurgulanır. ETBİS (Elektronik Ticaret Bilgi Sistemi) kayıt/bildirim yükümlülükleri, KVKK 6698 kapsamında veri işleme esasları, ticari ileti için İYS (İleti Yönetim Sistemi) onayları, faturalama için GİB e-Fatura/e-Arşiv/e-İrsaliye entegrasyonu ve ödeme tarafında PCI DSS mimari kararlarınızı doğrudan etkiler.
Vendor lock-in riskini nasıl azaltırız?
Sözleşmede veri sahipliğini ve tam dışa aktarımı (şema dahil) garanti altına alın; API-first mimari, açık ve dokümante standartlar, olay/iş kuyruğu tabanlı gevşek bağlaşım ve standart veri formatları (JSON, CSV, e-belge XML) kullanın. Kimlik doğrulama, ödeme ve kargo gibi dış bağımlılıkları soyutlama katmanı (adapter) ardında tutarsanız tedarikçi değişimi tüm sistemi yeniden yazmadan mümkün olur.
Canlıya geçtikten sonra bakım ve geliştirme sahipliği nasıl işler?
Özel geliştirmede kaynak kodu size teslim edildiği için üç yol açıktır: bakım ve yeni geliştirmeleri aynı ekiple sürdürmek, kendi iç ekibinize devralmak veya ikisini karma yürütmek (kritik modüller dışarıda, günlük operasyon içeride). Hangi yol seçilirse seçilsin; sürüm geçmişi, teknik dokümantasyon, test paketi ve dağıtım (deployment) otomasyonunun devir kapsamında olması gerekir. Sağlıklı bir sözleşme, bakım SLA’sını (yanıt/çözüm süreleri) ve yeni istekler için efor-onay mekanizmasını baştan tanımlar; böylece canlı sistem kişiye bağımlı olmaktan çıkar.
Hazır platformdan özel yazılıma geçiş (re-platform) nasıl planlanır?
Re-platform projelerinde en büyük risk büyük patlama (big bang) geçişidir; doğru yaklaşım aşamalı geçiştir. Önce veri envanteri çıkarılır (ürün, satıcı, sipariş geçmişi, cari), eski sistemden dışa aktarım ve veri temizliği yapılır. Yeni platform önce tek kategori, tek satıcı grubu veya salt-okunur katalog gibi dar bir kapsamla canlıya alınır; eski ve yeni sistem bir süre paralel çalışır ve siparişler kademeli aktarılır. URL yapısı ve SEO yönlendirmeleri, e-belge seri devamlılığı ve açık siparişlerin taşınması geçiş planının kritik kalemleridir. Geri dönüş (rollback) senaryosu her aşamada tanımlı olmalıdır.
Kendi pazaryerinizi size özel geliştirelim.
Pazaryeri fikrinizi ya da mevcut ihtiyacınızı yazın; iş modelinden geliştirmeye tek elden değerlendirip 1 iş günü içinde dönelim. Hazır paket değil — kaynak kodu sizin, size özel.
Talep Oluştur