Yazılım teklifi nasıl karşılaştırılır? Kapsam ve maliyet

Yazılım teklifi nasıl karşılaştırılır sorusuna yanıt ararken en büyük zorluk, tekliflerin aynı dili konuşmaması. Birinde kapsam geniş, diğerinde vade kısa; birisi bakımı dahil ediyor, diğeri üçüncü parti ücretlerini size bırakıyor. Bu rehberde, KOBİ'ler ve proje ekipleri için teklifleri objektif biçimde kıyaslayabileceğiniz, ölçülebilir bir çerçeve paylaşıyoruz. Biz Uriworks’te değerlendirmeyi kapsam, teknik mimari, entegrasyonlar, güvenlik, bakım-destek ve gizli maliyet başlıklarıyla netleştiriyoruz.

Yazılım teklifi nasıl karşılaştırılır? Önce iş hedefini ve kapsamı eşitleyin

Fiyat tek başına karar kriteri olamaz; önce iş hedefi ve kapsam eşitlenmeli. Aksi halde iki farklı işi iki farklı rakamla tartmış olursunuz. Başlangıçta şu çerçeveyi çıkarıyoruz:

• Zorunlu özellikler ve sonraya bırakılabilecek istekler (çekirdek ve isteğe bağlı kapsam ayrımı).
• Süreciniz kaç yerde özelleşiyor? Kim hangi adımda hangi onayı veriyor? (rol ve akış netliği).
• Entegrasyonlar: bağlanacak ERP/CRM, e-fatura, kargo, ödeme, pazaryeri, SMS/e-posta servisleri. Burada API Geliştirme ve Sistem Entegrasyonu deneyimimizle riskleri baştan listeliyoruz.
• Platform: Tarayıcı tabanlı iş yazılımı mı (Web Uygulama Geliştirme), iOS/Android mi (Mobil Uygulama Geliştirme) yoksa her ikisi mi?
• Veri göçü, mevcut içerik ve raporlama gereksinimleri.
• Başarı ölçütleri: Canlıya çıkışta “tamamlandı” dememiz için hangi akışların problemsiz işlemesi gerekiyor?

Bu çerçeve, teklifleri aynı terimlerle okumayı sağlar. Kapsamı yazılı hale getirdiğimizde, teklif dokümanlarında eksik/yanlış varsayımları çok daha hızlı yakalıyoruz.

Teklif dokümanı inceleme: Satır satır kontrol listesi

Teklif değerlendirme kriterleri netleştiğinde, dokümanı parçalarına ayırıp okuyoruz. İşte pratik bir kontrol listesi:

• Kapsam içi / kapsam dışı: Hangi özellikler dahil? Neler açıkça hariç? Değişiklik talebi süreci nasıl işleyecek?
• İş akışları ve kullanıcı rolleri: Yetkilendirme, onay adımları, loglama ve audit trail tanımlı mı?
• Teknik mimari: Tercih edilen dil/çatı, katmanlı yapı, modülerlik, bağımlılık yönetimi ve sürüm stratejisi belirtilmiş mi?
• Entegrasyon yöntemi: Resmî API mi, webhook mu, dosya aktarımı mı? Hata durumları ve tekrar deneme stratejisi var mı? Burada entegrasyon tecrübemizle belirsizlikleri noktalıyoruz.
• UI/UX yaklaşımı: Akış haritaları, wireframe veya tıklanabilir prototip üretilecek mi? Kodlamadan önce karar görecek misiniz? UI/UX Tasarım ve Prototipleme sürecini dahil eden tekliflerin sürprizi daha az olur.
• Testler: Birim/entegrasyon/e2e testleri hangi kritik akışları kapsıyor? Kabul testlerinin kriteri yazılmış mı?
• CI/CD ve ortamlar: Geliştirme, test, canlı ortam ayrımı; otomatik dağıtım, rollback stratejisi, günlükleme ve izleme araçları.
• Dokümantasyon ve eğitim: Kurulum, kullanım kılavuzu, admin rehberi ve kısa eğitim oturumları dahil mi?
• Kaynak kod ve erişim: Depo (repo) sahipliği, kod lisansı, gerekli olduğunda ekibinizin katkı yapma modeli.
• Veri sahipliği ve taşınabilirlik: Yedekleme, ihracat (export) ve başka sisteme geçiş senaryosu.
• Bakım-destek: Kapsamı, kanalları, yanıt/çözüm süreçleri; güvenlik güncellemeleri ve bağımlılık güncellemeleri nasıl ele alınıyor?

Bu maddeler, teklif dokümanı inceleme sürecinde “okudum, anladım” demekten fazlasını yapmanızı sağlar; gri alanları ortaya çıkarır.

Gizli maliyetleri tespit etme: En çok nerede saklanırlar?

Fiyat satırında görünmeyen ama bütçeyi büyüten kalemler genellikle şuralarda çıkar:

• Bulut barındırma ve veritabanı ücretleri, yedekleme, izleme ve log saklama maliyetleri.
• Mesajlaşma servisleri: SMS, e-posta gönderimi, bildirim servisleri.
• Ödeme ve e-ticaret giderleri: Ödeme sağlayıcı masrafları, sanal POS, pazaryeri entegrasyonlarının kullanıma bağlı ücretleri. E-Ticaret Yazılımı ve Altyapısı projelerinde bu kalemleri baştan tabloya koyuyoruz.
• Mağaza ve geliştirici hesapları: Apple/Google yayın hesapları, mağaza gereklilikleri (mobil uygulama projelerinde).
• Harita, konum, dosya işleme API'leri: Haritalar, OCR, çeviri, video işleme, CDN gibi servislerin kullanım bedelleri.
• Güvenlik ve uyum: Tarama araçları, WAF, sertifika yenilemeleri.
• Veri göçü ve içerik girişi: Eski sistemden veri temizliği/dönüşümü; görsel- içerik hazırlığı.
• Değişiklik talepleri: Canlıya yakın noktada ortaya çıkan iş kuralları; teklifin bu değişimleri nasıl fiyatladığı.

Biz tekliflendirirken bu kalemleri ayrı başlıkta açar, varsayım notlarıyla birlikte listeleriz. Böylece “gizli” değil, kontrol edilebilir maliyetler haline gelirler.

Teknik mimari, kod kalitesi ve güvenlik: Ölçülebilir kıstaslar

Teknik kalite soyut bir vaat değil; ölçülebilir sinyalleri var. Biz şu kıstaslara bakarak teklifleri kıyaslamanızı öneriyoruz:

• Mimari: Katmanlı ve modüler yapı, bağımsız servisler, entegrasyon sınırlarının netliği. Kritik akışlar için kanıt amaçlı küçük bir deneme (PoC) öneriyorlar mı?
• Standartlar: Kodlama standartları, stil denetimi, bağımlılık güncellemeleri, sürümleme stratejisi (örneğin semantik sürümleme yaklaşımı).
• Test ve otomasyon: En azından kritik ödeme/sipariş/rol bazlı onay akışlarının otomatik testlerle güvence altına alınması.
• Güvenlik uygulamaları: Ortam ayrımı, gizli anahtar yönetimi, şifreleme (aktarılırken ve saklanırken), girdi doğrulama ve hız sınırlama; OWASP ilkeleriyle uyumlu geliştirme yaklaşımı.
• İzleme ve günlükleme: Uygulama ve entegrasyon seviyesinde ölçümler; hata, performans ve iş metriklerinin toplanması.

Bu maddeler tekliflerde somut şekilde yer alıyorsa, süre veya fiyat cümlelerinden daha güvenilir bir kalite göstergesi elde edersiniz.

Bakım, destek ve garanti: Teslim sonrası tabloyu mutlaka kıyaslayın

Birçok proje, canlıya çıktıktan sonra anlaşılır. Bu yüzden teslim sonrası başlıkları ayrı değerlendirin:

• Garanti: Hata sınıfları ve garanti kapsamı nasıl tanımlı? İş kuralı değişikliği garantiye girer mi?
• Bakım: Güvenlik yamaları, çatı/kitaplık güncellemeleri, küçük iyileştirmelerin işleniş şekli.
• Destek kanalları: Tek temas noktası, önceliklendirme kuralları, durum güncellemeleri.
• İzleme ve olay yönetimi: Uyarı eşikleri, kök neden analizi ve geri bildirim döngüsü.

Bizde bakım-destek, kapsam ve iletişim modeliyle birlikte yazılıdır; müşteri ekibinizin sorumluluklarıyla bizim sorumluluklarımız aynı tabloda görünür.

Fiyat tek başına karar değil: Değer/Kapsam matrisi kurun

Sağlam bir karar, değer odaklı kıyasla verilir. Önerimiz: Öncelikli kriterleri belirleyin, her kritere önem ağırlığı verin ve her teklife aynı ölçekte puan verin. Çarpım toplamı, kimin daha çok değer sunduğunu gösterecektir. Buradaki puanlar sizin verinizdir; tekliflerin metni sadece girdi sağlar. Eğer teklif mobil ve web’i birlikte hedefliyorsa, web uygulaması ve mobil uygulama başlıklarını ayrı ayrı puanlamak daha isabetli olur.

Pratik puanlama şablonu (kendi sayılarınızla doldurun)

Dilerseniz “diyelim ki” senaryosuyla tek bir kriterde iki teklif arasındaki farkı ayrıca not düşebilirsiniz (örneğin entegrasyon sayısı arttıkça kimin yöntemi daha esnek kalıyor gibi).

Uriworks olarak süreci nasıl yönetiyoruz?

Biz teklif vermeden önce kısa bir keşif görüşmesi yapar, riskli alanlar için doğrulama isteriz. Ardından:

• Kapsamı yazarız: Kapsam içi ve kapsam dışı listeleri netleştirir, kabul kriterlerini kalem kalem belirtilmiş halde göndeririz.
• Prototip üretiriz: Kritik ekranlar için UI/UX prototipini sağlayıp akışları somutlarız.
• Mimariyi seçeriz: Gelecekteki modüllere açık, entegrasyonları sade tutan yapıyı tarif ederiz. Entegrasyonlar için mümkünse resmî API tercih ederiz; yoksa kurallara uygun alternatifleri (Bot/Scraper gibi) artı-eksi listesiyle yazarız.
• Kalite güvencesi kurarız: Kod incelemesi, otomatik testler ve CI/CD boru hattı teklife dahildir.
• Güvenliği işleriz: Gizli anahtar yönetimi, loglama, izleme, yedekleme ve geri dönüş planını teklifin ayrı bölümünde paylaşırız.
• Bakım-destek planları sunarız: Garanti kapsamı, destek kanalları ve güncelleme politikası aynı belgede yer alır.

Web iş yazılımları için Web Uygulama Geliştirme, mağaza ve ödeme akışları için E-Ticaret, iOS/Android yayın süreçleri için Mobil Uygulama hizmet sayfalarımızda yöntemi detaylı bulabilirsiniz. Benzer işleri görmek isterseniz projeler sayfasına göz atın.

İhale veya çoklu teklif süreçlerinde ek ipuçları

• Teknik şartnameyi iki bölüm yapın: Zorunlu gereksinimler ve değerlendirme puanlaması. Böylece tüm katılımcılar aynı zeminde teklif verir.
• Sorular için tek bir iletişim kanalı belirleyin; verilen yanıtları tüm katılımcılarla eşit şekilde paylaşın.
• Örnek veri seti ve kabul testlerini şartnameye eklemek, subjektif yorumu azaltır.

Bir sonraki adım

Elinizdeki teklifleri bu çerçeveyle birlikte hızlıca gözden geçirelim; riskleri, gizli maliyetleri ve iyileştirme önerilerini tek sayfalık bir özetle sunalım. Kısa bir görüşme ayarlamak için iletişim ve teklif formu üzerinden bize ulaşabilirsiniz. Uzaktan da çalışıyor, operasyonunuza uygun modeli birlikte seçiyoruz.

Sık sorulan sorular