Yazılım yaptırma maliyeti: teklifler nasıl karşılaştırılır?

Yazılım yaptırma maliyetini kapsamın ne kadar net yazıldığı, kullanıcı rolü ve ekran sayısı, entegrasyonlar, veri taşıma, hedeflenen platformlar ve yayın sonrası destek belirler. Teklifleri karşılaştırmanın doğru yolu toplam rakama bakmak değil, her teklifin aynı kapsamı, aynı varsayımları, aynı değişiklik kuralını ve aynı sahiplik koşullarını içerip içermediğini kontrol etmektir.

Bu yazı, elinde iki üç yazılım teklifi olan ya da teklif istemeye hazırlanan kurucular, operasyon yöneticileri ve ürün sorumluları için hazırlandı. Fiyat aralığı vermiyoruz: kapsamı bilinmeyen bir proje için verilen genel bir rakam karar vermenize yardım etmez, sizi yalnızca yanlış bir beklentiye bağlar. Onun yerine rakamı neyin büyüttüğünü, bunu kendi projenizde nasıl test edeceğinizi ve üç teklifi aynı ölçüyle nasıl okuyacağınızı adım adım anlatıyoruz. Yasal kısımlar Ekim 2026 itibarıyla yürürlükteki kanun metinlerine dayanıyor ve hukuki görüş yerine geçmiyor. Henüz özel yazılım mı yoksa hazır bir ürün mü gerektiğine karar vermediyseniz, önce özel yazılım mı hazır yazılım mı rehberimize bakmanızı öneririz.

Yazılım yaptırma maliyeti neye göre belirlenir?

Maliyet, bir ekibin işi bitirmek için harcayacağı emek ile üstlendiği belirsizliğin toplamıdır. Emek kapsamın büyüklüğünden, belirsizlik ise kapsamın ne kadar net olduğundan gelir. İki teklif arasındaki farkın büyük kısmı çoğu zaman ikinci kalemden çıkar: kapsamı belirsiz bir işte ajans ya riski fiyata ekler ya da riski sözleşmenin dışına iterek size bırakır. Aşağıdaki etkenler rakamı en çok oynatanlardır; her birinin yanına bunu kendi projenizde nasıl test edebileceğinizi yazdık.

• Kapsamın netliği: Yazılı bir kapsam belirsizlik payını küçültür ve fiyatı aşağı çeker; "konuşarak netleştiririz" denen her madde ya fiyata risk payı olarak eklenir ya da sonradan ek iş olarak döner. Test: ilk sürümde olması gerekenleri, her biri tek cümlelik maddeler halinde bir sayfaya yazabiliyor musunuz?
• Kullanıcı rolleri ve ekranlar: Müşteri, operasyon personeli ve yönetici gibi her yeni rol ayrı yetkiler, ayrı ekranlar ve ayrı testler demektir. İş yükü rol sayısından daha hızlı büyür, çünkü rollerin birbirini etkilediği durumlar da test edilmelidir. Test: her rolün sistemde yapabileceği ve yapamayacağı işleri listeleyin.
• Entegrasyonlar: ERP, muhasebe, e-fatura, ödeme, kargo ya da CRM bağlantıları çoğu projede en belirsiz kalemdir. Karşı sistemin API'si (yazılımların birbiriyle konuşmasını sağlayan arayüz) eksik, belgesiz ya da test ortamından yoksunsa süre ve maliyet yukarı gider. Test: bağlanacak her sistem için belgelenmiş bir API ve test ortamı olup olmadığını öğrenin.
• Veri taşıma: Eski bir sistemden ya da Excel dosyalarından veri aktarmak, verinin temizliğine göre birkaç günlük ya da haftalarca süren bir iş olabilir. Test: aktarılacak verinin gerçek bir örneğini teklif aşamasında paylaşın.
• Platform sayısı: Yalnızca web, web artı mobil ya da iOS ve Android için ayrı uygulamalar; her ek platform tasarımı, testi ve yayın sürecini çoğaltır. Test: ilk sürümün gerçekten bir mobil uygulama gerektirip gerektirmediğini, mobil uyumlu bir web uygulamasının yetip yetmeyeceğini sorun.
• Tasarım düzeyi: Hazır bir bileşen kütüphanesiyle kurulan bir yönetim paneli ile markaya özel tasarlanmış bir müşteri arayüzü arasında ciddi bir emek farkı vardır. Test: tasarımı kimin yapacağını ve kaç tur revizyonun fiyata dahil olduğunu sorun.
• Güvenlik, KVKK ve kayıt tutma: KVKK md. 12 (yeni sekmede açılır), veri sorumlusuna uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri almayı yükler; sağlık verisi ise md. 6'ya göre özel nitelikli kişisel veridir. Bu yüzden yetkilendirme, erişim kayıtları ve saklama kuralları kapsama girmelidir; bu da maliyeti yukarı çeker. Test: hangi verinin kişisel veri olduğunu ve nerede saklanacağını baştan yazın.
• Takvim baskısı: Yakın ve kesin bir tarih, ya ekibi büyütmeyi ya da kapsamı daraltmayı gerektirir; ekip büyüdükçe koordinasyon maliyeti de artar. Test: tarih gerçekten sabit mi, yoksa ilk sürüm daha dar bir kapsamla o tarihe yetişebilir mi?

Bu etkenlerin hepsi teklif verilmeden önce yazıya dökülebilir. Teklif aşamasında bu sorulara cevap veremiyorsanız eksik olan kapsamdır; o durumda doğru ilk adım, geliştirme teklifinden önce kısa bir keşif ve kapsam çalışmasıdır. Mobil tarafta mağaza hesapları ve inceleme süreçleri gibi ek kalemler de vardır; bunları aşağıda, sabit fiyatın dışında kalan kalemler arasında ele alıyoruz.

Bir yazılım projesinin süresini ne uzatır?

Süre, bütçeden daha zor tahmin edilir, çünkü bir kısmı ajansın elinde değildir. Geliştirme ekibinin hızı ölçülebilir; ama sizin tarafınızdaki karar süreleri, içeriğin hazır olması, üçüncü taraf onayları ve kabul testi için ayrılan zaman genellikle tahminin en zayıf halkasıdır. Bu yüzden iyi bir teklif yalnızca bir teslim tarihi değil, o tarihin hangi varsayımlara dayandığını da yazar. "Geri bildirimler iki iş günü içinde verilir" ya da "ödeme altyapısının test hesabı ikinci haftada hazır olur" gibi varsayımlar, tarihin neden kaydığını sonradan tartışmak yerine riski baştan görünür kılar.

• Karar ve geri bildirim süresi: Bir tasarım onayı ya da kapsam sorusu bir hafta bekliyorsa proje de bir hafta bekler. Tek bir karar vericinin belirlenmesi, süreyi kısaltmanın en ucuz yoludur.
• İçerik ve veri hazırlığı: Metinler, ürün listeleri, fiyat tabloları ya da çeviriler hazır değilse ekip boş şablonlarla ilerler ve son haftalar sıkışır.
• Üçüncü taraf süreçleri: Ödeme kuruluşu başvuruları, e-fatura entegratörü hesapları ve uygulama mağazası incelemeleri ajansın kontrolünde olmayan sürelerdir.
• Kabul testi: Yayından önce ekibinizin sistemi gerçek senaryolarla denemesi zaman alır; bu süre takvimde yoksa ya atlanır ya da yayın tarihi kayar.

Bizim tarafımızda bu belirsizliği kısa döngülerle yönetiyoruz (ayrıntısı aşağıda, "Biz olsak ne yapardık?" bölümünde). Süre kayıyorsa bunu son ayda değil ilk döngülerde görürsünüz ve kapsamdan neyin erteleneceğine birlikte karar verilir. Teklif aşamasında da aynı soruyu sorun: ilk çalışan sürümü ne zaman ve nerede göreceksiniz?

Aynı iş için yazılım fiyat teklifleri neden bu kadar farklı?

Aynı iş için alınan teklifler arasında büyük farklar görmek şaşırtıcı değildir ve bu farkın çoğu ekiplerin farklı ücretlerinden değil, farklı işleri fiyatlamalarından gelir. Bir teklif entegrasyonları, veri taşımayı ve yayın sonrası desteği içerirken diğeri yalnızca ekranları kapsıyor olabilir. Biri belirsiz maddeleri risk payıyla fiyata eklerken, diğeri onları "ek iş" olarak sonraya bırakıyor olabilir. Bu yüzden en düşük rakam çoğu zaman en dar kapsamın rakamıdır. Farkın nereden geldiğini anlamak için teklifleri aşağıdaki altı başlıkta okumak gerekir.

Kapsam boşlukları

Teklifte açıkça yazılmamış her iş kapsam dışıdır. Yönetim paneli, kullanıcı rolleri, bildirim e-postaları, şifre sıfırlama, raporlar ve dışa aktarma gibi "olması zaten belli" sanılan işler, kapsam dokümanında madde olarak yoksa sonradan ek bedelle döner. Bir teklifin kapsamını değerlendirmenin en kolay yolu, kendi ilk sürüm listenizi yanına koyup madde madde eşleştirmektir. Eşleşmeyen her madde ya teklifte eksiktir ya da sizin listenizde gereksizdir; ikisi de karar vermeden önce bilinmesi gereken bir şeydir.

Varsayımlar

Ciddi bir teklif, fiyatın hangi varsayımlara dayandığını yazar: içerik sizden mi gelecek, tasarım hazır mı, entegre olunacak sistemin test ortamı var mı, kaç dil desteklenecek, altyapı kaç kullanıcıya göre kurulacak. Varsayımlarını yazmayan bir teklif de varsayımlarda bulunmuştur, yalnızca bunları söylememiştir; gerçek koşullar farklı çıktığında tartışma da buradan başlar. Örneğin çok dilli bir site yalnızca çeviri dosyası eklemek değildir: sağlık turizmi koordinatörü için geliştirdiğimiz çok dilli sitede her dilin ayrı sayfaları, içerik yönetimi ve arama motoru ayarları da işin parçasıydı. Dil sayısı teklifte bir varsayım olarak yazılmamışsa, iki teklif aynı işi fiyatlamıyor olabilir.

Değişiklik yönetimi

Her yazılım projesinde kapsam bir ölçüde değişir; önemli olan değişikliğin nasıl ele alındığıdır. İyi bir teklif, değişiklik talebinin yazılı yapılacağını, geliştirmeye başlamadan önce ayrıca fiyatlanıp onaylanacağını ve takvime etkisinin belirtileceğini söyler. "Küçük değişiklikler dahildir" gibi ölçüsü olmayan ifadeler iki taraf için de risklidir, çünkü ajans neyin küçük olduğuna sizden farklı karar verebilir. Değişiklik kuralı yazılı değilse, sabit fiyatın neyi sabitlediği de belirsizleşir.

Destek dönemi

Yayın günü projenin bittiği gün değildir. Gerçek kullanıcılarla ilk haftalarda hata çıkması normaldir; bu hataların kim tarafından, ne kadar sürede ve hangi bedelle düzeltileceği teklifte yazmalıdır. Destek dönemiyle bakım sözleşmesini de birbirinden ayırın: destek dönemi teslim edilen işin hatalarını kapsar, bakım ise güvenlik güncellemeleri, kütüphane yükseltmeleri, izleme ve küçük geliştirmeler gibi süregelen işleri kapsar. Bir teklif destek döneminden hiç söz etmiyorsa, ucuz görünmesinin nedenlerinden biri budur.

Kod, hesaplar ve verinin sahipliği

Teklifler arasında en az konuşulan ama en pahalıya patlayabilen fark sahipliktir. Fikir ve Sanat Eserleri Kanunu bilgisayar programlarını eser sayar ve mali haklara dair sözleşmelerin yazılı olmasını, konusu olan hakların da ayrı ayrı gösterilmesini şart koşar (FSEK md. 2 ve md. 52) (yeni sekmede açılır). Yani bedelini ödediğiniz yazılımı kullanma, çoğaltma, değiştirme ve yayma haklarının size geçtiği sözleşmede açıkça yazmıyorsa, kodun sizin olduğunu varsaymak risklidir. Aynı soru kod deposu, bulut hesapları, alan adı, uygulama mağazası hesapları ve veritabanı için de geçerlidir: bunlar ajansın hesabında açılmışsa, ajansı değiştirmek istediğinizde önce bir devir pazarlığı yaparsınız. Veri için de ayrı bir soru sorun: çalışma bittiğinde ya da ajansı değiştirdiğinizde verilerinizi hangi biçimde, ne kadar sürede ve ek bedelle mi dışa aktarabileceğinizi teklif yazmalıdır. Bir kod deposunu sonradan başka bir hesaba devretmek teknik olarak mümkündür (GitHub'ın depo devri belgesi (yeni sekmede açılır) bunu anlatır), ama hesabın baştan şirketiniz adına açılması bu pazarlığı hiç gerektirmez. Sözleşmeyi imzalamadan önce bir avukata okutun.

Para birimi, KDV ve ödeme planı

Türkiye'de alınan tekliflerde iki ayrıntı toplam rakamı fark ettirmeden değiştirir. Birincisi KDV'dir: teklifin KDV dahil mi hariç mi verildiği yazmıyorsa, iki rakamı yan yana koymak yanıltıcıdır. İkincisi para birimidir: dolar ya da euro üzerinden verilen bir teklifte kur riski sizdedir, Türk lirası üzerinden verilen uzun bir projede ise ajans bu riski fiyata eklemiş olabilir. Ödeme planı da karşılaştırmanın parçasıdır. Peşin ağırlıklı bir plan ile tarihlere değil, teslim edilen aşamaların kabulüne bağlı bir plan, aynı toplam rakamda size çok farklı bir risk yükler.

Sabit fiyat neyi kapsamalı, neyi kapsamamalı?

Sabit fiyat, yazılı bir kapsamın belirli bir bedelle teslim edilmesi taahhüdüdür; kapsam yazılı değilse taahhüt de havada kalır. Türk Borçlar Kanunu eser sözleşmesinde bu modele götürü bedel der: bedel götürü olarak belirlenmişse yüklenici, iş öngörülenden fazla emek ve masraf gerektirse bile kural olarak bedelin artırılmasını isteyemez (TBK md. 480) (yeni sekmede açılır). Aynı kanun, yaklaşık olarak belirlenen bir bedelin iş sahibinin kusuru olmadan aşırı ölçüde aşılacağı anlaşılırsa iş sahibine sözleşmeden dönme hakkı tanır (TBK md. 482) (yeni sekmede açılır). Bir yazılım sözleşmesinin hangi hükümlere tabi olduğu sözleşmenin içeriğine göre değişebilir; bu özet Ekim 2026 itibarıyla kanun metnine dayanır ve hukuki görüş değildir. Bu yüzden "yaklaşık" ya da "tahmini" bir rakamla "sabit" bir rakam aynı şey değildir ve teklifin hangisi olduğunu yazılı olarak sormanız gerekir.

Sabit fiyatlı bir teklifte en azından şunlar yer almalıdır:

• Yazılı kapsam: Ekranlar, roller, entegrasyonlar ve raporlar madde madde; kapsam dışında bırakılanlar da ayrı bir listede.
• Teslim planı ve kabul ölçütü: Hangi parçanın ne zaman teslim edileceği ve bir parçanın "bitti" sayılması için neyin çalışması gerektiği.
• Tasarım ve test: Kaç tur tasarım revizyonu yapılacağı, testin kim tarafından ve hangi cihazlarda yapılacağı.
• Yayına alma: Sunucu kurulumu, alan adı bağlantısı, hata izleme ve ilk yayın.
• Dokümantasyon ve devir: Kurulum ve işletme belgeleri, kod deposunun ve hesapların teslim durumu.
• Destek dönemi: Süresi, kapsamı ve hata bildirimlerine dönüş süresi.

Şu kalemlerin sabit fiyatın dışında kalması ise normaldir, yeter ki teklifte ayrı satırlar olarak görünsünler:

• Üçüncü taraf ücretleri: Barındırma, alan adı, e-posta servisi, harita ya da SMS servisleri ve ücretli lisanslar. Mobil uygulamalarda mağaza hesapları da buraya girer: Ekim 2026 itibarıyla Apple Developer Program üyeliği yıllık 99 USD (yeni sekmede açılır), Google Play geliştirici hesabı ise bir defaya mahsus 25 USD kayıt ücreti (yeni sekmede açılır) gerektiriyor. Bu hesaplar da şirketiniz adına açılmalıdır.
• Kapsam dışı yeni istekler: Kapsam yazıldıktan sonra eklenen her özellik, değişiklik kuralına göre ayrıca fiyatlanır.
• İçerik üretimi: Metin yazımı, fotoğraf çekimi ve çeviri, aksi yazılmadıkça sizin tarafınızdadır.
• Bakım sözleşmesi: Destek dönemi bittikten sonraki güncellemeler ve geliştirmeler ayrı ve süreli bir sözleşmenin konusudur.

Sabit fiyat her proje için doğru model değildir. Seçimi şu ölçüye göre yapın:

• Sabit fiyatı seçin: İlk sürümün kapsamını yazıya dökebiliyor, bütçenizin üst sınırını biliyor ve teslim tarihine bağlı bir iş planınız varsa.
• Zaman ve malzeme (adam-saat) modelini seçin: Ne geliştireceğiniz henüz belli değilse, ürün kullanıcı geri bildirimiyle haftadan haftaya şekillenecekse ya da mevcut bir ekibe süreli destek alıyorsanız. Bu modelde haftalık harcama raporu ve yazılı bir üst sınır isteyin.
• İkisini birleştirin: Kapsam kısmen netse önce kısa ve sabit fiyatlı bir keşif aşaması, ardından onun çıkardığı yazılı kapsama göre sabit fiyatlı geliştirme.

Teklif karşılaştırma tablosu: aynı ölçüyle okuyun

Üç teklifi yan yana koyduğunuzda toplam rakamlara değil, aşağıdaki satırlara bakın. Her satırda bir teklif "iyi işaret" sütununa uyuyorsa artı, "uyarı işareti" sütununa uyuyorsa eksi yazın; eksik bilgi de eksi sayılır. Bu tablo, tekliflerin hangi satırda ayrıştığını tek bakışta gösterir.

Yazılım projesi teklifi nasıl karşılaştırılır? Üç teklif için adım adım

Karşılaştırmanın adil olması için üç ajansın aynı belgeye teklif vermesi gerekir. Aşağıdaki sıra, teklif istemeden önceki hazırlıktan karar toplantısına kadar olan yolu kapsar ve adımların çoğu bir iki saatlik iştir.

1. Tek sayfalık bir ihtiyaç belgesi yazın. Problemi, kullanıcıları, ilk sürümde olması gerekenleri, bağlanacak sistemleri ve varsa kesin tarihi yazın. Çözümü değil ihtiyacı anlatın.
2. Aynı belgeyi üç ajansa gönderin ve aynı soruları sorun. Ajanslardan biri farklı bir kapsam öneriyorsa onu ayrı bir seçenek olarak isteyin ki ana karşılaştırma bozulmasın.
3. Teklifleri kendi kapsam listenizle madde madde eşleştirin. Eksik maddeleri yazılı olarak sorun ve cevabın teklifin parçası olmasını isteyin.
4. Varsayımları ve kapsam dışı listelerini yan yana koyun. Bir teklifin dışarıda bıraktığı işi, diğerinin içerdiği bir işle kıyaslamayın.
5. Karşılaştırma tablosundaki sekiz satırı her teklif için doldurun. Eksik bilgiyi artı değil eksi sayın.
6. Fiyat dışı kalemleri ekleyerek ilk yılın toplamını hesaplayın. Geliştirme bedeline barındırma, lisanslar, mağaza hesapları ve bakım sözleşmesini ekleyin; para birimini ve KDV'yi eşitleyin. Yazılım yaptırma maliyetini karşılaştırırken ölçü olarak bu ilk yıl toplamını kullanın.
7. Teknik görüşmeyi kodu yazacak kişilerle yapın. Bir ekibin işi nasıl anladığını en iyi, projede çalışacak geliştiricinin sorduğu sorulardan öğrenirsiniz.
8. Kararı en düşük rakama göre değil, en az belirsizliğe göre verin. Rakamlar birbirine yakınsa, kapsamı en net ve sahiplik koşulları en temiz olan teklifi seçin.

Altıncı adımdaki ilk yıl toplamını her teklif için aynı formülle hesaplayın: geliştirme bedeli (KDV hariç ve aynı para birimine çevrilmiş) + aylık barındırma × 12 + aylık lisans ve servis giderleri × 12 + mağaza hesapları gibi yıllık ücretler + destek döneminden sonraki bakım sözleşmesinin o yıla düşen tutarı. Bir teklif emeği adam-gün olarak kırıyorsa, her kalemin gün sayısını kendi kapsam listenizdeki maddeyle eşleştirin; gün sayısı yazılmamış ya da tek satırda toplanmış büyük kalemler, belirsizliğin yoğunlaştığı yerlerdir. Bu kalemleri teklif sahibinden ayrıntılandırmasını isteyin. Formül size piyasa fiyatını söylemez, ama üç teklifi aynı ölçüye getirir.

Varsayımsal bir örnek

Bir lojistik şirketinin, müşterilerinin sipariş durumunu görebileceği bir portal istediğini düşünün; bu bir örnek senaryodur, gerçek bir müşteri değildir. A ajansının teklifi en düşük rakamdır, ama kapsamında yalnızca ekranlar vardır; ERP entegrasyonu "müşteri tarafından sağlanacak API ile" diye geçiştirilmiş, destek dönemi hiç yazılmamıştır. B ajansı entegrasyonu dahil etmiştir, ama kod deposunu ve sunucuyu kendi hesabında tutmayı önermektedir. C ajansının rakamı en yüksektir; kapsamı madde madde yazmış, ERP'nin test ortamını bir varsayım olarak koymuş, değişiklik kuralını ve destek dönemini tanımlamış, tüm hesapları şirket adına açmayı taahhüt etmiştir. A'ya entegrasyonu ve desteği, B'ye de sahipliğin devrini ayrıca fiyatlattığınızda aradaki farkın önemli bir kısmı kapanabilir; kapanmasa bile artık neyin bedelini ödediğinizi bilerek seçersiniz.

Yazılım firmasıyla görüşmede hangi sorular sorulmalı?

Aşağıdaki listeyi görüşmeye yanınızda götürün. Cevabın kendisi kadar, cevabın ne kadar net verildiği de bilgi verir: "projeye göre değişir" diyen bir ekipten, neye göre değiştiğini de anlatmasını isteyin. Cevapları görüşmeden sonra e-postayla yazılı olarak teyit etmek, teklif metnine girmeyen sözlü taahhütlerin kaybolmasını önler.

• Bu fiyat sabit mi, yoksa tahmini mi? Tahminiyse üst sınır nedir?
• Kapsam dışında bıraktığınız işler neler, bunları yazılı bir liste olarak verebilir misiniz?
• Fiyat hangi varsayımlara dayanıyor ve bir varsayım tutmazsa ne olur?
• Değişiklik talebi nasıl yapılıyor ve geliştirmeden önce nasıl fiyatlanıyor?
• Projede kimler çalışacak ve onlarla doğrudan konuşabilecek miyiz?
• Ne sıklıkla çalışan bir sürüm göreceğiz ve bunu nerede deneyeceğiz?
• Kod deposu, bulut hesapları, alan adı ve mağaza hesapları kimin adına açılacak?
• Kaynak koduna ilişkin mali haklar sözleşmede nasıl devrediliyor?
• Destek dönemi ne kadar, neyi kapsıyor ve hata bildirimine ne kadar sürede dönüyorsunuz?
• Yayından sonraki aylık işletme giderleri (barındırma, lisanslar, servisler) yaklaşık ne olacak?
• Teklif KDV dahil mi, hangi para biriminde ve ödeme planı teslimlere bağlı mı?
• Bu projeyi bizimle yapmamanız gereken bir durum görüyor musunuz?

En çok şey anlatan soru sonuncusudur. Sizi gereksiz bir işten vazgeçirmeye ya da daha küçük bir başlangıç önermeye hazır bir ekibin, kapsamı da dürüst yazma ihtimali yüksektir. Web sitesi projelerinde arama motoru tarafı için sorulacak teknik soruları ayrıca Next.js SEO kontrol listemizde topladık. Yapay zekâ projelerinde ise model kullanım bedeli gibi işletme maliyetleri ayrıca hesaplanmalıdır; bunu şirketlerde yapay zekâ otomasyonu rehberimizde ele aldık.

Teklif değerlendirirken sık yapılan hatalar

Aşağıdakiler teklif süreçlerinde sık rastlanan genel kalıplardır. Çoğu, kararı hızlandırmak isterken kapsamı yazmayı atlamaktan doğar ve sonradan hem süreye hem bütçeye yansır.

• Toplam rakamları karşılaştırmak: Farklı kapsamların rakamlarını yan yana koymak, en dar kapsamı ödüllendirir.
• Kapsamı hiç yazmamak: Yazılı bir kapsam yoksa sabit fiyat da, teslim tarihi de, değişiklik kuralı da dayanaksız kalır.
• İşletme maliyetini unutmak: Geliştirme bedeline odaklanıp barındırma, lisans, servis ve bakım giderlerini hesaba katmamak, ilk yılın bütçesini şaşırtır.
• Sahipliği sona bırakmak: Hesapların ve kodun kimde olduğunu yayından sonra sormak, pazarlık gücünüzün en düşük olduğu anda sormaktır.
• Her şeyi ilk sürüme koymak: "Madem yaptırıyoruz" diyerek ilk sürüme eklenen her özellik hem maliyeti hem riski artırır; ilk sürüm, gerçek kullanımdan öğrenebilecek kadar küçük olmalıdır.
• Satış görüşmesiyle karar vermek: Projeyi kimin geliştireceğini görmeden imza atmak, sunumu yapan kişiyle işi yapacak kişinin farklı olabileceğini göz ardı etmektir.

Biz olsak ne yapardık?

Şirket içi bir panel, müşteri portalı ya da web uygulaması gibi tipik bir projede önce kapsamı netleştirmeyi, kodu ondan sonra yazmayı öneririz. Süreç ücretsiz, 30–45 dakikalık bir keşif görüşmesiyle başlar ve problemi nasıl anladığımızın yazılı bir özetiyle biter. Ardından işi teslim edilebilir parçalara ayırır, ilk sürümde neyin yer alıp neyin bekleyebileceğine birlikte karar verir ve bunu bir kapsam dokümanı, teslim planı ve sabit fiyatla yazılı hale getiririz. Kapsam sonradan değişirse değişiklik geliştirilmeden önce fiyatlanır, böylece faturada sürprizle karşılaşmazsınız.

Geliştirme iki haftalık döngülerle ilerler ve her döngü, test ortamında kendinizin açıp deneyebileceği çalışan bir sürümle biter. Sizinle kodu yazan kişiler arasında bir müşteri temsilcisi katmanı yoktur; kapsamı çıkaran, geliştiren ve yayın sonrası sorularınızı yanıtlayan aynı ekiptir. Kod deposu, bulut hesapları, alan adları ve üçüncü taraf servisler ilk günden şirketiniz adına açılır; proje dokümantasyon, bir devir toplantısı ve süresi belirlenmiş bir destek dönemiyle biter. Bu yaklaşımı hangi işlerde uyguladığımızı özel web uygulaması geliştirme, mobil uygulama geliştirme, SaaS platform geliştirme ve yönetim paneli geliştirme sayfalarında anlattık. İş süreçlerinize yapay zekâ eklemek istiyorsanız yapay zekâ entegrasyonu ve süreç otomasyonu sayfası daha uygun bir başlangıç noktasıdır.

Teklif sürecinizde bizimle çalışmasanız bile aynı yapıyı isteyin: kapsam yazılı, fiyat sabit ya da üst sınırlı, değişiklik kuralı açık, hesaplar sizin adınıza. Bu dört koşulu karşılayan bir teklif, rakamı biraz yüksek olsa bile genellikle toplamda daha az sürpriz çıkarır.

Hangi durumlarda bizimle çalışmamalısınız?

Her ihtiyaç bir yazılım ekibi gerektirmez ve bunu baştan söylemek hem sizin hem bizim zamanımızı korur. Aşağıdaki durumlarda başka bir yol daha mantıklıdır:

• Kapsam çok küçükse: Tek bir formu bir tabloya bağlamak ya da birkaç sayfalık bir tanıtım sitesini güncellemek gibi işler için keşif, kapsam dokümanı ve iki haftalık döngüler gereğinden ağır bir süreçtir. Bu işlerde serbest çalışan bir geliştirici ya da kısa süreli bir destek daha uygundur.
• Kodsuz bir araç yetiyorsa: İhtiyacınız hazır bir form aracı, otomasyon platformu ya da site kurucuyla karşılanıyorsa özel geliştirme gereksiz bir maliyettir. Hazır ürünün nerede yettiğini ve nerede tıkandığını, yazının başında bağlantısını verdiğimiz karar rehberinde anlattık.
• Şirket içinde bir yazılım ekibiniz varsa: Ekibiniz işi yapabilecek kapasitedeyse, dışarıdan bir ekibin getireceği koordinasyon yükü kazancı aşabilir. Belirli bir uzmanlık eksikse tüm projeyi değil, yalnızca o parçayı dışarıdan almak daha mantıklıdır.

Bu durumların hiçbiri sizi tanımlamıyorsa ve elinizde karşılaştırmak istediğiniz teklifler ya da henüz yazılmamış bir kapsam varsa, iletişim sayfasından projeyi birkaç cümleyle anlatın. Doğru ekip olup olmadığımızı ve mantıklı ilk adımın ne olduğunu açıkça söyleriz.