Fikirden canlı ürüne
bütün maliyeti gör.

Üç aşamalı maliyet modeli

Keşif aşamasında hedef, bir varsayımı görünür hale getirmektir. Kullanıcının sorunu gerçekten yaşayıp yaşamadığını, teklifin anlaşılır olup olmadığını ve hangi akışın değer verdiğini öğrenirsiniz. Bu aşamada düşük riskli test verisi, tıklanabilir veya çalışan basit prototip, birkaç kullanıcı görüşmesi ve karar notu yeterli olabilir. Yüksek ölçekli altyapı yatırımı erken olabilir.

Pilot aşamasında sınırlı gerçek kullanıcıyla akışın tamamı denenir. Burada veri doğrulama, hata mesajları, geri bildirim toplama, erişim seviyesi ve destek süreci görünür olur. Kullanıcı ilk ekrandan daha ileri gittiğinde, bütçede düzeltme ve gözlem kalemi büyür. Bir fikrin demo olması ile işte kullanılabilmesi arasındaki fark bu aşamada anlaşılır.

Üretim aşaması ise devamlı sorumluluk taşır. Kimlik doğrulama, yetkilendirme, veri saklama, loglama, izleme, yedekleme, erişilebilirlik, performans ve hata durumunda geri alma gibi alanlar planlanmalıdır. Bu maliyetlerin gerekli düzeyi ürünün türüne göre değişir. Kullanıcı verisi, ödeme veya kritik karar varsa resmi platform koşullarını ve kurum politikalarını güncel olarak doğrulamak gerekir.

MVP'yi hesaplanabilir hale getirin

“MVP yapalım” sözü çoğu zaman kapsamı küçültmez, yalnızca belirsizleştirir. MVP için en fazla üç temel kullanıcı akışı seçin. Örneğin kullanıcı kayıt ekler, sonucu görür ve paylaşılan bağlantı oluşturur. Bu üç akış dışında kalan her özelliği bir park listesine koyun. Park listesi fikirleri yok etmez; yalnızca kullanıcı kanıtı oluşmadan bütçe tüketmelerini engeller.

Her akışın kabul kriterini yazın. Kullanıcı ne yapacak, başarı olarak ne görecek, yanlış veri girerse ne olacak, işlem kaydedilmezse hangi mesajı alacak? Bu kriterler olmadan üretim aracına ne kadar iyi talimat verirseniz verin, sonuç değerlendirmesi kişisel zevke kalır. Kabul kriteri bütçe için de gereklidir; düzeltme sayısını ve tekrar işi ölçmenin tek yolu beklenen davranışı önceden bilmektir.

Gizli maliyet: gereksinim değişikliği

Vibe coding ile ilk sürüm hızlı üretildiğinde ekip bazen değişikliğin de her zaman ucuz olacağını varsayar. Oysa bir form alanının eklenmesi, veri modelini, listeyi, filtreyi, bildirimleri ve raporu etkileyebilir. Bütçede “değişiklik talebi” için zaman ve test payı ayrılmalıdır. Her yeni talep için hangi kullanıcı sorununu çözdüğünü, hangi akışa dokunduğunu ve nasıl doğrulanacağını yazın.

İstemleri sürümleyin. Kullanıcı hikâyesi, veri alanı, hata davranışı, ekran değişikliği ve kabul kriterini ayrı not edin. Böylece bir düzenlemenin neden yapıldığı unutulmaz; başka geliştirici ya da ekip üyesi projeyi devraldığında karar izini görebilir. Bu belge maliyet gibi görünür, ama yeniden keşif süresini azaltır.

İnsan emeği ve uzmanlık payı

Üretim aracı ne kadar yardımcı olursa olsun, ürün yöneticisi, tasarımcı, geliştirici veya güvenlik sorumlusu emeği sıfırlanmaz. İş problemi tanımlama, test senaryosu yazma, kullanıcı görüşmesi yapma, hatayı önceliklendirme ve canlıdaki sorunu çözme insan kararına ihtiyaç duyar. Bütçe tablosunda yalnızca araç planını değil, bu rollere ayrılan saati de gösterin.

Uzmanlık ihtiyacını erken kabul etmek tasarruf sağlayabilir. Örneğin ödeme ya da yetki katmanı eklenmeden önce teknik inceleme yapmak, canlıda oluşacak açıkla uğraşmaktan daha ucuz olabilir. Aynı şekilde erişilebilirlik değerlendirmesi, ürün yayına çıktıktan sonra tüm ekranları yeniden tasarlamayı önleyebilir. Hangi uzmanlığın gerekli olduğu projenin riskiyle birlikte değerlendirilmelidir.

Kullanıcı testi maliyeti, ürün maliyetidir

Kullanıcı görüşmelerini “ekstra” saymak, yanlış özelliğe yatırım yapma riskini artırır. Beş gerçek kullanıcıyla yapılan kısa görev testi, ekibin haftalarca tasarladığı bir özelliğin anlaşılmadığını gösterebilir. Testte kullanıcıdan belirli işi yapmasını isteyin; hangi noktada durduğunu, neyi beklediğini ve işin bittiğinden nasıl emin olduğunu not edin.

Geri bildirimleri anlaşılabilirlik, işlev ve güven olarak etiketleyin. Kullanıcı ne yapacağını bilmiyorsa anlaşılabilirlik; beklediği sonuç oluşmuyorsa işlev; verinin kaydedildiğinden veya geri alınabildiğinden emin değilse güven sorunu vardır. Bütçeyi en sık tekrarlanan sorunu çözmeye ayırın. Her yoruma özellik eklemek, MVP'yi hızla kontrolsüz büyütür.

Altyapı ve sürdürme maliyeti

Prototipte göz ardı edilen alanlar üretimde düzenli maliyete dönüşür: alan adı, barındırma, veri depolama, e-posta gönderimi, hata izleme, analitik, yedekleme, destek ve güvenlik güncellemesi. Her kalem için sahibi, aylık/ değişken maliyeti ve büyüme senaryosu olsun. Araçların güncel fiyat ve kullanım koşulları değişebileceği için satın alma tarihinde resmi sayfaları kontrol edin.

Çıkış maliyetini de yazın. Uygulamayı başka ortama taşımak isterseniz kaynak kodu, veri modeli, tasarım varlıkları, ortam değişkenleri ve dokümantasyon elinizde mi? Bir araca veya tek bir kişinin hesabına bağlılık, ilk prototipi ucuz fakat geleceği pahalı hale getirebilir.

30 günlük bütçe planı

İlk hafta üç kullanıcı akışını ve kabul kriterlerini belirleyin. İkinci hafta düşük riskli prototip oluşturup on sınır durumunu test edin. Üçüncü hafta beş kullanıcıyla görev testi yapın ve en sık üç sorunu listeleyin. Dördüncü hafta pilot için gerekli altyapı, güvenlik ve bakım kalemlerini ekleyin; üretime geçmek için henüz bilinmeyenleri yazın.

Bu süreç sonunda “araç bize ne kadar tutuyor?” yerine “hangi kullanıcı kanıtı için hangi maliyeti üstleniyoruz?” sorusuna yanıt verirsiniz. Bu daha iyi bir ürün bütçesidir.

Teknik borcu ilk günden kaydedin

Prototip aşamasında bazı kararları bilinçli olarak erteleyebilirsiniz. Örneğin gelişmiş rol yönetimi, ayrıntılı izleme veya çoklu dil desteği ilk kullanıcı testinde gerekli olmayabilir. Bu erteleme görünür değilse, ekip bunu tamamlanmış iş sanabilir. Her proje için bir teknik borç listesi tutun: ertelenen konu, neden ertelendi, hangi risk oluşur, üretime geçmeden önce sahibi kim?

Liste, hızlı geliştirmeyi yavaşlatmaz; tam tersine hızın hangi koşulla güvenli olduğunu gösterir. Kullanıcı sayısı arttığında veya ödeme/veri gibi yeni kapsam eklendiğinde bu listeden hangi işlerin önce yapılacağı anlaşılır. Sürpriz maliyet, ertelenen işin unutulmasından doğar.

Kapsam değişikliğini fiyatlandırın

Yeni özellik talebi geldiğinde “kaç ekran ekleyeceğiz?” diye değil, “hangi kullanıcı akışı, veri alanı, test senaryosu ve bakım sorumluluğu değişecek?” diye bakın. Basit görünen bildirim, kullanıcı ayarı, rapor filtresi veya hesap alanı projenin farklı katmanlarını etkileyebilir. Bu etkiyi kısa notta yazmak, ekibin önceliklendirmesini güçlendirir.

Kullanıcı testinden gelmeyen özellikleri hemen bütçeye almayın. Onları park listesinde tutun ve hangi kanıt oluşursa öncelik kazanacağını belirtin. Böylece ürün, en yüksek sesle istenen değil en güçlü kullanıcı kanıtı olan yönde büyür.

Devralma tatbikatı yapın

Pilot bitmeden başka bir geliştirici veya ekip üyesine projeyi açtırın. On beş dakika içinde kodu, veri modelini, çalıştırma yöntemini ve test adımlarını bulabiliyor mu? Bulamıyorsa belge veya yapı eksiktir. Bu küçük tatbikat, üretime geçmeden sahiplik borcunu görünür yapar ve tek kişiye bağımlılığın maliyetini azaltır.

Üretim eşiği için net kriter koyun

Pilotun üretime hazır olduğunu söylemek için ekranın çalışması yetmez. Kritik kullanıcı akışları test edilmiş mi, veri ve erişim sahibi belli mi, hata anında uyarı ve geri alma yolu var mı, yeni kişi projeyi devralabiliyor mu? Bu dört soruya kanıtla evet denemiyorsa proje keşif veya pilot aşamasında kalmalıdır. Bu sınıflandırma bütçe kararını dürüst tutar.

Üretim eşiği yazılı olduğunda ekip, prototip için gereksiz altyapı kurmaz; fakat riskli özellik eklendiğinde hangi maliyetin kaçınılmaz olduğunu da bilir. Böylece hız ile sorumluluk birbirini dışlayan hedefler olmaktan çıkar.

Sonuç: hızlı başlangıcı kalıcı maliyetle karıştırmayın

Vibe coding, fikirleri denemek için güçlü bir hızlandırıcı olabilir. Bütçeyi doğru kurmak için prototip ile üretimi ayırın, MVP kapsamını sınırlayın, kullanıcı testine yatırım yapın ve teknik sahipliği görünür kılın. Böylece hızlı üretim, daha sonra pahalıya mal olan bir borç değil; doğru problemi daha erken öğrenmenin yolu olur.

Yayın öncesi uygulama denetimi

Seçilen çalışma akışını gerçek kullanıcı göreviyle deneyin, sonucu kabul kriteri ve testle karşılaştırın, sonra hata türünü kaydedin. Aynı görevi ikinci ekip üyesiyle tekrarlayın. İki kişi benzer kaliteye ulaşamıyorsa, sorun araçtan çok kapsam, kaynak veya görev tanımında olabilir.

Her ay küçük bir örneklem seçip pilot çıktıları yeniden inceleyin. Yeni veri türü, ekip rolü veya üretim gereksinimi yeni kontrol ihtiyacı yaratabilir. Bulgunun yanında sorumlu kişi ve sonraki gözden geçirme tarihini yazın. Böylece bütçe standardı yalnızca planlama anında değil proje boyunca korunur.

Bilinmeyen maliyeti sıfır kabul etmeyin

Vibe coding bütçesinde bazı kalemlerin ilk gün net olmaması doğaldır: trafik, depolama, model kullanımı, gözlemleme veya destek emeği tahmin edilemeyebilir. Bu satırları sıfır yazmak yerine aralık ve varsayım olarak gösterin. Örneğin kullanıcı sayısı belli değilse düşük, beklenen ve yüksek senaryo oluşturun; hangi kullanımın üst sınıra taşıdığını yazın. İlk faturalar geldiğinde tahminle farkı karşılaştırın ve modeli güncelleyin. Böylece bütçe belgesi bir kez hazırlanan sunum değil, ürün olgunlaştıkça daha doğru tahmin yapan çalışma aracı olur. Karar verici için belirsizliği görünür kılmak, sahte kesinlikten daha faydalıdır.