Web Yazılım Projesine Başlamadan Önce 5 Adım

Bir web yazılım projesinin kaderi çoğu zaman ilk satır kod yazılmadan belirlenir. Teklif isteyen şirket "neye ihtiyacımız var" sorusunu netleştirmeden yola çıktığında, gelen teklifler birbirinden farklı projeleri fiyatlar ve karşılaştırılamaz. Bütçe aşımı da teslim gecikmesi de genellikle buradan başlar.

Bu yazı, bir yazılım ajansı ile ilk görüşmeye girmeden önce kendi tarafınızda yapmanız gereken hazırlığı anlatıyor. Her adımın sonunda elinizde somut bir çıktı olacak; beş adımın sonunda da bunlar tek sayfalık bir proje brief'inde birleşecek.

Güncelleme (15 Ekim 2026): Yazı genişletildi: her adıma çıktı ve örnek eklendi, kullanılabilir bir brief şablonu, keşif aşamasının çıktıları ve teklif karşılaştırma tablosu eklendi. Kaynağı gösterilemeyen bir ifade çıkarıldı.

Kısa cevap: Web yazılım projesi, kod yazmadan önce beş kararla başlatılır: (1) projenin hangi iş metriğini değiştireceği, (2) ilk sürümün kapsamı (MVP), (3) gerçekçi bir bütçe aralığı ve tarih, (4) entegrasyonlar, veri ve hesap sahipliği gibi erken teknik kararlar, (5) bu bilgilerle aynı brief'i en az üç firmaya gönderip teklifleri yan yana karşılaştırmak. Bu hazırlık bir iki haftalık iştir ve sonunda teklifler aynı işi fiyatladığı için karşılaştırılabilir hale gelir.

Neden hazırlık sizin tarafınızda başlamalı?

Türkiye'de şirketlerin büyük çoğunluğunun içeride yazılım ekibi yok. TÜİK'in 2026 araştırmasına göre en az 10 çalışanı olan girişimlerin yalnızca yüzde 15,2'si bilgi ve iletişim teknolojileri uzmanı istihdam ediyor. Bu uzmanı işe almaya çalışanların yaklaşık üçte biri de işe alımda güçlük yaşadığını söylüyor.

Sonuç şu: Projeyi büyük ihtimalle dışarıdan bir ekip yapacak, ama projenin ne olduğunu bilen tek taraf sizsiniz. Bu bilgiyi yazıya dökmezseniz firma kendi varsayımlarıyla doldurur. Varsayımlar da teklifin içinde, fark edilmeden fiyatlanır.

Adım 1: Projenin değiştireceği metriği yazın

"Kurumsal sitemizi yenileyelim" bir proje tanımı değil, bir istektir. Tanım, projenin hangi sayıyı nereden nereye taşıyacağını söyler. Üç soruyu yanıtlayın:

• Bu proje hangi iş metriğini iyileştirecek: satış, teklif talebi, operasyonda harcanan saat, hata oranı?
• Bu metriğin bugünkü değeri ne? Bilmiyorsanız, ilk iş onu ölçmektir.
• 6 ya da 12 ay sonra projeye "başarılı" demek için hangi değeri görmeniz gerekir?

Hedef cümlesini yazarken hedef kullanıcıyı da adıyla yazın: "Satın alma müdürü", "sahadaki teknisyen", "ilk kez gelen bireysel müşteri". Kullanıcıyı tanımadığınızı fark ederseniz, birkaç kısa görüşme yapmak tahminden ucuzdur; yöntemini UX araştırma rehberimizde anlattık.

Bu adımın çıktısı: Bir cümlelik hedef, bugünkü değer, hedef kullanıcı.

Adım 2: Kapsamı özellik listesiyle değil, akışla çizin

İlk sürümde her şeyi istemek süreyi ve maliyeti büyütmenin en hızlı yoludur. Ama "MVP yapalım" demek de yetmez; neyin MVP'ye girdiğine karar vermenin bir yöntemi olmalı.

Özellik listesi yazmak yerine, hedef kullanıcının baştan sona izlediği birkaç ana akışı yazın. Örneğin bir bayi portalında: "Bayi giriş yapar, kendi fiyatını görür, sepeti onaya gönderir, siparişin durumunu izler." Her akışı adım adım yazınca eksik parçalar kendiliğinden ortaya çıkar: Onayı kim veriyor? Fiyat nereden geliyor? Bildirim e-postayla mı gidiyor?

Sonra her parçayı dört gruba ayırın (MoSCoW yöntemi):

• Must: Olmazsa ana akış çalışmıyor.
• Should: Önemli, ama ilk sürümde elle ya da geçici bir yolla çözülebilir.
• Could: Güzel olur; zaman kalırsa.
• Won't (bu sürümde): Bilinçli olarak ertelenenler. Bu listeyi yazmak, en az diğerleri kadar değerlidir.

Pratik bir kural: "Should" maddelerinden biri için "ilk üç ay bunu Excel'le idare edebilir miyiz?" sorusunun cevabı evetse, o madde ilk sürüme girmez.

Bu adımın çıktısı: 2-4 ana akış ve MoSCoW tablosu.

Adım 3: Bütçeyi aralık, tarihi gerekçe olarak verin

Pek çok şirket bütçesini söylememeyi pazarlık avantajı sanır. Oysa bütçe bilinmeyince firma iki şeyden birini yapar: Ya en geniş yorumla pahalı bir teklif hazırlar ya da en dar yorumla ucuz bir teklif verip farkı sonradan değişiklik talebi olarak çıkarır. Bir aralık vermek ("şu ile şu arası") ikisini de engeller ve teklifleri aynı çerçeveye oturtur.

Tarih için de aynısı geçerli: "Mümkün olan en kısa sürede" yerine tarihin nedenini yazın: bir fuar, bir kampanya, bir sözleşme bitişi. Firma, tarihe yetişmek için kapsamdan neyin ertelenebileceğini ancak bu gerekçeyi bilirse önerebilir.

Bütçeyi yalnızca geliştirme ücreti olarak düşünmeyin. Sık unutulan kalemler:

• Barındırma ve alan adı: Aylık ya da yıllık, proje bittikten sonra da devam eder.
• Üçüncü taraf servisler: Ödeme altyapısı komisyonu, SMS ve e-posta gönderimi, harita, arama servisi gibi kullanım bazlı ücretler.
• İçerik: Metinler, ürün fotoğrafları, çeviriler. Çoğu projede en geç teslim edilen parça budur.
• Bakım ve destek: Güvenlik güncellemeleri, küçük değişiklikler, izleme.
• Beklenmeyen işler için pay: Kapsamda keşif sırasında ortaya çıkan eksikler için bir yedek.

E-ticaret tarafında bu kalemlerin nasıl dağıldığını e-ticaret sitesi kurmanın maliyeti yazımızda ayrıntılı inceledik.

Bu adımın çıktısı: Bütçe aralığı, hedef tarih ve tarihin gerekçesi, yıllık işletme kalemlerinin listesi.

Adım 4: Sonradan pahalıya patlayan teknik kararları şimdi verin

Teknoloji seçiminin büyük kısmını işini bilen bir ekibe bırakabilirsiniz. Ama bazı konular teknoloji değil, sizin işinizle ilgili bilgilerdir ve yalnızca siz cevaplayabilirsiniz:

Entegrasyonlar. Yeni sistem hangi mevcut sistemlerle konuşacak? ERP, muhasebe ve e-fatura, kargo, pazaryerleri, CRM. Her biri için sistemin adını, sürümünü ve bir API'si olup olmadığını öğrenin. Entegrasyon sayısı, teklif fiyatını en çok oynatan kalemlerden biridir; pazaryeri tarafını ayrıca pazaryeri entegrasyonu yazımızda ele aldık.

Veri taşıma. Eski sistemdeki ürünler, müşteriler, siparişler, blog yazıları taşınacak mı? Kaç kayıt var, hangi formatta? "Eski sitedeki her şey gelsin" cümlesi, projenin en az planlanan işine dönüşebilir.

Kişisel veri. Sistem müşteri, bayi ya da çalışan verisi tutacaksa KVKK aydınlatma metinleri, açık rıza akışları ve verinin hangi ülkedeki sunucuda duracağı en baştan konuşulmalıdır. Bunu sona bırakmak, bitmiş ekranların yeniden tasarlanması demektir.

Hesap ve kod sahipliği. Alan adı, barındırma, analitik, ödeme altyapısı ve kod deposu hesapları kimin adına açılacak? Doğru cevap: sizin şirketinizin adına. Kaynak kodun teslim koşulunu da sözleşmeye yazdırın.

Performans ve SEO beklentisi. Organik trafik işiniz için önemliyse bunu baştan söyleyin. Örneğin içerik ağırlıklı ve aramaya bağımlı bir sitede sunucu tarafında render eden bir yapı (Next.js nedir?) tercih edilir; çok kanallı satışta ise headless mimari gündeme gelir. Kararı ekip verir, ama beklentiyi siz koyarsınız.

Bu adımın çıktısı: Entegrasyon envanteri, veri taşıma notu, hesap sahipliği listesi.

Adım 5: Aynı brief'i en az üç firmaya gönderin

Elinizdeki dört çıktıyı tek bir belgede toplayın ve aynı belgeyi en az üç firmaya gönderin. Brief aynı olunca teklifler aynı işi fiyatlar; fark fiyatta değil, yorumda ortaya çıkar. Görüştüğünüz firmaların hangi modelle çalıştığını anlamak için yazılım firmaları türleri yazımıza, değerlendirme için de yazılım şirketi seçerken 10 kriter rehberimize bakabilirsiniz.

Teklifler gelince fiyattan önce şu tabloyu doldurun:

Son satır en çok şey söyleyendir. Brief'inizdeki bir boşluğu fark edip soru soran firma, projeyi gerçekten okumuştur.

Bir sayfalık proje brief'i şablonu

Aşağıdaki şablonu kopyalayıp doldurabilirsiniz. Her alana birkaç cümle yeterli; amaç roman yazmak değil, varsayım bırakmamak.

PROJE BRIEF'İ

1. Şirket ve bağlam
   Ne iş yapıyoruz, bu proje neden şimdi gündemde?

2. Hedef
   Değişmesini istediğimiz metrik: ...
   Bugünkü değeri: ...      12 ay sonra hedef: ...
   Hedef kullanıcı(lar): ...

3. Ana akışlar (2-4 tane)
   Akış 1: Kullanıcı ... yapar → ... → ...
   Akış 2: ...

4. Kapsam (MoSCoW)
   Must: ...
   Should: ...
   Could: ...
   Bu sürümde yok: ...

5. Mevcut sistemler ve entegrasyonlar
   Sistem adı / sürümü / API var mı / kim yönetiyor

6. Veri
   Taşınacak veri, kayıt sayısı, format
   Kişisel veri var mı, nerede saklanmalı

7. Bütçe ve zaman
   Bütçe aralığı: ...
   Hedef tarih: ...   Gerekçesi: ...

8. Sahiplik ve işletme
   Hesaplar kimin adına, kod teslimi, beklenen destek

9. Karar süreci
   Projede kim karar veriyor, kim onaylıyor, ne zaman karar vereceğiz?

Dokuzuncu madde kolayca atlanır ama projelerin takvimini en çok etkileyen şeylerden biridir: Tasarımı onaylayacak kişi ilk görüşmede yoksa, revizyon turları uzar.

Keşif aşamasında ne olur, sonunda elinizde ne olmalı?

İyi hazırlanmış bir brief, keşif aşamasının yerini tutmaz; onu kısaltır ve odaklar. Keşif (discovery), seçtiğiniz ekibin brief'inizi sorgulayıp gerçek bir plana dönüştürdüğü aşamadır. Bizim süreçte bu aşama genellikle 1-2 hafta sürer ve ilk keşif görüşmesi ücretsizdir; adımların tamamını yazılım ajansı mı, freelancer mı? yazımızın süreç bölümünde anlattık.

Keşif bittiğinde elinizde en azından şunlar olmalı:

• Ana akışların ekran taslakları (wireframe) ya da tıklanabilir bir prototip
• Netleşmiş kapsam listesi ve "bu sürümde yok" listesi
• Entegrasyonların teknik doğrulaması: API gerçekten var mı, erişim nasıl alınacak?
• Sprint ya da kilometre taşı bazında bir takvim
• Bilinen riskler ve her biri için bir önlem

Bu çıktılar sizin malınızdır. Keşiften sonra farklı bir firmayla devam etmeye karar verseniz bile işinize yaramalıdır; yaramıyorsa, keşif aslında bir satış toplantısıydı.

En sık yapılan beş hata

• Brief'i ilk görüşmeden sonra yazmak. Firma sizin yerinize yazar, kendi kapsamını çizer.
• Her firmaya farklı şey anlatmak. Teklifler karşılaştırılamaz hale gelir.
• İçeriği son haftaya bırakmak. Ekranlar hazır, metin ve görseller yok; canlıya çıkış bekler.
• Hesapları ajansın adına açtırmak. Ayrılık günü alan adını ve verinizi geri almak zorlaşır.
• Güvenlik ve performansı "sonra" diye ertelemek. Sonradan eklenen güvenlik, baştan tasarlanandan her zaman pahalıdır.

Son söz

Bir web yazılım projesine iyi başlamak, teknik bilgi gerektirmez; netlik gerektirir. Hedefi, akışları, bütçe aralığını ve sahiplik konularını yazıya döktüğünüzde hem doğru firmayı seçmek hem de projeyi takvimde tutmak kolaylaşır.

Brief'iniz hazırsa ya da yarısında takıldıysanız, birlikte netleştirebiliriz. Özel yazılım geliştirme sürecimize göz atabilir ya da ücretsiz keşif görüşmesi için bize yazabilirsiniz.