Yazılım Projesi Maliyeti 2026: Web, Mobil ve SaaS Fiyat Rehberi

Bize gelen ilk soru neredeyse her zaman aynı: “Bu iş ne kadar tutar?” Dürüst cevap şu: kapsamı konuşmadan verilen her rakam ya sizi yanıltır ya da bizi. Yine de bir yere tutunmak gerekiyor. Aşağıda, Türkiye pazarında 2026 itibarıyla gördüğümüz gerçek aralıkları ve o aralıkları belirleyen kalemleri paylaşıyoruz.

Maliyeti belirleyen 6 kalem

Bir teklifin arkasındaki hesap, tahmin edilenden daha basittir. Fiyatı yukarı ya da aşağı çeken şey neredeyse her zaman şu altı başlıktan biridir.

1. Ekran sayısı ve durum çeşitliliği: 10 ekranlık bir uygulama, 5 ekranlığın iki katı değildir. Her ekranın yükleniyor, boş, hata ve başarı durumu vardır; asıl iş burada.
2. Rol sayısı: Tek kullanıcı tipi olan bir ürünle; yönetici, editör ve müşteri panelleri olan bir ürün arasında yetkilendirme açısından ciddi fark vardır.
3. Entegrasyonlar: Ödeme, e-fatura, kargo, CRM, SMS, takvim… Her dış servis kendi hata senaryolarını da getirir.
4. Veri modelinin karmaşıklığı: Basit bir katalogla, çok kiracılı (multi-tenant) bir SaaS'ın veritabanı tasarımı aynı iş değildir.
5. Tasarım seviyesi: Hazır bileşen kütüphanesiyle ilerlemek mi, markaya özel bir tasarım sistemi kurmak mı?
6. Yayın sonrası kapsam: Bakım, izleme ve iyileştirme dahil mi, teslimle bitiyor mu?

2026 için gerçekçi bütçe aralıkları

Aşağıdaki tablo, uçtan uca (tasarım + geliştirme + yayın) yürütülen projeler için gördüğümüz tipik aralıkları gösteriyor. Freelance tek kişilik çalışmalar alt sınırın altına, büyük ajanslar üst sınırın üstüne çıkabilir.

Sabit fiyat mı, aşama bazlı mı?

İki model de çalışır; hangisinin doğru olduğu belirsizlik seviyesine bağlıdır.

Sabit fiyat

Kapsam net olduğunda en rahat modeldir. Ne alacağınızı ve ne ödeyeceğinizi baştan bilirsiniz. Karşılığında kapsam disiplini gerekir: sonradan eklenen her şey ayrı bir kalem olur. Kurumsal siteler, landing sayfaları ve iyi tanımlanmış modüller için tercih ederiz.

Aşama bazlı (faz faz)

Ürün henüz aranırken, yani “kullanıcı ne isteyecek” sorusunun cevabı netleşmemişken daha sağlıklıdır. Her faz sonunda çalışan bir parça teslim edilir, bir sonraki faz o veriye bakılarak planlanır. Bütçe kontrolü, tek seferde büyük taahhüt vermek yerine adım adım ilerlemekle sağlanır.

Maliyeti gerçekten düşüren 5 karar

• Kapsamı v1 için acımasızca kısın. Kullanıcının ilk gün ihtiyaç duymadığı her özellik, v2'ye ertelenebilir bir maliyettir.
• Hazır altyapıları kullanın. Kimlik doğrulama, ödeme, e-posta ve dosya depolama için sıfırdan sistem yazmak neredeyse hiçbir zaman doğru karar değildir.
• İçeriği zamanında hazırlayın. Projelerin gecikmesinin en yaygın sebebi kod değil, bekleyen metin ve görsellerdir. Gecikme = maliyet.
• Tek karar verici belirleyin. Beş kişinin onayını bekleyen her ekran, iki kat tur atar.
• Tasarım sistemini erken kurun. İlk üç ekranda kurulan buton/kart/form standardı, sonraki otuz ekranı hızlandırır.

Ucuz teklifin gizli maliyeti

Piyasada aynı işe onda bir fiyat veren teklifler görürsünüz. Bazen gerçekten verimli bir ekiptir; çoğu zaman ise fark şu kalemlerden çıkarılmıştır: test yok, hata durumları yok, mobil uyum yüzeysel, erişilebilirlik yok, güvenlik gözden geçirmesi yok, teslimden sonra iletişim yok.

Yazılımda ucuzun maliyeti genelde ikinci ekibe ödediğiniz tutardır.

Teklifleri karşılaştırırken fiyatın yanına şunları da sorun: Kaynak kod kime ait? Hangi ortamlarda test ediliyor? Yayın sonrası ilk 30 gün neyi kapsıyor? Devretme (handover) dokümanı var mı?

Teklifte mutlaka olması gereken 8 madde

İyi bir teklif fiyat listesi değil, bir sözleşme taslağıdır. Aşağıdakiler yoksa teklif eksiktir — ve eksik teklif, sonradan tartışma demektir.

1. Kapsam listesi: ekran ekran, modül modül ne yapılacağı. “Yönetim paneli” tek satır değil, alt maddeleriyle.
2. Kapsam dışı listesi: neyin dahil olmadığı. Bu liste, dahil olanlar kadar önemlidir.
3. Teslim takvimi ve aşamalar: hangi hafta ne teslim edilecek.
4. Ödeme planı: aşamalara bağlı, tek seferde peşin değil.
5. Revizyon hakkı: kaç tur tasarım revizyonu dahil.
6. Kaynak kod ve fikri mülkiyet: teslimde kodun ve tasarım dosyalarının kime geçtiği.
7. Yayın sonrası destek: kaç gün/ay, neleri kapsıyor, hata ile yeni istek ayrımı nasıl yapılıyor.
8. Üçüncü parti maliyetler: hangi servislerin abonelik ücreti size ait.

Unutulan kalem: aylık işletme maliyeti

Proje bütçesi konuşulurken çoğunlukla tek seferlik geliştirme bedeli konuşulur. Oysa ürün yayına girdiği gün işletme giderleri başlar. Aşağıdaki kalemlerin tamamı dolarla faturalanıyor — bu yüzden tabloyu USD üzerinden veriyoruz; TL karşılığı güncel kura göre değişir.

Kurumsal bir site ayda neredeyse sıfır maliyetle dönerken, kullanıcı tabanı büyüyen bir SaaS'ta bu kalem hızla üç haneli dolara çıkar. Fiyatlandırma modelinizi kurarken işletme maliyetinin kullanıcı başına ne olduğunu bilmek şart — aksi halde büyüdükçe kâr eriyebilir.

Bakım için yıllık ne ayırmalı?

Sektörde yaygın kabul, ilk geliştirme bedelinin yıllık %15–20'si kadar bir bakım bütçesidir. Bu tutar; kütüphane güncellemeleri, güvenlik yamaları, işletim sistemi uyumu, küçük iyileştirmeler ve hata düzeltmelerini kapsar.

Bu kalemi bütçeye koymamak kısa vadede tasarruf gibi görünür. Pratikte iki yıl bakımsız kalan bir projeyi güncel hale getirmenin maliyeti, düzenli bakımın toplamını çoğu zaman aşar — çünkü artık tek tek güncelleme değil, toplu bir modernizasyon işi olur.

Nasıl ilerlemeli?

Bütçenizi netleştirmenin en hızlı yolu, elinizdekiyle bir keşif görüşmesi yapmak. Bir sayfalık fikir notu bile yeterli. Kapsamı birlikte yazıya döküp size aralık değil, rakam verebiliriz. İletişime geçin — 48 saat içinde dönüyoruz.