Hazır bir PHP script satın almak geliştirme süresini kısaltabilir; fakat çalışan bir demo, güvenli ve devredilebilir bir ürün aldığınızı tek başına kanıtlamaz. Kaynak kodun kullanım hakkı, bağımlılık lisansları, gizli erişimler, güncelleme kapasitesi, veri tabanı geçişi ve destek koşulları incelenmeden yapılan alım sonradan yüksek maliyet çıkarabilir.
Bu rehber alıcı ve satıcı için ortak bir teslim standardı sunar. Amaç pazarlık taktiği vermek değil; neyin satıldığını, hangi hakların devredildiğini ve yazılımın güvenli biçimde nasıl kabul edileceğini ölçülebilir hâle getirmektir.
“E-ticaret scripti” gibi genel ifade yeterli değildir. Modüller, kullanıcı rolleri, ödeme yöntemleri, API’ler, yönetim paneli, tema, mobil uyum, çoklu dil, raporlar ve dış servisler madde madde yazılmalıdır. Demo ile teslim paketinin aynı özellikleri içerdiği doğrulanmalıdır.
Teslimin lisans mı, kaynak kod kopyası mı, münhasır hak devri mi yoksa mevcut işin tamamının devri mi olduğu açık olmalıdır. Yazılımı kullanabilmek, yeniden satabilmek ve telif hakkına sahip olmak birbirinden farklı haklardır.
Satıcı, kodu kendisinin geliştirdiğini veya satış ve alt lisans verme yetkisine sahip olduğunu kanıtlamalıdır. Fatura, sözleşme, repository geçmişi, geliştirici anlaşmaları ve üçüncü taraf bileşen listesi birlikte incelenebilir.
Başka bir ürünün kaldırılmış lisans kontrolüyle sunulması, internetten toplanmış kod veya çalışan tarafından yazılmış fakat hakkı devredilmemiş modül ciddi risk taşır. Alan adı ve marka devri varsa bunlar kod lisansından ayrı belgelenmelidir.
Kullanım alanı, kurulum sayısı, müşteri sayısı, süre, güncelleme, destek, değişiklik yapma, yedek kopya, yeniden dağıtım ve alt lisans hakları açıkça belirtilmelidir. “Ömür boyu” ifadesi kimin ömrünü ve hangi hizmetleri kapsadığını söylemediği sürece belirsizdir.
Açık kaynak paketlerin kendi lisans yükümlülükleri bulunabilir. Ticari ana ürün satın alınsa bile MIT, BSD, Apache, GPL veya başka lisanslara tabi bileşenler ayrı koşullar getirebilir. Hukuki belirsizlik yüksekse uzman görüşü alın.
Aynı kodun başka müşterilere daha önce lisanslanıp lisanslanmadığını, mevcut müşterilerin haklarını ve satıcının gelecekte benzer ürün geliştirme sınırını sözleşmede açıklayın. Gerçekçi olmayan mutlak yasaklar yerine açık fikrî mülkiyet kapsamı yazın.
Yalnız ZIP dosyası yeterli olmayabilir. Git geçmişi, sürüm etiketi, README, kurulum adımları, composer.json ve composer.lock, migration, seed, testler, cron görevleri, queue ayarları, web sunucusu örneği ve ortam değişkeni şablonu teslim kapsamına alınmalıdır.
Derlenmiş ön yüz dosyaları varsa kaynak paket, build komutu ve paket kilit dosyası da bulunmalıdır. Özel Composer repository, ücretli paket veya lisans sunucusu kullanılıyorsa erişim devri ve devam maliyeti açıklanmalıdır.
Scriptin doğrudan ve dolaylı bağımlılıklarını bilmek güvenlik ile lisans yönetimi için gereklidir. composer.lock gerçek çözümlenmiş sürümleri gösterir. Daha olgun teslimlerde Software Bill of Materials, bileşen adı, sürüm, kaynak ve lisans bilgisini ortak formatta sunabilir.
, yazılım bileşenleri ve SBOM bilgisi için uluslararası standart olarak kullanılan açık bir formattır. Küçük projede tam otomasyon şart olmayabilir; en azından bağımlılık ve lisans tablosu hazırlanmalıdır.
Composer’ın [URL=https://getcomposer.org/doc/03-cli.md#audit]audit komutu, kurulu paketleri bilinen güvenlik duyuruları ve tanımlı bağımlılık politikalarına göre denetler; terk edilmiş veya zararlı olarak işaretlenen paketleri de raporlayabilir. Teslim alınan kodda kilit dosyasıyla audit çalıştırın.
Temiz audit sonucu “kod güvenlidir” demek değildir. Bilinmeyen açık, özel kod hatası, yanlış yapılandırma veya zararlı özel modül görünmeyebilir. Sonuç tarihini ve kullanılan repository’leri kaydedin; üretimden sonra denetimi düzenli tekrarlayın.
Otomatik taramaya ek olarak deneyimli geliştirici kritik akışları okumalıdır. OWASP’ın Güvenli Kod İnceleme rehberi, otomatik aracın kaçırabileceği uygulama mantığı ve veri akışı sorunlarını bulmak için manuel incelemeyi vurgular.
Öncelik; kimlik doğrulama, yetkilendirme, dosya yükleme, ödeme, admin işlemleri, SQL, komut çalıştırma, uzaktan istek, güncelleme mekanizması ve dış API anahtarlarıdır. Gizlenmiş kod, base64 ile anlamsızlaştırılmış uzun bloklar veya bilinmeyen dış alan adına çağrı açıklanmalıdır.
Sabit yönetici hesabı, gizli URL, lisans bahanesiyle uzaktan komut, habersiz veri gönderimi, kontrolsüz eval/exec ve uzak kaynaktan kod indirme yüksek risklidir. Her kullanım kötü niyetli olmayabilir; fakat iş gerekçesi ve sınırı kanıtlanmalıdır.
Satıcının demosuna bakmak yerine mümkünse temiz ve kontrol edilen bir test ortamına kurulum yapın. Kurulum dokümanını başka bir geliştirici takip etsin. Gerekli PHP sürümü, eklentiler, web sunucusu, veri tabanı ve dosya izinleri kaydedilsin.
Ana rollerle giriş, parola sıfırlama, kayıt, arama, ödeme sandbox, e-posta, dosya yükleme, queue ve cron akışlarını test edin. Hata durumlarını da deneyin: dış servis kapalı, ödeme başarısız, dosya bozuk ve çift gönderim gibi.
“Binlerce kullanıcı kaldırır” ifadesi test koşulu olmadan anlamsızdır. Donanım, veri büyüklüğü, eş zamanlı kullanıcı, istek türü, cache ve ölçülen percentile değerleri belirtilmelidir. Küçük boş veri tabanındaki hızlı demo üretim yükünü temsil etmez.
Yavaş sorgu, N+1, eksik indeks, sınırsız liste ve büyük dosya işleme kontrol edilmelidir. Ölçek ihtiyacı gerçek değilse karmaşık dağıtık mimari için fazladan ödeme yapmayın.
Şema yalnız SQL dump olarak verilmemeli; sürümlü migration ve başlangıç verisi ayrılmalıdır. Mevcut sistemden veri taşınacaksa alan eşleme, karakter seti, saat dilimi, dosyalar, kullanıcı parolası ve hata raporu planlanmalıdır.
Migration önce anonimleştirilmiş kopyada denenmeli. Satır sayısı, toplamlar ve kritik ilişkiler kabul kriteri olarak karşılaştırılmalıdır. Geri dönüş ve yedek doğrulaması olmadan canlı veri üzerinde tek yönlü işlem yapılmamalıdır.
Teslim paketinde gerçek .env, veritabanı yedeği, müşteri bilgisi, API anahtarı, SMTP parolası veya ödeme tokenı bulunmamalıdır. Satıcı tüm sırları iptal edip alıcının yeni değerlerle kurulum yapmasını sağlamalıdır.
Örnek veri yapay olmalı. Log, upload ve cache dizinleri kontrol edilmelidir. Ürünün topladığı kişisel veriler, saklama süresi, silme işlevi ve erişim rolleri belgelenmelidir.
Script kendi kendine güncelleniyorsa paket kaynağı, bütünlük doğrulaması, HTTPS, imza, sürüm notu ve rollback incelenmelidir. Satıcının alan adı kapanırsa uygulamanın çalışıp çalışmayacağı bilinmelidir.
Otomatik güncelleme üretimde doğrudan çalışmamalı; önce test ortamında kurulup migration ve uyumluluk kontrolünden geçmelidir. Güncelleme desteğinin süresi ve ücretli olup olmadığı sözleşmeye yazılmalıdır.
Destek; kanal, saat, yanıt hedefi, kapsanan hata, sürüm aralığı ve hariç işleri tanımlamalıdır. Yeni özellik ile garanti hatası ayrılmalıdır. Tek geliştiriciye bağlı projede kaynak dokümantasyonu ve devir oturumu daha kritiktir.
PHP, framework ve bağımlılıkların destek sonu takip edilmelidir. Güvenlik düzeltmesinin kaç gün içinde yayımlanacağı ve müşteriye nasıl bildirileceği belirlenmelidir.
Ödemeyi yalnız ekran görüntüsü veya sözlü vaatle tamamlamayın. Aşamalar; demo, kod inceleme, test kurulumu, kritik hata düzeltme, canlı geçiş ve son kabul olarak bölünebilir. Güvenilir ödeme veya escrow mekanizması taraf riskini azaltabilir.
Kabul kriterleri ölçülebilir olmalıdır: belirtilen modüller çalışıyor, audit sonucu teslim edildi, kritik güvenlik açığı yok, doküman tamam ve alıcının ortamında kurulum başarıyla tekrarlandı gibi.
Repository, domain, lisans paneli, paket hesabı, e-posta sağlayıcısı, ödeme entegrasyonu ve üçüncü taraf servislerin sahipliği tek tek aktarılmalıdır. Satıcının erişimleri son kabulden sonra kaldırılır; anahtarlar yenilenir.
Yeni yönetici hesapları ve iki faktörlü doğrulama alıcının kontrolünde kurulmalıdır. Yedek alınır, geri yükleme test edilir ve ilk üretim izleme penceresi planlanır. Devir, ZIP indirmek değil operasyonun kontrolünü kanıtla almaktır.
Alınabilir ancak kaynak incelemesi, değiştirme, PHP sürüm yükseltmesi ve satıcıya bağımlılık sınırlanır. Hangi dosyaların kapalı olduğu, loader gereksinimi, lisans sunucusu ve satıcı ortadan kalkarsa çalışma durumu açıkça değerlendirilmelidir.
Hayır. Antivirüs bilinen kalıbı bulabilir; iş mantığı açığını, gizli admin yetkisini veya güvensiz veri akışını kaçırabilir. Bağımlılık denetimi, statik analiz, manuel inceleme ve çalışma testi birlikte gerekir.
Lisans ihlali yanında kodun değiştirilmiş, arka kapılı veya güncellemesiz olma ihtimali yüksektir. Kaynağı ve bütünlüğü doğrulanamayan script üretim verisine erişmemelidir.
PHP script alım satımında en ucuz teklif, toplam maliyeti en düşük teklif olmayabilir. Lisans belirsizliği, güvensiz bağımlılık ve eksik teslim daha sonra yeniden geliştirme kadar pahalı olabilir. İyi alışveriş; hakları, kod bileşimini, güvenlik durumunu ve operasyon devrini bağımsız biçimde doğrulayabildiğiniz alışveriştir.
Bu rehber alıcı ve satıcı için ortak bir teslim standardı sunar. Amaç pazarlık taktiği vermek değil; neyin satıldığını, hangi hakların devredildiğini ve yazılımın güvenli biçimde nasıl kabul edileceğini ölçülebilir hâle getirmektir.
Önce satın alınan şeyin kapsamını tanımlayın
“E-ticaret scripti” gibi genel ifade yeterli değildir. Modüller, kullanıcı rolleri, ödeme yöntemleri, API’ler, yönetim paneli, tema, mobil uyum, çoklu dil, raporlar ve dış servisler madde madde yazılmalıdır. Demo ile teslim paketinin aynı özellikleri içerdiği doğrulanmalıdır.
Teslimin lisans mı, kaynak kod kopyası mı, münhasır hak devri mi yoksa mevcut işin tamamının devri mi olduğu açık olmalıdır. Yazılımı kullanabilmek, yeniden satabilmek ve telif hakkına sahip olmak birbirinden farklı haklardır.
Satıcının kaynak kod üzerindeki hakkını doğrulayın
Satıcı, kodu kendisinin geliştirdiğini veya satış ve alt lisans verme yetkisine sahip olduğunu kanıtlamalıdır. Fatura, sözleşme, repository geçmişi, geliştirici anlaşmaları ve üçüncü taraf bileşen listesi birlikte incelenebilir.
Başka bir ürünün kaldırılmış lisans kontrolüyle sunulması, internetten toplanmış kod veya çalışan tarafından yazılmış fakat hakkı devredilmemiş modül ciddi risk taşır. Alan adı ve marka devri varsa bunlar kod lisansından ayrı belgelenmelidir.
Lisans metninde hangi haklar yazmalı?
Kullanım alanı, kurulum sayısı, müşteri sayısı, süre, güncelleme, destek, değişiklik yapma, yedek kopya, yeniden dağıtım ve alt lisans hakları açıkça belirtilmelidir. “Ömür boyu” ifadesi kimin ömrünü ve hangi hizmetleri kapsadığını söylemediği sürece belirsizdir.
Açık kaynak paketlerin kendi lisans yükümlülükleri bulunabilir. Ticari ana ürün satın alınsa bile MIT, BSD, Apache, GPL veya başka lisanslara tabi bileşenler ayrı koşullar getirebilir. Hukuki belirsizlik yüksekse uzman görüşü alın.
Münhasır devirde ek kontroller
Aynı kodun başka müşterilere daha önce lisanslanıp lisanslanmadığını, mevcut müşterilerin haklarını ve satıcının gelecekte benzer ürün geliştirme sınırını sözleşmede açıklayın. Gerçekçi olmayan mutlak yasaklar yerine açık fikrî mülkiyet kapsamı yazın.
Kaynak kod teslimatı tam mı?
Yalnız ZIP dosyası yeterli olmayabilir. Git geçmişi, sürüm etiketi, README, kurulum adımları, composer.json ve composer.lock, migration, seed, testler, cron görevleri, queue ayarları, web sunucusu örneği ve ortam değişkeni şablonu teslim kapsamına alınmalıdır.
Derlenmiş ön yüz dosyaları varsa kaynak paket, build komutu ve paket kilit dosyası da bulunmalıdır. Özel Composer repository, ücretli paket veya lisans sunucusu kullanılıyorsa erişim devri ve devam maliyeti açıklanmalıdır.
Bağımlılık envanteri ve SBOM
Scriptin doğrudan ve dolaylı bağımlılıklarını bilmek güvenlik ile lisans yönetimi için gereklidir. composer.lock gerçek çözümlenmiş sürümleri gösterir. Daha olgun teslimlerde Software Bill of Materials, bileşen adı, sürüm, kaynak ve lisans bilgisini ortak formatta sunabilir.
, yazılım bileşenleri ve SBOM bilgisi için uluslararası standart olarak kullanılan açık bir formattır. Küçük projede tam otomasyon şart olmayabilir; en azından bağımlılık ve lisans tablosu hazırlanmalıdır.
Composer audit neyi kontrol eder?
Composer’ın [URL=https://getcomposer.org/doc/03-cli.md#audit]audit komutu, kurulu paketleri bilinen güvenlik duyuruları ve tanımlı bağımlılık politikalarına göre denetler; terk edilmiş veya zararlı olarak işaretlenen paketleri de raporlayabilir. Teslim alınan kodda kilit dosyasıyla audit çalıştırın.
Temiz audit sonucu “kod güvenlidir” demek değildir. Bilinmeyen açık, özel kod hatası, yanlış yapılandırma veya zararlı özel modül görünmeyebilir. Sonuç tarihini ve kullanılan repository’leri kaydedin; üretimden sonra denetimi düzenli tekrarlayın.
Manuel güvenli kod incelemesi
Otomatik taramaya ek olarak deneyimli geliştirici kritik akışları okumalıdır. OWASP’ın Güvenli Kod İnceleme rehberi, otomatik aracın kaçırabileceği uygulama mantığı ve veri akışı sorunlarını bulmak için manuel incelemeyi vurgular.
Öncelik; kimlik doğrulama, yetkilendirme, dosya yükleme, ödeme, admin işlemleri, SQL, komut çalıştırma, uzaktan istek, güncelleme mekanizması ve dış API anahtarlarıdır. Gizlenmiş kod, base64 ile anlamsızlaştırılmış uzun bloklar veya bilinmeyen dış alan adına çağrı açıklanmalıdır.
Arka kapı belirtileri
Sabit yönetici hesabı, gizli URL, lisans bahanesiyle uzaktan komut, habersiz veri gönderimi, kontrolsüz eval/exec ve uzak kaynaktan kod indirme yüksek risklidir. Her kullanım kötü niyetli olmayabilir; fakat iş gerekçesi ve sınırı kanıtlanmalıdır.
Demo nasıl test edilmeli?
Satıcının demosuna bakmak yerine mümkünse temiz ve kontrol edilen bir test ortamına kurulum yapın. Kurulum dokümanını başka bir geliştirici takip etsin. Gerekli PHP sürümü, eklentiler, web sunucusu, veri tabanı ve dosya izinleri kaydedilsin.
Ana rollerle giriş, parola sıfırlama, kayıt, arama, ödeme sandbox, e-posta, dosya yükleme, queue ve cron akışlarını test edin. Hata durumlarını da deneyin: dış servis kapalı, ödeme başarısız, dosya bozuk ve çift gönderim gibi.
Performans ve ölçek iddiaları
“Binlerce kullanıcı kaldırır” ifadesi test koşulu olmadan anlamsızdır. Donanım, veri büyüklüğü, eş zamanlı kullanıcı, istek türü, cache ve ölçülen percentile değerleri belirtilmelidir. Küçük boş veri tabanındaki hızlı demo üretim yükünü temsil etmez.
Yavaş sorgu, N+1, eksik indeks, sınırsız liste ve büyük dosya işleme kontrol edilmelidir. Ölçek ihtiyacı gerçek değilse karmaşık dağıtık mimari için fazladan ödeme yapmayın.
Veri tabanı ve migration teslimi
Şema yalnız SQL dump olarak verilmemeli; sürümlü migration ve başlangıç verisi ayrılmalıdır. Mevcut sistemden veri taşınacaksa alan eşleme, karakter seti, saat dilimi, dosyalar, kullanıcı parolası ve hata raporu planlanmalıdır.
Migration önce anonimleştirilmiş kopyada denenmeli. Satır sayısı, toplamlar ve kritik ilişkiler kabul kriteri olarak karşılaştırılmalıdır. Geri dönüş ve yedek doğrulaması olmadan canlı veri üzerinde tek yönlü işlem yapılmamalıdır.
Sırlar ve kişisel veri temizliği
Teslim paketinde gerçek .env, veritabanı yedeği, müşteri bilgisi, API anahtarı, SMTP parolası veya ödeme tokenı bulunmamalıdır. Satıcı tüm sırları iptal edip alıcının yeni değerlerle kurulum yapmasını sağlamalıdır.
Örnek veri yapay olmalı. Log, upload ve cache dizinleri kontrol edilmelidir. Ürünün topladığı kişisel veriler, saklama süresi, silme işlevi ve erişim rolleri belgelenmelidir.
Güncelleme mekanizması güvenli mi?
Script kendi kendine güncelleniyorsa paket kaynağı, bütünlük doğrulaması, HTTPS, imza, sürüm notu ve rollback incelenmelidir. Satıcının alan adı kapanırsa uygulamanın çalışıp çalışmayacağı bilinmelidir.
Otomatik güncelleme üretimde doğrudan çalışmamalı; önce test ortamında kurulup migration ve uyumluluk kontrolünden geçmelidir. Güncelleme desteğinin süresi ve ücretli olup olmadığı sözleşmeye yazılmalıdır.
Destek ve bakım sözleşmesi
Destek; kanal, saat, yanıt hedefi, kapsanan hata, sürüm aralığı ve hariç işleri tanımlamalıdır. Yeni özellik ile garanti hatası ayrılmalıdır. Tek geliştiriciye bağlı projede kaynak dokümantasyonu ve devir oturumu daha kritiktir.
PHP, framework ve bağımlılıkların destek sonu takip edilmelidir. Güvenlik düzeltmesinin kaç gün içinde yayımlanacağı ve müşteriye nasıl bildirileceği belirlenmelidir.
Ödeme ve kabul aşamaları
Ödemeyi yalnız ekran görüntüsü veya sözlü vaatle tamamlamayın. Aşamalar; demo, kod inceleme, test kurulumu, kritik hata düzeltme, canlı geçiş ve son kabul olarak bölünebilir. Güvenilir ödeme veya escrow mekanizması taraf riskini azaltabilir.
Kabul kriterleri ölçülebilir olmalıdır: belirtilen modüller çalışıyor, audit sonucu teslim edildi, kritik güvenlik açığı yok, doküman tamam ve alıcının ortamında kurulum başarıyla tekrarlandı gibi.
Devir günü kontrolü
Repository, domain, lisans paneli, paket hesabı, e-posta sağlayıcısı, ödeme entegrasyonu ve üçüncü taraf servislerin sahipliği tek tek aktarılmalıdır. Satıcının erişimleri son kabulden sonra kaldırılır; anahtarlar yenilenir.
Yeni yönetici hesapları ve iki faktörlü doğrulama alıcının kontrolünde kurulmalıdır. Yedek alınır, geri yükleme test edilir ve ilk üretim izleme penceresi planlanır. Devir, ZIP indirmek değil operasyonun kontrolünü kanıtla almaktır.
Satıcı için şeffaf ilan şablonu
- Scriptin amacı, hedef kullanıcısı ve sürümü
- PHP/framework/veritabanı gereksinimleri
- Dahil modüller ve hariç özellikler
- Lisans türü, kurulum sayısı ve yeniden satış hakkı
- Kaynak kod, repository, test ve doküman kapsamı
- Üçüncü taraf paket, servis ve devam maliyetleri
- Bilinen hatalar, güvenlik güncellemesi ve destek süresi
- Demo erişimi, teslim adımları ve kabul koşulları
Sık sorulan sorular
IonCube ile şifreli script alınır mı?
Alınabilir ancak kaynak incelemesi, değiştirme, PHP sürüm yükseltmesi ve satıcıya bağımlılık sınırlanır. Hangi dosyaların kapalı olduğu, loader gereksinimi, lisans sunucusu ve satıcı ortadan kalkarsa çalışma durumu açıkça değerlendirilmelidir.
Temiz virüs taraması yeterli mi?
Hayır. Antivirüs bilinen kalıbı bulabilir; iş mantığı açığını, gizli admin yetkisini veya güvensiz veri akışını kaçırabilir. Bağımlılık denetimi, statik analiz, manuel inceleme ve çalışma testi birlikte gerekir.
Nulled script neden risklidir?
Lisans ihlali yanında kodun değiştirilmiş, arka kapılı veya güncellemesiz olma ihtimali yüksektir. Kaynağı ve bütünlüğü doğrulanamayan script üretim verisine erişmemelidir.
Alıcı kabul kontrol listesi
- Satıcının kodu satma ve lisanslama hakkı doğrulandı mı?
- Lisans; kullanım, değişiklik, kurulum ve devir haklarını açıklıyor mu?
- Kaynak, Git geçmişi, kilit dosyası, migration, test ve doküman tam mı?
- Composer audit, otomatik tarama ve manuel kritik kod incelemesi yapıldı mı?
- Sırlar ve gerçek kişisel veriler teslim paketinden temizlendi mi?
- Test kurulumu, veri geçişi, performans ve rollback kabul edildi mi?
- Destek, güncelleme, ödeme aşaması ve devir kayıtları yazılı mı?
PHP script alım satımında en ucuz teklif, toplam maliyeti en düşük teklif olmayabilir. Lisans belirsizliği, güvensiz bağımlılık ve eksik teslim daha sonra yeniden geliştirme kadar pahalı olabilir. İyi alışveriş; hakları, kod bileşimini, güvenlik durumunu ve operasyon devrini bağımsız biçimde doğrulayabildiğiniz alışveriştir.