MVP'den Ürüne Geçiş: Teknik Borçtan Ölçeklenebilir Ürüne Tam Rehber

Giriş: MVP Paradoksu ve Ürüne Geçişin Gerçeği

Minimum Viable Product (MVP) pazar testinin en etkili yöntemidir. Ancak başarılı bir MVP aslında en zor sorunun başlangıcıdır. Gerçek kullanıcılardan ilk geri bildirim aldıktan sonra MVP'den ürüne geçiş, birçok girişimi durdurur.

Araştırmalara göre, MVP aşamasından ürün olgunluğuna ulaşmaya çalışan projelerin yüzde 70'i bu geçişte başarısız olur. Bunun nedeni basit: MVP oluşturmak hızlık için tasarlanırken, ürün geliştirme güvenilirlik, ölçeklenebilirlik ve bakımlanabilirlik gerektirir.

Bu rehber, MVP'den ürüne geçişin her aşamasını, maliyet analizi ve gerçek uygulamalarıyla ele alır. Smart Maple, sağlık hizmetlerine sunulan SaaS ürünü Oplist'in bu geçişinde tecrübe kazanmıştır.

---

MVP vs Ürün: Farklılıkları Anlamak

MVP'den ürüne geçişin başlangıcında, iki aşama arasındaki fark net olmalıdır.

Kriter	MVP (L0)	Erken Ürün (L1)	Ölçeklenmiş Ürün (L3)	Kurumsal Ürün (L4)
Mimari	Monolith, tek database	Modular services, basic separation	Microservices, event-driven	Full distributed, saga patterns
Test Coverage	%0-10 (manual only)	%40-60	%75-85	%85-95
CI/CD	El ile deployment	Basic automation	Multi-env, canary deploys	Blue-green, feature flags
Monitoring	Console logs	Basic APM	Full observability	Real-time alerting, SLA tracking
Güvenlik	Hiç test	OWASP Top 10 remediation	Pentest, KVKK compliance	ISO 27001, SOC 2
Veritabanı	Single DB, no backups	Backups, basic replication	Multi-region, automatic failover	Full HA, disaster recovery
Belgeler	Hiç	Temel API docs	Comprehensive guides	Architecture decision records
Takım Boyutu	1-2	3-5	8-15	15+
Deployment Sıklığı	Haftada 1-2	Günde 5-10	Saatte 10+	Saatte 50+

Maturity seviyeleri şöyle tanımlanır: L0 MVP ürünün yaşadığını kanıtlar, L1 kullanıcı memnuniyetini korur, L2 ilk ölçekleme sinyallerini gösterir, L3 binlerce kullanıcı ve yüksek uptime sağlar, L4 ise kurumsal müşteri gereksinimlerini karşılar.

---

Geçiş Kararı: Ne Zaman Ürüne Geçmeliyiz?

Her MVP sonunda aynı soru ortaya çıkar: "Ne zaman durmalı, ürüne geçmeliyiz?" Bu sorunun cevabı veriye dayalı olmalıdır. Beş ana sinyal, geçiş kararınız için rehber olabilir.

Geçişin Beş Ana Sinyali

Product-Market Fit: Ünlü girişimci Sean Ellis, "Bu ürünü hiç bulamaysaydınız ne hissederdiniz?" sorusuyla piyasa uyumunu ölçer. Kullanıcıların yüzde 40 ve üzeri "çok hayal kırıcı olurdu" yanıtını verirse, ürün pazara uyuyor demektir. Oplist'in hastane yöneticilerinin yüzde 58'i bu yanıtı verdi.

Gelir Stabilizasyonu: MVP aşamasında 0-5,000 dolar aylık yinelenen gelir (MRR) normaldir. Geçiş kararı için en az 10,000 dolar MRR'nin sabit kalması gerekir. Oplist'in 8. ayında 15,000 dolara ulaşması, geçişe hazır olduğunun göstergesidir.

Kullanıcı Katılım Oranları: Günlük aktif kullanıcıların aylık aktif kullanıcılara oranı (DAU/MAU) 0.25 üzeri olmalıdır. Oplist'in 0.32 oranı sağlıklı katılımı göstermiştir.

Retention Eğrileri: İlk haftada kaydolan kullanıcıların dördüncü haftada hala aktif olma oranı yüzde 40 ve üzeri olmalıdır. Oplist'in yüzde 72'den yüzde 38'e düşüş eğrisi ürün uyumunu göstermektedir.

Teknik Borç Oranı: Teknik borç oran hesapla (borç ile ilgili çalışma günleri / toplam çalışma günleri) yüzde 30 üzerine çıkarsa, geçiş zorunlu hale gelir. Oplist'te 12. ayda yüzde 42 orana ulaştığında, geçiş kritik hale gelmiştir.

Geçiş Karar Matrisi

Sinyal	Ağırlık	Oplist Puanı	Durum
PMF (Sean Ellis %)	30%	58% / 40% = 1.0	Geçişe hazır
MRR Stabilizasyonu	25%	$15K / $10K = 1.0	Geçişe hazır
DAU/MAU Oranı	20%	0.32 / 0.25 = 1.0	Geçişe hazır
Retention Curve	15%	Stabil = 1.0	Geçişe hazır
Tech Debt	10%	42% / 30% = 0.6	Acil
Toplam Skor	100%	0.96	Geçiş Kritik

Skor 0.75 ve üzeri olduğunda geçişe başlayabilirsiniz. Oplist'in 0.96 puanı hemen harekete geçmesi gerektiğini göstermiştir.

---

Faz 1: Mimari Refactoring

MVP yazılırken genellikle monolitik yapı kullanılır - tüm özellikler tek bir dosya içinde yer alır. Ürüne geçişin ilk adımı, bu yapıyı modüler hale getirmektir.

Monolith'ten Modular Yapıya Geçiş

MVP aşamasında, authentication, randevu yönetimi, kullanıcı profilleri, ödemeler ve bildirimler gibi tüm işlevler birbirine karışmış tek bir kodda yer alır. Ürün mimarisi ise bu işlevleri ayrı, bağımsız hizmetler olarak organize eder: authentication hizmeti kendi kurallarıyla çalışır, randevu hizmeti randevu yönetimine odaklanır, bildirim hizmeti ise asenkron olarak çalışır.

Bu yapının faydaları büyüktür. Her hizmet bağımsız olarak test edilebilir, birinde hata olsa diğerlerine etki etmez ve ölçeklendirme daha verimli hale gelir.

Veritabanı Migrasyonu Stratejileri

Şema değişikliklerini yönetmek için versiyon kontrol sistemleri kullanılmalıdır. Her değişiklik numaralandırılmış bir adımda uygulanır. İlk adımda kullanıcı tablosu ve randevu tablosu oluşturulur. İkinci adımda notlar ve iptal nedeni sütunları eklenir. Üçüncü adımda indexler eklenerek sorgu performansı artırılır.

Bu yaklaşım, geri alma işlemini basit hale getirir ve veritabanı değişikliklerinin izlenebilir olmasını sağlar.

API Versioning

Yeni sürüme geçerken eski API'leri desteklemeye devam etmek gerekir. Endpoint'lere versiyon numarası eklenerek (v1, v2) bu sorun çözülür. Kullanıcılar istediği sürümü kullanmaya devam edebilir, zamanla yeni sürüme geçebilir.

---

Faz 2: Test ve CI/CD Altyapısı

MVP'de test neredeyse yoktur. Ürüne geçerken test coverage yüzde 40'tan yüzde 80'e çıkarılmalıdır. Test piramidi ilkesine göre çalışılmalıdır: birim testler (yüzde 60) küçük parçaları test eder, entegrasyon testleri (yüzde 30) modüller arasındaki iletişimi doğrular, uçtan uca testler (yüzde 10) kullanıcı akışlarını kontrol eder.

Test Türleri ve Kapsamı

Birim testler tek bir fonksiyonun davranışını doğrular. Örneğin, geçmiş tarihleri red eden bir tarih doğrulayıcı, gelecek tarihleri kabul eden bir doğrulayıcı, parola kurallarını denetleyen testler yazılır.

Entegrasyon testleri birden çok modülün birlikte çalışmasını kontrol eder. Kullanıcı oluşturulduğunda, randevu kaydedilebiliyor mu? Randevu kaydedilince bildirim sistemi tetikleniyor mu?

Uçtan uca testler gerçek tarayıcıda kullanıcı akışını simüle eder. Giriş yap, doktor ara, tarih seç, randevu al, başarı mesajını gör. Bu testler en yavaş ama en güvenilir olanıdır.

Sürekli Entegrasyon ve Dağıtım Pipeline'ı

Kod her pushlanıldığında otomatik olarak test edilir. Tüm testler geçerse, kod derlenir ve güvenlik taraması yapılır. Herhangi bir açıklık bulunmazsa, imaj oluşturulup hazır bekler. Üretim dalına merge olunca, bu imaj otomatik olarak test ortamına dağıtılır ve son kontroller yapılır. Sorun yoksa üretime geçer.

Bu süreç sayesinde her hafta düzinelerce dağıtım güvenle yapılabilir.

Kod Kalitesi Kontrolleri

Statik analiz araçları kod yazılırken sorunları bulur: karmaşık fonksiyonlar, tekrarlayan kod, güvenlik açıkları vb. Bu raporlar haftada izlenir ve en riskli alanlar iyileştirilir.

---

Faz 3: Performans ve Ölçeklendirme

MVP hızda ölçülür, ürün ölçeklenebilirlikte ölçülür. Binlerce kullanıcı binlerce sorgu anlamına gelir. Veritabanı ve caching tarafı düzgün yapılmazsa sistem çöker.

Veritabanı Optimizasyonu

Yavaş sorgular envanteri yapılmalıdır. Hangi sorgular 300ms üzeri sürüyor? Bunlar neden yavaş? İndeks eksik mi, join yanlış yapılmış mı?

Örneğin, hastanın randevu listesini filtrelenmiş olarak çeken sorgu, sorunlu alan olabilir. Bu sorguya index eklenerek 450ms'den 5ms'ye düşürülür. Bu 90 katlık hız artışı, sistemin ölçeklenebilmesi açısından kritiktir.

Query plan analizi yapılarak her sorgu incelenir. Hangi index'ler kullanılıyor, sıralaması verimli mi?

Caching Katmanı

Sık talep edilen veriler - kullanıcı listeleri, doktor profilleri, takvim bilgileri - bir cache'de tutulur. Istek gelirse önce cache kontrol edilir, burada bulunursa anında döndürülür. Cache'de yoksa veritabanından çekilir ve cache'e kaydedilir.

Veri güncellenince ilgili cache invalidate edilir. Bu sayede ağır sorguların tekrar tekrar çalışması önlenir.

Yük Testi

Sistem ne kadar yükü kaldırabilir? 100, 500, 1000 paralel kullanıcı? Her seviyede tepki hızı nedir, hata oranı nedir? Yük testler bu soruları yanıtlar ve bottleneck'leri bulur.

Tipik hedef: 95. yüzdelik tepki hızı 500ms altında, hata oranı yüzde 1 altında olmak.

Sistem Izleme (APM)

Üretime alındıktan sonra, sistem davranışı takip edilir. Her endpoint için ortalama tepki süresi, kullanıcı sayısı, hata oranı kayıt altına alınır. İstisnai durumlar (çöküş, yavaşlama) otomatik olarak tespit edilir ve ekip bilgilendirilir.

---

Faz 4: Güvenlik ve Uyumluluk

Ürüne geçişin en önemli taraflarından biri güvenliktir. MVP'de "security later" mantığı vardır; üründe bu olmaz.

OWASP Top 10 Güvenlik Risklerine Karşı Önlemler

Veritabanı sorguları her zaman parametreize edilmeli, kullanıcı inputu asla doğrudan sorguya konulmamalıdır. SQL injection için bu, en temel korunmadır.

Session yönetimi güvenli hale getirilir: çerezler sadece HTTPS'de gönderilir, JavaScript erişimine kapatılır, Cross-Site Request Forgery (CSRF) tokenları kontrol edilir.

Hassas veri (şifreler, tokenlar) asla log'a yazılmaz. Hata mesajları kullanıcı kafa karıştıracak detayları içermez.

Tüm dış inputlar (form verisi, URL parametreleri) doğrulanır ve kodlanır. Yetkisiz erişim engellenir: kullanıcı sadece kendi verilerini görebilir, doktor sadece kendi hastalarının randevularını görebilir.

KVKK Uyumluluğu (Türkiye GDPR'ı)

Veri saklama politikası yazılır ve uygulanır. Örneğin, loglar 90 gün tutulur, daha eski olanlar silinir. Kullanıcı tercihlerine izin verir: pazarlama e-postaları, analitik verisi kullanımı hakkında karar verebilir.

Kullanıcı profilini silme isteği alınca, ilgili tüm kişisel veri silinir ve sistem kayıtları anonim hale getirilir. Kullanıcı verilerini indirebilme hakkı sağlanır.

Dış Güvenlik Denetimi

Profesyonel penetration testing en az yılda bir kez yapılmalıdır. Güvenlik uzmanı sistemi saldırı açısından test eder, bulduğu açıklıkları rapor eder. Açıklıklar öncelik sırasına göre kapatılır.

---

Faz 5: Ekip ve Süreç Olgunlaştırması

MVP'yi 2 kişi yazabilir; ürünü 15 kişi yönetmeli. Ekibi ölçeklendirmek, teknikten daha önemlidir.

Organizasyonel Ölçeklendirme

İlk dönem 2-5 kişi aynı kodda çalışır. Herkes her şeye dokunabilir, kararlar hızlı alınır. Bu model 10 kişiye kadar ölçeklenebilir.

10+ kişi olunca squad modeline geçilir. Her squad 5-6 kişilik ekip, belirli iş alanından sorumlu. Örneğin, "Randevu Squad" randevu kitaplığı ve scheduling'den sorumlu, "Platform Squad" authentication, ödemeler ve alt yapıdan sorumlu. Squadlar paralel çalışabilir, bağımlılıklar minimum hale gelir.

İşe Alım Planı

Geçiş başlarken hemen işe almak gerekmez. 4. haftaya kadar mevcut ekip yetebilir. 6. hafta itibaren DevOps/SRE pozisyonları açılmalıdır (başlamalar 1 ay sonra). 8. hafta ürün ekibi (backend, frontend, QA) açılmalıdır.

Agile Olgunlaştırma

Başlangıçta haftalık standup yeterlidir. Birkaç ay sonra 2 haftalık sprint'ler başlatılır. Sprint planning, review ve retrospective toplantıları yapılır.

Daha büyük ekip olunca Program Increment Planning (3 ay planlaması) eklenir. Her sprint'te kısa vadeli hedefler, her PI'da uzun vadeli stratejik hedefler açık olur.

---

Maliyet Analizi: MVP'den Ürüne Geçiş Bütçesi

MVP'den ürüne geçiş ne kadar malır? İşte detaylı bir hesap:

Faz Bazlı Maliyet Dağılımı

(Baz: 3,500 dolar/ay per developer - Smart Maple standart oranı)

Faz	Süre	Ekip	Bütçe	Detay
1. Refactoring	4 hafta	2 senior backend dev	$7,000	Monolith → Services
2. CI/CD & Test	4 hafta	1 DevOps + 1 QA	$7,000	Pipeline setup, %80 coverage
3. Performance	4 hafta	1 senior backend + 1 DevOps	$7,000	Indexing, caching, load testing
4. Security	4 hafta	1 security konsültant + QA	$8,000	Pentest, OWASP, KVKK
5. Team & Process	4 hafta	2 backend + 1 frontend + HR	$9,000	Hiring, onboarding, training
Buffer (10%)	-	-	$3,850	Beklenmeyen hususlar
TOPLAM	12 hafta	8-10 person-week	$41,850

Alternatif Senaryolar

Hızlı geçiş (8 hafta) paralel çalışma ve daha fazla junior geliştirici ile 28,000-32,000 dolara indirilebilir, ancak teknik borç artabilir.

Detaylı geçiş (16 hafta) kapsamlı refactoring, harici güvenlik firması ve performance optimizasyonu ile 55,000-65,000 dolaraya çıkar, ancak pazar hızı kaybedilir.

MVP'den Ürüne Geçiş vs Sıfırdan Yazma

Sıfırdan yazılmak 24 haftaya, 84,000 dolara mâliyeti ve daha yüksek riske sebep olurken, MVP'den geçiş 12 haftaya, 42,000 dolara ve daha düşük riske malıyeti. Ayrıca, 6 ay pazarında erken hareket etme avantajı sağlar. Yüzde 50 maliyet tasarrufu ve 6 aylık zaman kazancı, bu yaklaşımı cazip hale getirir.

---

Smart Maple Geçiş Metodolojisi

Smart Maple, 12 haftada MVP'yi ürüne dönüştürmenin kanıtlanmış bir yaklaşımını geliştirdi.

5 Fazlı Sprint Planı

İlk 4 hafta: Monolitik mimarinizi modular hizmetlere dönüştürün ve GitHub Actions gibi otomatik test ve dağıtım altyapısını kurun. Yüzde 80 test kapsamına ulaşın.

Sonraki 4 hafta: Veritabanını index'ler ve Redis cache'ler ile optimize edin. Datadog gibi izleme araçlarını kurun. Sistemin 100, 500, 1000 paralel kullanıcıda nasıl davrandığını test edin.

9-10. haftalar: Güvenlik denetimi yapın, OWASP en risky 10 sorunu kapatın, KVKK uyumluluğu sağlayın.

11-12. haftalar: Yeni ekip üyelerini işe alın ve eğitin. Üretime geçişi planlayın ve başlangıç rehberleri yazın.

Oplist İçin Başarı Hikayesi

Oplist 150 aktif kullanıcı ve 15,000 dolar aylık gelir ile başlamıştır. 2 geliştirici ve manual deployment vardır. 12 haftalık geçişten sonra, 1,200 aktif kullanıcıya ve 45,000 dolar aylık gelire ulaşmıştır. Otomatlık sayesinde haftada 26 dağıtım yapılır hale gelmiş, uptime yüzde 99.95'e yükselmiştir. Ekip 2'den 10'a genişlemiştir (8 geliştirici + 1 DevOps + 1 QA).

---

Sıkça Sorulan Sorular

Ne Kadar Zaman Alır?

Tipik olarak 10-14 hafta. Paralel çalışma 8 haftaya indirebilir, ancak riskleri artar. Detaylı yol 16 haftaya çıkabilir.

MVP Kodunu Kullanabilir Miyiz?

Kısmen evet. Mimari refactoring gerekir: API'ları yeniden tasarlayın, veritabanı şemasını güncelleyin, test yazın, hata yönetimi ekleyin. Tavsiye: yüzde 20 kodu yeniden yazın, yüzde 80'ini refactor edin.

Teknik Borç Nedir?

Hız için alınan tasarım borcunun değeridir. İyi ölçüsü: fırsat maliyeti. 1 saatlik borç ilerde 2 saat harcama gerektirirse, ödenir. Sınır: yüzde 30 borç oranı kritiktir.

Database Migrasyonu Riskleri?

Yüksek risk vardır. Blue-green deploy (eski ve yeni DB paralel çalışıyor, anında switch) sıfır downtime sağlar. Shadow traffic (yeni DB test ederken eski'ye gidiyor) de güvenli bir yaklaşımdır. Oplist blue-green kullandı, 15 dakika bile downtime yaşamadı.

Microservices'a Geçmeli Miyiz?

Henüz hayır. 10,000 kullanıcının altında monolith uygun. 5,000+ DAU görülünce microservices başlaması akılcı. 500ms+ latency varsa, kritiktir.

Müşteriler İçin Downtime?

Doğru yapılırsa hayır. Blue-green deploy sıfır downtime, database migrasyonu 15-30 dakika (gece yapılır), canary deploy (yüzde 10 → 50 → 100 kullanıcıya kademeli) hata durumunda geri döner.

Güvenlik Pentest Maliyeti?

İç audit 5,000 dolar, dış pentest (3 gün) 12,000-20,000 dolar, compliance audit (KVKK) 3,000-5,000 dolar. Toplam: 20,000-25,000 dolar.

Kaç Kişi Gerekli?

İlk fazlar: 4-5 kişi (2 backend, 1 frontend, 1 QA, 1 PM). Mid fazlar: 6-7 kişi. Son fazlar: 10-12 kişi.

---

Sonuç: MVP'den Ürüne Geçişin Sanat ve Bilimi

MVP'den ürüne geçiş sadece teknik refactoring değildir. Aynı zamanda takımınızı ölçeklendirmek, kullanıcı güvenini kazanmak, pazar liderliğini korumak ve işletmeye hazır hale getirmektir.

Oplist örneği bunu gösterir: 150 kullanıcıdan 1,200'e, 15,000 dolardan 45,000 dolara ulaştı. Ekip 2'den 8'e ölçeklendi. Uptime artarken deployment hızı 100 kat arttı.

Maliyeti 40,000-45,000 dolar olsa da, sıfırdan yazılmak 80,000+ dolara mâliyeti, ayrıca 6 ay pazarınızı kaybettirir. Bu yüzden, başarılı MVP'nizi ürüne çevirmek tercih edilmeli yaklaşımdır.

---

Başarılı MVP'niz var ve ürüne geçişe hazırsınız? Smart Maple bu yolculuğunuzda rehber olabilir. Refactoring, DevOps, güvenlik danışmanlığı ve ekip eğitiminde deneyimli ekibimiz, 12 haftalık geçişi verimli hale getirebilir.

Ücretsiz bir danışmanlık sesi almak için smart-maple.com'u ziyaret edin ve ekibimizle iletişime geçin.