Yazılım ve web projesi fiyatları neye göre değişir?

Yazılımda “web sitesi” tek bir ürün değildir: hazır bir tema kurulumu ile sıfırdan yazılan bir uygulama arasında hem emek hem sorumluluk bakımından büyük fark vardır. Fiyatı okumanın yolu, kapsamı okumaktan geçer.

Fiyatı belirleyen kalemler

  • Kapsam: kaç ekran, kaç kullanıcı rolü, hangi işlevler?
  • Hazır altyapı mı, sıfırdan geliştirme mi: ikisi farklı bir emek ve farklı bir esneklik anlamına gelir.
  • Tasarım: hazır tema mı kullanılacak, özel arayüz tasarımı mı yapılacak?
  • Entegrasyon: ödeme, kargo, muhasebe ve üçüncü parti servisler ayrı kalemlerdir.
  • İçerik: metin, görsel ve ürün girişinin kime ait olduğu çoğu projede belirsiz bırakılır ve sonra tartışma çıkarır.
  • Test ve düzeltme: teslim sonrası hata düzeltme süresinin uzunluğu.
  • Bakım: teslimden sonraki güncelleme, yedekleme ve destek ayrı bir hizmettir.

Sabit fiyat mı, saatlik çalışma mı?

Sabit fiyat, kapsamın baştan net olduğu işlerde bütçeni sabitler; karşılığında kapsamı yazıya dökmeyi gerektirir ve kapsam dışı her istek ek bir anlaşma olur. Saatlik çalışma, kapsamın yol boyunca netleştiği işlerde adildir; karşılığında ilerlemeyi düzenli görmeni ve bir üst sınır belirlemeni gerektirir. Yanlış olan, hangisinin konuşulduğunu bilmeden başlamaktır.

Revizyon: en sık atlanan madde

Revizyon sayısı yazılı değilse, “bir de şunu değiştirelim” cümlesinin sonu yoktur ve bu, iki taraf için de kötü biter. İyi bir anlaşma revizyonun kaç turda ve hangi aşamada yapılacağını, tur dışındaki isteklerin nasıl fiyatlanacağını söyler.

Kaynak kod, hesaplar ve lisanslar kimin?

Bir projenin teslim edilmesi ile haklarının devredilmesi aynı şey değildir. Fikir ve Sanat Eserleri Kanunu, mali hakların devrine ilişkin sözleşmelerin yazılı olmasını ve devredilen hakların her birinin ayrıca gösterilmesini arar; yani “kod bende kalsın” demek yetmez, devir yazılı olarak ve hangi hakların devredildiği tek tek gösterilerek düzenlenmelidir. Aynı netlik alan adı, sunucu, e-posta ve mağaza hesapları için de geçerlidir: hesaplar kimin adına açılacak?

Teslimden sonra ne oluyor?

  • Teslim sonrası hata düzeltme süresi ne kadar ve neyi kapsıyor?
  • Güncelleme, yedekleme ve güvenlik yamaları kimin sorumluluğunda?
  • Sunucu, alan adı ve lisans bedelleri kimin bütçesinden çıkacak?
  • Devir hâlinde teknik dokümantasyon ve erişim bilgileri nasıl teslim edilecek?
  • Acil bir arıza için ulaşılabilirlik nasıl tanımlandı?

Aynı istek, üç farklı proje

Yazılımda “bir web sitesi istiyorum” cümlesi tek bir işi anlatmaz. Aynı cümleden üç farklı proje çıkabilir ve üçünün emeği birbirine benzemez.

  • Hazır altyapı kurulumu: mevcut bir tema ve eklentilerle kurulan, içeriği senin girdiğin bir site.
  • Özelleştirilmiş kurulum: hazır altyapı üzerine kendi tasarımın ve birkaç özel işlev; entegrasyonlar burada başlar.
  • Sıfırdan geliştirme: kendi veri modelin, kendi arayüzün ve kendi kurallarının olduğu bir uygulama.

Üçü de meşru bir çözümdür ve seçim ihtiyaca bağlıdır: değişmeyecek bir tanıtım sayfası ile her gün kullanılacak bir iş uygulaması aynı yatırımı hak etmez. Rakam isterken hangisini düşündüğünü değil ne yapmak istediğini anlat — doğru seçeneği anlatan bir teklif, yanlış seçeneğe verilmiş ucuz bir rakamdan daha değerlidir.

Kapsamın nasıl yazıldığı, fiyatın kendisidir

Yazılımda anlaşmazlıkların neredeyse tamamı kapsamdan çıkar ve kapsam, cümlelerin ne kadar somut olduğuna bağlıdır. “Kullanıcı yönetimi olsun” bir kapsam değildir; “kayıt, giriş, şifre sıfırlama ve iki rol” bir kapsamdır.

Rakam almadan önce yapılacakları ekran ve işlev listesine dönüştür; hangi ekranın hangi rolü ilgilendirdiğini yaz. Bu liste hem gelen rakamları karşılaştırılabilir yapar hem proje ortasında çıkan “bu dâhil miydi?” sorusunu ortadan kaldırır. Liste uzunsa proje büyüktür; bunu baştan görmek, yarıda görmekten iyidir.

Bütçeyi kontrol altında tutmanın yolları

Yazılımda maliyeti kontrol etmenin yolu kapsamı kısmak değil, kapsamı sıraya koymaktır.

  • Önce çalışan bir ilk sürüm: gerçekten kullanılacak en küçük hâli yayına al, gerisini kullandıkça ekle.
  • İçeriği sen hazırla: metin, görsel ve ürün girişini üstlenmek, projenin en çok tahmin edilemeyen kalemini senin tarafına alır.
  • Hazır olanı kullan: standart bir ihtiyacı sıfırdan yazdırmak hem süre hem bakım yükü demektir.
  • Entegrasyonu erken netleştir: ödeme, kargo ve muhasebe bağlantıları sonradan eklendiğinde çoğu zaman yeniden yazım gerektirir.
  • Revizyon turlarını sabitle: kaç tur ve hangi aşamada olduğu yazılıysa kapsam kendiliğinden büyümez.
  • Tekrarlayan giderleri baştan hesapla: alan adı, barındırma, sertifika ve üçüncü taraf servis ücretleri projenin bitiminde başlar.

Kim çalışıyor: tek kişi mi, bir ekip mi?

Yazılımda fiyat farkının az konuşulan bir sebebi, işi kimin yapacağıdır. Tek kişi genellikle daha doğrudan iletişim ve daha az genel gider demektir; bir ekip ise süreklilik ve birden fazla uzmanlık demektir. İkisi de doğru seçim olabilir, ama sordukların değişir.

  • İşi fiilen kim yazacak; teklifi veren kişi mi, başka biri mi?
  • O kişi altı ay sonra ulaşılabilir olmazsa proje nasıl devam eder?
  • Kod bir yerde saklanıyor mu ve o depoya senin de erişimin olacak mı?
  • Yazılan kodun okunabilirliği ve teknik notlar teslim kapsamında mı?
  • Birden fazla kişi çalışacaksa aralarındaki iş bölümü ve tek muhatap kim?
  • Tatil, hastalık ve yoğunluk dönemlerinde takvim nasıl korunuyor?

Bu soruların amacı kimseyi elemek değil, riski görünür kılmaktır. Tek kişiyle çalışmanın riski süreklilik, ekiple çalışmanın riski ise iletişimin seyrelmesidir; ikisi de yönetilebilir, ama ancak baştan konuşulduğunda.

Neden bu sayfada bir rakam yok?

Aynı adı taşıyan iki projenin kapsamı arasında çok büyük fark olabilir; “web sitesi” için yayımlanacak bir aralık, kapsamı dar olan işi pahalı, geniş olanı imkânsız gösterir. Kaynağı belli bir tarife de yok. Bu yüzden rakam yerine, kapsamı yazıya dökmeni sağlayacak soruları veriyoruz — bir yazılım projesinde pazarlığı belirleyen zaten kapsamdır.

Talebini yazarken neleri belirtmelisin?

Yazılımda kapsamı yazmak, fiyatı yazmanın yarısıdır. Aşağıdakileri belirttiğinde gelen teklifler aynı işi tarif eder ve aradaki fark gerçekten yaklaşımdan gelir.

  • Ne yapmak istediğin: yeni bir sistem, mevcut birinin geliştirilmesi ya da bir arıza.
  • Kimlerin kullanacağı ve orada hangi işi yapacağı.
  • Hazır bir altyapı kullanılmasına açık olup olmadığın.
  • Gereken bağlantılar: ödeme, kargo, muhasebe, pazaryeri.
  • Metin ve görsel içeriği kimin sağlayacağı.
  • Hedeflediğin teslim tarihi.
  • Mevcut alan adı, sunucu ve hesapların kimin adına olduğu.

Teslim kontrol listesi

Yazılımda “teslim edildi” cümlesi tek başına bir durum bildirmez. Aşağıdakiler teslimin gerçekten tamamlandığını gösteren maddelerdir ve hepsi teslim gününde birkaç dakikada kontrol edilebilir.

  • Kaynak kodun ve tasarım dosyalarının senin erişebildiğin bir yerde olması.
  • Alan adı, barındırma, e-posta ve mağaza hesaplarının senin adına açılmış olması.
  • Yedeklemenin kurulu ve çalışır olduğunun gösterilmesi.
  • Test ortamı varsa nasıl kullanılacağının anlatılması.
  • Yönetim panelinin kısa bir devir görüşmesiyle gösterilmesi.
  • Bilinen ve kapsam dışı bırakılan eksiklerin yazılı bir listesi.
  • Kullanılan üçüncü taraf servislerin ve lisanslarının listesi.
  • Hata düzeltme süresinin ne zaman başladığı ve ne zaman biteceği.

Bu listenin en kritik maddesi hesaplardır: kod devredilmiş olsa bile alan adı ya da barındırma başkasının adınaysa, ürünün üzerinde fiilen söz sahibi olamazsın. Devir görüşmesini de küçümseme — yarım saatlik bir anlatım, aylarca sürebilecek destek yazışmasının yerine geçer ve teslimin gerçekten tamamlandığını iki taraf için de görünür kılar.

Sık sorulan sorular

Hazır tema mı, özel geliştirme mi?

Hazır altyapı hızlıdır ve başlangıç maliyetini düşürür; özel geliştirme ise ihtiyacın kalıba sığmadığı yerde gerekir. Karar, işin ne kadar standart olduğuna bağlıdır; ikisi birbirinin ucuz ya da pahalı sürümü değildir.

Kaynak kod bana ait olur mu?

Kendiliğinden olmaz. Mali hakların devri yazılı olarak ve devredilen haklar tek tek gösterilerek düzenlenmelidir; sözleşmede bu yoksa teslim almış olman hak sahibi olduğun anlamına gelmez.

Bakım ücreti ayrı mı?

Genellikle ayrıdır ve olması da doğaldır: teslim bir kerelik, bakım süreklidir. Önemli olan, teslim sonrası hata düzeltme süresi ile bakımın nerede ayrıldığının yazılı olmasıdır.

Proje süresi neye göre belirleniyor?

Kapsam ve karar hızının birlikte belirlediği bir süredir. Geliştirme süresi tahmin edilebilir; asıl belirsizlik geri bildirimin ne kadar sürede geldiğidir. Kendi tarafındaki onay sürelerinin de yazılması, gecikmenin kimden kaynaklandığını tartışma konusu olmaktan çıkarır.

Barındırma ve alan adı kimin adına açılmalı?

Senin adına. Hesaplar seni gösteriyorsa, çalıştığın kişi değişse bile erişim sende kalır. Bu teknik bir tercih değil sahiplik meselesidir ve projenin ilk gününde halledilmesi en kolay olan konudur.

Teslimden sonra çıkan hatalar ücretli mi?

Anlaşmada yazan hata düzeltme süresi içinde ve kapsam dâhilindeki hatalar ücretsiz olmalıdır; kapsam dışı yeni bir istek ise yeni bir iştir. Aradaki sınırı belirleyen şey, kapsamın baştan ne kadar somut yazıldığıdır — bu yüzden ekran ve işlev listesi sonradan da işine yarar.

İlgili hizmetler

Bu rehberdeki konularla ilgili hizmetler için ücretsiz teklif toplayabilirsin.