Web Uygulaması Geliştirme Süreci: Fikirden Çalışan MVP'ye Hangi Aşamalar Var?

Bir web uygulaması fikri genellikle bir ekran listesiyle gelir: müşteri paneli, raporlar, bildirimler, yönetim ekranı. Liste uzadıkça süre ve bütçe de uzar, ilk sürüm bir türlü kullanıma açılamaz. Sorun çoğu zaman teknik değildir. Hangi işin ilk sürümde çalışması gerektiğine karar verilmemiştir.

Bu yazıda web uygulaması geliştirme sürecini fikirden çalışan MVP'ye kadar beş aşamada anlatıyoruz: her aşamanın somut çıktısı, bir sonraki aşamaya geçmeden verilen karar ve MVP'ye girmemesi gerekenler. Web uygulama geliştirme projelerimizde bu sırayı izliyoruz.

MVP ne değildir?

Terimi yaygınlaştıran Eric Ries, 2009'da minimum uygulanabilir ürünü, ekibin en az çabayla müşteriler hakkında en fazla doğrulanmış öğrenmeyi toplamasını sağlayan ürün sürümü olarak tanımladı. Tanımda iki kelime öne çıkıyor: öğrenme ve çaba. MVP özellikleri yarım bırakılmış bir ürün değildir. En kritik iş akışının uçtan uca çalışan, gerçek kullanıcıya açılabilen halidir.

Pendo'nun 615 müşterisinin kullanım verisine dayanan 2019 raporuna göre ortalama bir yazılım ürünündeki özelliklerin yüzde 80'i nadiren kullanılıyor ya da hiç kullanılmıyor. CB Insights'ın Mart 2026'da yayımladığı analizde kapanan girişimlerin yüzde 43'ünde ürün ile pazar arasındaki uyumsuzluk neden olarak öne çıkıyor. İki veri de aynı yöne işaret ediyor: ilk sürümde neyin yapılmayacağına karar vermek, neyin yapılacağına karar vermek kadar önemli.

5 aşamaya genel bakış

1. 01

   Aşama 1

   Kapsam

   • Ne yapılacağı, kimin için yapılacağı ve başarı kriteri yazılır
   • MVP'de çalışacak tek kritik iş akışı seçilir
   • Kapsam dışı bırakılan özellikler listelenir

   ÇıktıTek sayfalık kapsam belgesi ve kapsam dışı listesi

2. 02

   Aşama 2

   Veri modeli

   • Varlıklar ve aralarındaki ilişkiler çizilir
   • Kullanıcı rolleri ve yetkiler tanımlanır
   • Mevcut verinin nereden taşınacağı belirlenir

   ÇıktıVarlık ilişki diyagramı ve yetki tablosu

3. 03

   Aşama 3

   Prototip

   • Kritik akışın ekranları tıklanabilir prototipe dönüşür
   • Beş gerçek kullanıcıyla test yapılır
   • Bulunan sorunlar kod yazılmadan düzeltilir

   ÇıktıTest edilmiş tıklanabilir prototip

4. 04

   Aşama 4

   Geliştirme

   • Arayüz, sunucu ve entegrasyonlar kurulur
   • Her hafta test ortamında çalışan bir sürüm gösterilir
   • Temel güvenlik gereksinimleri baştan uygulanır

   ÇıktıTest ortamında çalışan MVP

5. 05

   Aşama 5

   Teslim

   • Kabul testleri yapılır
   • Uygulama canlıya alınır ve izlemeye başlanır
   • Kod, erişimler ve dokümantasyon devredilir

   ÇıktıCanlıda çalışan MVP ve devir paketi

Aşama 1: Kapsam

Kapsam aşaması üç soruya cevap verir: bu uygulama hangi işi yapacak, bu işi kim yapacak ve işin başarılı olduğunu nasıl anlayacağız? Başarı kriteri ölçülebilir olmalı. "Teklif hazırlama süresi yarıya inecek" bir kriterdir, "süreç kolaylaşacak" değildir.

Bu aşamanın en değerli çıktısı kapsam dışı listesidir. Görüşmelerde çıkan ama ilk sürüme girmeyecek her özellik bu listeye yazılır. Liste, sonraki sürümlerin de ilk taslağı olur ve "unutuldu mu?" sorusunu ortadan kaldırır.

Aşama 2: Veri modeli

Fred Brooks, 1975'te yayımlanan The Mythical Man-Month kitabında, akış şemaları yerine tabloları görmenin yeterli olduğunu, tablolar görüldüğünde akışın zaten anlaşılacağını yazar. Bir web uygulamasında tablolar veri modelidir: müşteri, sipariş, teklif, görev gibi varlıklar ve aralarındaki ilişkiler.

Veri modelini ekran tasarımından önce yapıyoruz, çünkü ekranlar, raporlar ve yetkiler bu modelin üzerine kurulur. Geliştirme başladıktan sonra değişen bir ilişki, o ilişkiye bağlı her ekranın ve raporun yeniden elden geçmesi demektir. Aynı aşamada kullanıcı rolleri ve kimin hangi kaydı görüp değiştirebileceği de yazılır. OWASP'ın 2025 listesinde web uygulamalarındaki en yaygın risk hâlâ erişim kontrolündeki kusurlar.

Aşama 3: Prototip

Prototip, kritik iş akışının tıklanabilir ekranlarıdır. Amacı, akışın gerçek kullanıcı için anlaşılır olup olmadığını kod yazılmadan görmektir. Nielsen Norman Group'un 2003'teki kağıt prototip yazısında belirttiği gibi, bir ürünü geliştirme sürecinin başında değiştirmek sonradan değiştirmekten çok daha ucuzdur.

Test için büyük bir örneklem gerekmiyor. Jakob Nielsen'in 2000 tarihli yazısına göre benzer kullanıcılardan oluşan beş kişilik bir test, kullanılabilirlik sorunlarının büyük kısmını ortaya çıkarır. Sorunlar düzeltildikten sonra yapılan ikinci küçük tur, tek büyük bir testten daha fazla şey öğretir. Kullanıcı grupları birbirinden çok farklıysa her grup ayrı test edilir.

Aşama 4: Geliştirme

Geliştirme aşamasında her hafta test ortamında çalışan bir sürüm gösteriyoruz. Haftalık demo iki işe yarar: sapmalar erken yakalanır ve kapsam dışı listesine yeni bir özellik eklenmek istendiğinde bunun bedeli somut olarak konuşulur.

Güvenliği bu aşamanın ilk gününden itibaren ele alıyoruz. Referans olarak OWASP'ın uygulama güvenliği doğrulama standardı ASVS'nin birinci seviyesini alıyoruz. Standardın 2025'te yayımlanan 5.0 sürümü birinci seviyeyi bir uygulamayı güvenceye alırken dikkate alınması gereken asgari gereksinimler olarak tanımlıyor. Az miktarda hassas veri toplayan erken aşama ürünler için de başlangıç noktası olarak bu seviyeyi öneriyor.

Aşama 5: Teslim

Teslim, kabul testleriyle başlar. Kapsam aşamasında yazılan başarı kriteri burada test senaryosuna dönüşür. Uygulama canlıya alındıktan sonra hata kayıtları, performans ve kullanım izlenmeye başlar.

Teslimin en çok atlanan kısmı devirdir. Kaynak kod deposu, sunucu ve alan adı erişimleri, veri modeli dokümanı, kurulum ve yayın talimatları ile açık işler listesi müşteriye devredilir. Kodun sahipliği sözleşmede baştan yazılmalı.

Her aşamanın karar kapısı

Aşamalar arasında birer karar kapısı var. Kapıdan geçilmeden bir sonraki aşamaya başlanmaz. Kapıların amacı hatayı en ucuz olduğu anda yakalamak.

McKinsey ve Oxford Üniversitesi'nin 2012'de 5.400'den fazla BT projesi üzerine yaptığı çalışmada, bütçesi 15 milyon doların üzerindeki projeler ortalama yüzde 45 bütçe aşımı yaşıyor ve beklenenden yüzde 56 daha az değer üretiyordu. Bu rakamlar büyük kurumsal projelere ait ve bir MVP'ye doğrudan aktarılamaz. Yine de mantık aynı: kapsamı ve kararı aşamalara bölmeyen projede hata geç fark edilir.

MVP'ye neler girmemeli?

• Kritik akışa hizmet etmeyen raporlar ve grafikler. İlk ay verisi birikmeden rapor anlamlı olmaz.
• Birden fazla dil ve para birimi, gerçek bir kullanıcı ihtiyacı yoksa.
• Gelişmiş rol ve izin kırılımları. İlk sürümde iki üç rol çoğu zaman yeterlidir.
• Az kullanılan entegrasyonlar. Haftada birkaç kez yapılan bir aktarım ilk sürümde elle yapılabilir.
• Mobil uygulama. Mobil uyumlu bir web arayüzü ilk sürümde çoğu ihtiyacı karşılar.
• Yapay zekâ özellikleri, kritik akışın parçası değilse.

Bu özelliklerin hiçbiri önemsiz sayılmaz. Hepsi kapsam dışı listesine yazılır ve ilk sürümün kullanım verisine göre sıraya konur. Mobil uygulama gerçekten gerekliyse kapsamını mobil uygulama geliştirme sürecimizde aynı mantıkla küçültüyoruz.

Parkmetria'da süreç

Aynı aşamaları kendi ürünümüz Parkmetria'da da uyguladık. Otopark işletmelerinin doluluk, abonelik, tahsilat ve müşteri verisini tek panelde toplayan ürünün mimarisi katmanlı: temelde operasyon paneli, üzerinde talep tahmini, etki ölçümü ve senaryo karşılaştırması. Ürün Next.js ve PostgreSQL üzerinde çalışıyor ve pilot sahada kullanılıyor. Karar katmanı doğrulama aşamasında, ticari sonuç verisi henüz yayımlanmadı.

Kendi ürünlerimizde öğrendiklerimizi müşteri projelerine web uygulama geliştirme hizmetimiz üzerinden taşıyoruz.

Nereden başlanır

Uygulamanın çözmesini istediğiniz tek işi bir cümleyle yazın. Ardından bu işi bugün kimin, hangi araçlarla ve ne kadar sürede yaptığını not edin. Bu iki satır, kapsam aşamasının ilk girdisidir.

Süreci birlikte yürütmek isterseniz web uygulama geliştirme sayfamızda MVP yaklaşımımızı, süre ve yatırım aralıklarını bulabilirsiniz.