E-pin Scripti Satan Kişinin Teknik Yeterliliğini 11 Soruda Çöz: Demo Gösterirken Senden Özenle Sakladığı Şeyi Kendi Gözünle Gör

Bir e-pin scripti almaya karar verdiğin an gözün ilk olarak ekran görüntülerine kayar. Panel koyu temalı mı, grafikler hareketli mi, sepet animasyonu akıcı mı. Çoğu kişi şunu sanır: arayüz bu kadar toparlanmışsa arkadaki kod da sağlamdır. Oysa bu ikisi arasında neredeyse hiç bağ yok. Arayüz bir hafta sonunda hazır şablonla toparlanabilir; sipariş kuyruğunun eşzamanlı yüz talebi karıştırmadan işlemesi ise aylarca süren bir mühendislik işidir. Sen ilkini satın alıyorsun sanıyorsun, faturayı ikincisinin eksikliğiyle ödüyorsun.

Bu yazı, satıcıya "kaç yıllık tecrübeniz var" diye sormayı bırakman için yazıldı. Onun yerine, cevabı kolay uydurulamayan on bir sorunun ve iki tablonun peşine düşeceğiz. Amaç satıcıyı köşeye sıkıştırmak değil; dijital ürün satış scripti pazarında teknik yeterliliğin sözle değil izle ölçüldüğünü göstermek. Güncelleme kaydı, hata yönetimi, log dosyası, devir teslim maddesi. Bunlar yalan söylemez, çünkü sonradan üretilmesi zahmetlidir.

Demo paneli neden sana neredeyse hiçbir şey anlatmıyor?

Demo ortamı, satıcının kontrol ettiği bir sahnedir. Orada veri temizdir, sipariş sayısı azdır, ödeme sağlayıcısı simülasyondur ve hiçbir kullanıcı aynı e-pini iki kez almaya çalışmaz. Senin işletmende olacak şeylerin hiçbiri demoda olmaz. Bir e-pin satış yazılımı gerçek dünyada dört yerden çatlar: ödeme bildirimi geciktiğinde, aynı stok kalemine iki sipariş aynı saniyede düştüğünde, tedarikçi API'si zaman aşımına uğradığında ve iade talebi otomatik teslim edilmiş bir koda geldiğinde. Demo bunların hiçbirini göstermez.

Yapman gereken şey basit: satıcıdan demo değil, senaryo istemek. "Ödeme onayı geldi ama stok bitti, sistem ne yapıyor?" diye sor. Yetkin bir geliştirici sana kuyruğun nasıl kilitlendiğini, siparişin hangi statüye düştüğünü ve müşteriye hangi mesajın gittiğini adım adım anlatır. Yetkin olmayan kişi "öyle bir şey olmaz" der. Bu cümleyi duyduğun anda konuşma bitmiştir; çünkü o durumun olmadığını söyleyen biri, o durumu hiç yaşamamış demektir.

Satıcının kodu gerçekten kendisi mi yazdı, nasıl anlarsın?

Pazardaki epin yazılım satıcılarının bir kısmı geliştirici değil, yeniden paketleyicidir. Başka bir ürünü alır, logoyu değiştirir, iki rengi çevirir ve kendi markasıyla satar. Bunu anlamanın en kestirme yolu, ürünün kendi dışındaki bir parçasını sormaktır. Örneğin kur dönüşümünün nerede hesaplandığını, bakiye düşümünün veritabanı tarafında mı uygulama tarafında mı kilitlendiğini, bildirim kuyruğunun cron ile mi yoksa anlık tetikleyiciyle mi çalıştığını sor.

Kodu yazan kişi bu soruları sevmez ama rahat cevaplar; çünkü o kararları kendisi almıştır ve neden öyle yaptığını anlatmak ister. Yeniden paketleyici ise genel cümlelere kaçar: "altyapımız çok güçlü", "her şey optimize". İkinci tip cevapta hiçbir karar yoktur. Bir ürünün arkasında karar yoksa, o üründe seni ilgilendiren bir mühendislik de yoktur. Pinova gibi sürdürülen bir e-pin satış scripti üzerinde konuşurken bu ayrım tek başına saatlerini kurtarır.

Güncelleme kaydı neden yetkinliğin en dürüst göstergesi?

Bir yazılımın changelog'u, geliştiricisinin karakter referansıdır. Tarih tarih yazılmış, sürüm numaralı, "şu hata giderildi / şu davranış değişti" diyen bir liste, o kişinin kendi ürününü takip ettiğini kanıtlar. Böyle bir kayıt tutmayan satıcı, sana sattığı şeyin hangi halde olduğunu kendisi de bilmiyor demektir. Daha kötüsü, altı ay sonra bir güvenlik yaması gerektiğinde nereye dokunacağını hatırlamayacaktır.

Kayda bakarken sürüm sayısını değil ritmi oku. Üç yılda iki güncelleme, ürünün terk edildiğini gösterir. Ayda kırk güncelleme ise çoğu zaman panik yamasıdır; sürekli kırılan bir sistemin izi. Sağlıklı ritim, ayda birkaç anlamlı iyileştirme ve her PHP ya da ödeme sağlayıcısı değişiminde zamanında gelen uyum yamasıdır. Dijital ürün satış yazılımı seçerken bu tek metriği okumak, on sayfalık özellik listesinden daha fazla şey söyler. Ürünün neleri kapsadığını görmek için özellikler bölümünü de aynı gözle incele.

Entegrasyon konuşmasında hangi cümle seni durdurmalı?

Ödeme sağlayıcısı ve tedarikçi bağlantıları, bir e-pin yazılımı projesinin en çok zaman yiyen kısmıdır. Burada duyacağın en tehlikeli cümle şudur: "O entegrasyonu senin için de yaparız." Kulağa iyi gelir ama içinde iki bilgi saklıdır. Birincisi, o entegrasyon bugün üründe yok. İkincisi, ilk kez senin kurulumunda denenecek. Yani beta müşteri sensin ve muhtemelen bunun için ayrıca ödeyeceksin.

Doğru soru "yapar mısınız" değil, "şu an kaç kurulumda çalışıyor" olmalı. Çalışan bir örnek varsa, o örneğin sahibine ulaşmak istemek senin en doğal hakkındır. Ayrıca entegrasyonun hangi tarafta durduğunu netleştir: bildirim doğrulaması sunucu tarafında mı yapılıyor, yoksa tarayıcıdan dönen bilgiye mi güveniliyor. İkincisi ise bu bir entegrasyon değil, açık kapıdır. Fiyat tarafında bu kalemlerin nasıl fiyatlandığını fiyat bölümünde karşılaştırabilirsin.

Destek süresi mi destek kalitesi mi? İkisini ayıran tek test

"Bir yıl ücretsiz destek" ifadesi tek başına hiçbir şey ifade etmez. Süre, kalitenin ölçüsü değildir. Bir yıl boyunca her talebine "inceliyoruz" diye dönen bir ekip de teknik olarak sözünü tutmuş sayılır. Kaliteyi ölçmek için satın alma öncesinde bir test yap: satıcıya somut, cevaplanması emek isteyen bir soru gönder. Örneğin "kurulumda PHP sürümü uyuşmazsa hangi dosyayı düzeltmem gerekir" gibi.

Dönüş süresi kadar dönüşün biçimine bak. Sana dosya adı, satır aralığı ya da komut veren bir cevap geldiyse karşında işini bilen biri var. Sadece "bize bağlanalım biz bakalım" diyen bir cevap ise bilgi paylaşmama alışkanlığını gösterir; bu alışkanlık ileride her küçük ayarda satıcıya bağımlı kalmak anlamına gelir. Bağımlılık teknik bir sorun değil ama ticari olarak en pahalı olanıdır.

Devir teslim ve kaynak kod: sözleşmede aranması gereken maddeler

Teknik yeterlilik, teslim anında en net görülür. Sana yalnızca bir zip dosyası gönderiliyorsa iş yarım bırakılmıştır. Düzgün bir teslimde şunlar olur: sunucu gereksinimleri yazılı, kurulum adımları belgeli, veritabanı yedeği alınmış, yönetici erişimleri sana devredilmiş, kritik ayar dosyaları açıklanmış. Ayrıca lisans modelinin ne olduğu, alan adı değişirse ne olacağı ve güncellemelerin nasıl geleceği tek tek yazılmış olmalı.

Kaynak kod konusunda net ol. Şifrelenmiş dosyalarla çalışan bir kurulumda ileride küçük bir metin değişikliği bile satıcıya muhtaç kalmak demektir. Şifreleme tek başına kötü değildir; kötü olan, hangi bölümlerin kapalı olduğunun sana söylenmemesidir. Satın almayı tamamlamadan önce bu maddeleri yazılı hale getir; sipariş adımında teslim kapsamının açıkça tanımlı olması, sonradan yaşanacak tartışmaların neredeyse tamamını ortadan kaldırır.

Teknik yeterlilik, bir satıcının anlattığı hikâyede değil bıraktığı izlerde durur. Bu yazıdaki soruları elinde tutup görüşmeye gir; hangi cevabın hazır, hangisinin uydurma olduğunu üçüncü soruda ayırt etmeye başlayacaksın. Pinova'nın bu izleri nasıl bıraktığını merak ediyorsan, senaryoları kendi elinle denemek için canlı demo üzerinden panele gir, sonra aynı soruları başka satıcılara da sor; farkı kıyaslama anında göreceksin.