Minimum Uygulanabilir Ürün (MVP) Nedir, Nasıl Geliştirilir?

Minimum Uygulanabilir Ürün (MVP) Nedir, Nasıl Geliştirilir? sorusu, dijital ürün geliştirme süreçlerinde kaynak israfını önlemek ve pazar doğrulaması sağlamak isteyen girişimciler ile kurumsal karar vericiler için kritik bir öneme sahiptir. MVP, bir fikrin ticari ve teknik uygulanabilirliğini en düşük maliyet ve temel işlevsellik seti ile test etmeyi amaçlayan bir geliştirme stratejisidir. Bu kapsamlı rehberde, bir MVP'nin kavramsal temellerinden başlayarak, hedef kitle analizine, önceliklendirme metodolojilerine ve ölçeklenebilir bir mimari üzerinde nasıl inşa edilmesi gerektiğine dair tüm pratik adımları teknik derinlikle ele alacağız.

MVP (Minimum Uygulanabilir Ürün) Kavramının İş Dünyasındaki Yeri

MVP Nedir? (Kapsamlı Tanım ve Temel İşlev)

Minimum Uygulanabilir Ürün (MVP - Minimum Viable Product), hedef pazardaki gerçek kullanıcıların ana problemini çözmek amacıyla geliştirilen, yalnızca en temel işlevselliğe (core functionality) sahip ilk çalışan ürün sürümüdür. Yalın girişim (Lean startup) metodolojisinin merkezinde yer alan bu kavram, bir ürünün "minimum" (en az kaynak ve eforla üretilen) ile "viable" (kullanıcıya değer sunan ve kullanılabilir olan) özelliklerini dengeli bir biçimde bir araya getirir. MVP geliştirmek, sadece basit veya eksik bir ürün ortaya koymak anlamına gelmez; aksine, hedeflenen değer teklifini (value proposition) en yalın şekilde temsil eden fonksiyonel bir çözüm sunmaktır.

Yazılım mimarisi perspektifinden bakıldığında bir MVP, gelecekteki ölçeklenebilir altyapının çekirdeğini oluşturur. Kullanıcı yönetiminden veri güvenliğine kadar temel katmanları barındırırken, ana işlevi desteklemeyen tüm ikincil özellikleri (gelişmiş filtreleme araçları, detaylı raporlama modülleri, kişiselleştirilmiş tema seçenekleri vb.) ilk aşamada devre dışı bırakır. Bu stratejinin temel işlevi, geliştiricilerin ve ürün yöneticilerinin varsayımlarını gerçek kullanıcı verileriyle doğrulamak, teknik riskleri en aza indirmek ve yatırım geri dönüşünü (ROI) hızlandırmaktır.

Kavram Karmaşasını Önlemek: MVP, Prototip ve PoC Arasındaki Kritik Farklar

Ürün geliştirme süreçlerinde MVP, Prototip ve PoC (Proof of Concept / Kavram Kanıtlama) terimleri sıklıkla birbirinin yerine kullanılsa da, bu kavramların her biri farklı amaçlara, hedef kitlelere ve teknik olgunluk seviyelerine hizmet eder. PoC, belirli bir teknik fikrin veya entegrasyonun teorik olarak mümkün olup olmadığını kanıtlamak için yapılan, genellikle son kullanıcıya ulaştırılmayan dahili bir çalışmadır. Örneğin, tescilli bir yapay zeka algoritmasının bulut sunucusunda 100 milisaniyenin altında yanıt verip veremeyeceğini test etmek bir PoC çalışmasıdır.

Prototip ise ürünün görsel tasarımı, kullanıcı deneyimi (UX) akışı ve arayüz etkileşimlerini simüle eden, genellikle arkasında çalışan bir kod tabanı veya veritabanı bulunmayan statik tasarımdır. Yatırımcılara sunum yapmak veya kullanıcı testlerinde arayüzün anlaşılırlığını ölçmek için Figma gibi araçlarla hazırlanır. MVP ise hem teknik olarak çalışan bir arka plana sahiptir hem de gerçek pazar koşullarında, gerçek kullanıcılar tarafından test edilmek üzere canlıya alınır.

Kurumsal Şirketler ve Girişimler İçin MVP'nin Stratejik Önemi

Girişimler için MVP, kısıtlı finansal kaynakları ve zamanı korumanın en etkili yoludur. Erken aşama bir girişim, pazar analizi yapmadan doğrudan nihai ürünü geliştirmeye odaklandığında, nakit akışını (runway) tüketerek başarısızlık riskiyle karşı karşıya kalır. MVP sayesinde girişimler, temel hipotezlerini doğrulamak için ihtiyaç duydukları yazılım geliştirme maliyetlerini optimize eder ve gerçek kullanıcılardan aldıkları geri bildirim döngüsü (feedback loop) yardımıyla ürünü iteratif olarak şekillendirirler. Bu süreç, yatırımcılardan tohum fon (seed funding) alma aşamasında somut kullanıcı metrikleri (etkin kullanıcı sayısı, elde tutma oranı - retention) sunulabilmesini sağlar.

Büyük kurumsal şirketlerde ise MVP yaklaşımı, bürokratik karar alma süreçlerini aşmak ve inovasyon hızını artırmak amacıyla kullanılır. Kurumsal yapılarda yeni bir ürün fikrinin onaylanması, bütçelendirilmesi ve geliştirilmesi aylar, hatta yıllar alabilir. Kurumsal bir MVP projesi, şirketin ana markasından bağımsız bir "sandbox" ortamında veya alt marka altında hızlıca piyasaya sürülerek pazarın tepkisi ölçülebilir. Bu yaklaşım, büyük ölçekli sermaye yatırımı yapılmadan önce projenin ticari potansiyelini test ederek kurumsal risk yönetimini destekler.

MVP Geliştirmenin Temel Avantajları ve Risk Yönetimi

Erken Pazar Doğrulaması ile Maliyet Optimizasyonu

Yazılım projelerinin başarısız olmasının en yaygın nedenlerinden biri, pazarın ihtiyaç duymadığı bir ürünü inşa etmektir. MVP, bu riski ortadan kaldırmak için erken pazar doğrulaması sunar. Tüm özellikleri içeren eksiksiz bir SaaS platformu geliştirmek binlerce adam/saatlik çalışma ve ciddi sunucu maliyetleri gerektirirken, odaklanmış bir MVP ile bu maliyetler %70'e varan oranlarda düşürülebilir. Örneğin, karmaşık bir bulut tabanlı muhasebe yazılımı yerine, sadece e-fatura kesebilen ve bunu e-posta ile gönderen bir mikro hizmet geliştirmek çok daha az maliyetlidir.

Finansal optimizasyon sadece kod yazım aşamasıyla sınırlı değildir. MVP aşamasında, altyapı maliyetleri de (cloud infrastructure) minimum düzeyde tutulur. AWS, Google Cloud veya Microsoft Azure gibi sağlayıcıların sunduğu ücretsiz kullanım limitleri (free tier) ve sunucusuz (serverless) mimariler kullanılarak, başlangıç bütçesi etkin bir şekilde yönetilir. Bu sayede, ürünün pazar tarafından kabul görmemesi durumunda kaybedilecek sermaye miktarı tolere edilebilir seviyelerde kalır.

Ürün-Pazar Uyumunu (Product-Market Fit) Yakalama Hızı

Hız, modern teknoloji pazarlarında en belirleyici rekabet avantajlarından biridir. Ürün-pazar uyumunu (Product-market fit) yakalamak, statik bir süreç değil, pazar dinamiklerine göre sürekli uyum sağlamayı gerektiren dinamik bir yolculuktur. Tam donanımlı bir yazılımın geliştirilmesi 12 ila 18 ay sürerken, bu süre zarfında pazarın ihtiyaçları, rakip çözümler veya regülasyonlar (GDPR, KVKK, veri lokalizasyonu yasaları gibi) kökten değişebilir.

Çevik yazılım geliştirme (Agile development) metodolojileriyle desteklenen bir MVP, 6 ila 8 hafta içinde canlı yayına alınabilir. Bu hız, şirketin gerçek pazar dinamiklerini rakiplerinden çok daha önce öğrenmesini sağlar. Pazardan elde edilen veriler ışığında hızlıca yön değiştirebilen (pivot) veya mevcut özellikleri derinleştirebilen ekipler, pazarın gerçek ihtiyacını tam olarak karşılayan nihai ürüne çok daha kısa sürede ulaşır.

Erken Benimseyenlerden (Early Adopters) Stratejik Veri Toplama

Her yeni ürünün başarısı, onun ilk savunucuları olacak erken benimseyenler (early adopters) grubuna ulaşma becerisine bağlıdır. Erken benimseyenler, karşılaştıkları problemi çözmek için alternatif yollar arayan, ürünün ilk sürümlerindeki olası teknik aksaklıkları veya eksiklikleri tolere etmeye en eğilimli kullanıcı kitlesidir. MVP, bu kitleye doğrudan ulaşarak paha biçilemez bir veri toplama mekanizması kurar.

Toplanan veriler sadece anketlerden veya kullanıcı röportajlarından oluşmaz. MVP içerisine entegre edilen telemetri ve analitik araçları (Mixpanel, PostHog, Hotjar vb.) sayesinde kullanıcıların ürünle nasıl etkileşime girdiği, hangi özelliklerde takıldığı, kullanıcı kayıp oranları (churn rate) ve müşteri edinme maliyetleri (CAC) gibi kritik SaaS metrikleri doğrudan veritabanından okunabilir. Bu nicel veriler, ürünün gelecekteki yol haritasını (roadmap) kişisel tahminler yerine, somut kullanıcı davranışları üzerine inşa etmeye olanak tanır.

Adım Adım MVP Geliştirme Süreci (Uygulama Rehberi)

1. Pazar İhtiyaçlarının Analizi ve İş Fikrinin Doğrulanması

Geliştirme sürecinin ilk adımı, çözülmesi hedeflenen problemin gerçekten var olup olmadığını nesnel olarak araştırmaktır. Bu aşamada pazar araştırması ve doğrulama süreçleri yürütülür. Google Trends analizi, sektör raporları, rakip analizleri ve anahtar kelime hacimleri incelenerek pazarın büyüklüğü ve talep seviyesi ölçülür.

Fikrin doğrulanmasında sıklıkla kullanılan bir diğer yöntem "Smoke Testing" (Duman Testi) olarak adlandırılır. Henüz arkasında çalışan bir ürün bulunmayan, sadece ürünün değer teklifini ve özelliklerini açıklayan bir açılış sayfası (landing page) hazırlanır. Bu sayfaya yerleştirilen "Erken Erişim İçin Kaydol" veya "Fiyatlandırma Planlarını Gör" butonlarının tıklanma oranları, kullanıcıların projeye olan ilgisini ölçmek için güçlü bir göstergedir.

2. Hedef Kitle ve Kullanıcı Personalarının Belirlenmesi

Herkesi hedefleyen bir ürün, hiç kimseyi hedeflemiyor demektir. MVP'nin başarısı, hedeflenen kitlenin olabildiğince dar ve odaklanmış olmasına bağlıdır. Bu aşamada, ürünün çözdüğü problemi en derinden hisseden ideal müşteri profili (ICP - Ideal Customer Profile) ve kullanıcı personaları tanımlanır.

Personalar oluşturulurken yaş, cinsiyet gibi demografik verilerin ötesine geçilmeli; kullanıcının günlük iş akışı, yaşadığı teknik engeller, kullandığı mevcut yazılım araçları ve bütçe yetkinlikleri analiz edilmelidir. Örneğin, bir B2B proje yönetim yazılımı için hedef kitle "tüm proje yöneticileri" yerine, "uzaktan çalışan ve Slack kullanan 5-15 kişilik yazılım ekiplerinin yöneticileri" olarak daraltılmalıdır. Bu daraltma, MVP'nin odaklanacağı entegrasyonları ve özellikleri netleştirir.

3. Değer Teklifinin (Value Proposition) Netleştirilmesi

Değer teklifi, kullanıcının mevcut alternatifler (rakipler, Excel tabloları, manuel süreçler vb.) yerine neden sizin ürününüzü seçmesi gerektiğini açıklayan temel vaattir. MVP, bu tek ve güçlü değer teklifini doğrulamak üzere tasarlanmalıdır.

Değer teklifi oluşturulurken şu soruların yanıtları aranır:

• Ürün hangi spesifik sorunu çözüyor?

• Bu çözüm kullanıcıya nasıl bir zaman, maliyet veya verimlilik kazancı sağlıyor?

• Çözümün rakiplerden ayrışan en net ve benzersiz yönü nedir?

Bu vaat, pazarlama mesajlarından ürünün ilk ekranındaki onboarding (kullanıcı alıştırma) sürecine kadar her alanda tutarlı bir biçimde sunulmalıdır.

4. Özellik Önceliklendirmesi (MoSCoW Analizi ile Çekirdek Özelliklerin Seçimi)

MVP geliştirme sürecinin en zorlu aşamalarından biri, hangi özelliklerin ilk sürüme dahil edileceğine karar vermektir. Bu karar aşamasında MoSCoW analizi (önceliklendirme yöntemi) kullanılır. MoSCoW; özellikleri "Must Have" (Mutlaka Olmalı), "Should Have" (Olmali), "Could Have" (Olsa İyi Olur) ve "Won't Have" (Bu Sefer Olmayacak) şeklinde dört ana gruba ayırır.

MoSCoW Analizi Önceliklendirme Tablosu:
┌─────────────────────────────────┬─────────────────────────────────┐
│           MUST HAVE             │           SHOULD HAVE           │
│   (Ürünün çalışması için        │   (Önemli olan ancak MVP'yi     │
│    olmazsa olmaz çekirdek       │    geciktirmeyecek özellikler)  │
│    işlevler ve güvenlik)        │                                 │
├─────────────────────────────────┼─────────────────────────────────┤
│           COULD HAVE            │           WON'T HAVE            │
│   (Kullanıcı deneyimini artıran │   (Gelecek sürümlere bırakılan  │
│    fakat kritik olmayanlar)     │    ve kapsam dışı tutulanlar)   │
└─────────────────────────────────┴─────────────────────────────────┘

• Must Have (Mutlaka Olmalı): Bu özellikler olmadan MVP çalışamaz ve değer sunamaz. Örneğin, bir SaaS ürünü için kullanıcı kayıt/giriş sistemi, veri kaydetme mekanizması ve temel işlem arayüzü bu gruptadır.

• Should Have (Olmali): Önemli olan ancak ilk sürümde olmaması durumunda manuel iş akışlarıyla veya geçici çözümlerle idare edilebilecek özelliklerdir. Örneğin, otomatik e-posta bildirimleri yerine sistem içi basit bildirimler.

• Could Have (Olsa İyi Olur): Kullanıcı deneyimini iyileştiren ancak projenin ana değer teklifini doğrudan etkilemeyen özelliklerdir (Örn: Karanlık mod seçeneği).

• Won't Have (Bu Sefer Olmayacak): Net bir şekilde MVP kapsamının dışında bırakılan, gelecekteki büyük güncellemelerde değerlendirilecek özelliklerdir (Örn: Gelişmiş yapay zeka destekli otomatik analiz raporları).

5. Çevik (Agile) Geliştirme ve İlk Sürümün Piyasaya Sürülmesi

Özellik listesi netleştikten sonra, teknik geliştirme aşamasına geçilir. Çevik yazılım geliştirme metodolojileri (Scrum veya Kanban) tercih edilerek süreç 1-2 haftalık sprint'lere bölünür. Amaç, her sprint sonunda çalışan, test edilebilir bir yazılım parçası ortaya koymaktır.

MVP'nin teknoloji yığını (tech stack) seçilirken macera aranmamalı, ekibin en hızlı kod yazabildiği, topluluk desteği güçlü ve stabil teknolojiler (Örn: Node.js, Python, PostgreSQL, React) tercih edilmelidir. Sunucu altyapısında Docker konteynerleri ve yönetilen bulut hizmetleri (AWS ECS, Supabase, Firebase) kullanılarak operasyonel yük azaltılır. Güvenlik katmanında ise JWT tabanlı kimlik doğrulama, SSL sertifikaları ve temel veri şifreleme yöntemleri uygulanarak, MVP'nin KVKK ve GDPR standartlarına uyumlu olması sağlanır.

6. Geri Bildirim Döngüsü: Yap-Ölç-Öğren (Build-Measure-Learn) Stratejisi

MVP'nin piyasaya sürülmesi bir son değil, aksine öğrenme sürecinin başlangıcıdır. Yalın Girişim metodolojisinin kalbinde yer alan Yap-Ölç-Öğren döngüsü (Build-Measure-Learn) bu aşamada devreye girer. Ürün pazara sunulur (Yap), kullanıcıların davranışları ve geri bildirimleri analitik araçlarla izlenir (Ölç) ve elde edilen verilerden çıkarımlar yapılarak bir sonraki adım planlanır (Öğren).

Kullanıcılardan gelen geri bildirimleri toplamak için ürün içerisine doğrudan geri bildirim formları (Örn: Typeform, Hotjar anketleri) yerleştirilir. Kullanıcının ürünü terk etme noktaları (drop-off points) tespit edilerek, onboarding akışı optimize edilir. Bu döngü, ürünün sürekli olarak gerçek kullanıcı ihtiyaçlarına göre evrilmesini ve kaynakların doğru özelliklere aktarılmasını garanti altına alır.

MVP Sürecinde Kaçınılması Gereken Kritik Hatalar (Tedbirler)

Aşırı Özellik Ekleme (Feature Creep) Tuzağına Düşmek

Ürün sahiplerinin ve geliştiricilerin en sık düştüğü hatalardan biri, "şu özellik de olsun, bu özellik olmadan kullanıcılar ürünü beğenmez" düşüncesiyle sürekli yeni modüller eklemektir. "Feature Creep" (Aşırı Özellik Ekleme) olarak adlandırılan bu durum, projenin kapsamını kontrolsüz bir şekilde genişleterek teslim tarihlerinin aylarca gecikmesine ve bütçenin tükenmesine yol açar.

Bu tuzağı engellemenin yolu, MoSCoW analizinde belirlenen sınırları katı bir şekilde uygulamaktır. MVP'nin odaklanması gereken tek bir "kahraman özellik" (hero feature) olmalıdır. Eğer bu temel özellik kullanıcı problemini çözemiyorsa, eklenen diğer onlarca küçük özelliğin projeyi kurtarması mümkün değildir.

"Minimum" Kavramını Yanlış Anlayıp Kaliteden Ödün Vermek

MVP'nin "minimum" boyutu, ürünün kararsız, hatalarla dolu (buggy) ve güvensiz olması gerektiği anlamına gelmez. Birçok ekip, hızlı olmak adına güvenlik testlerini atlar, hatalı kod bloklarını canlıya alır ve kötü bir kullanıcı arayüzü sunar. Bu durum, "Viable" (Uygulanabilir/Kullanılabilir) kelimesinin göz ardı edilmesine neden olur.

Güvenlik açıkları barındıran, KVKK/GDPR uyumluluğu olmayan, kullanıcı verilerini açıkta bırakan veya sürekli çöken bir MVP, kullanıcılarda güvensizlik yaratır. İlk izlenimi kötü olan bir yazılıma kullanıcıları geri döndürmek, yeni bir kullanıcı edinmekten çok daha zordur. MVP, sınırlı sayıda özelliğe sahip olmalı ancak sahip olduğu özellikleri kararlı, güvenli ve pürüzsüz bir deneyimle sunmalıdır.

Kullanıcı Geri Bildirimlerini Görmezden Gelerek Varsayımlara Dayanmak

Bazı girişimciler, kendi ürün fikirlerine aşırı derecede aşık olurlar ve pazarın sesine kulaklarını kapatırlar. Kullanıcılardan gelen negatif geri bildirimleri "onlar ürünü henüz anlamadı" diyerek göz ardı etmek, ticari bir başarısızlığı önceden kabul etmek demektir.

MVP'den elde edilen veriler, kurucuların varsayımlarıyla çelişiyorsa, yapılması gereken şey inat etmek değil, esnek olmaktır. Eğer kullanıcılar ürünün farklı bir özelliğini daha çok kullanıyor veya bambaşka bir kullanım senaryosuna yöneliyorsa, ürün stratejisi o yöne doğru kaydırılmalıdır. Veriye dayalı karar alma kültürü, MVP sürecinin temel taşıdır.

Ölçeklenebilirlik Altyapısını Hiç Düşünmeden Kodlama Yapmak

"Nasılsa bu bir MVP, kod kalitesi ve mimari önemli değil" yaklaşımı, teknik borç (technical debt) birikimine neden olur. MVP doğrulanıp binlerce kullanıcı sisteme kaydolmaya başladığında, altyapının çökmesi veya sistemin genişletilemez durumda olması projenin büyümesini engeller.

Mimariyi ilk günden devasa mikro hizmet yapısında kurmak ne kadar hatalıysa, tamamen "spagetti kod" yazarak ölçeklenmeyi imkansız hale getirmek de o kadar hatalıdır. En dengeli yaklaşım, temiz kod (clean code) prensiplerine bağlı kalarak, modüler monolitik (modular monolith) bir mimari tercih etmektir. Bu sayede, pazar doğrulaması alındıktan sonra sistemi parçalara ayırmak ve belirli servisleri mikro hizmetlere dönüştürmek çok daha kolay olacaktır.

Piyasayı Değiştiren Başarılı MVP Örnekleri

Dropbox: Sadece Bir Video ile Pazar İhtiyacını Doğrulamak

Dropbox, yazılım geliştirmeye başlamadan önce pazar talebini doğrulamanın en yaratıcı örneklerinden birini sunmuştur. Şirketin kurucusu Drew Houston, dosya senkronizasyonu teknolojisinin arka planındaki karmaşık algoritmaları yazmanın ciddi bir zaman ve maliyet gerektireceğini biliyordu. Bu teknik zorlukları aşmak ve bütçeyi riske atmamak için son derece yalın bir yöntem tercih etti.

Houston, ürünün nasıl çalışacağını gösteren, sadece 3 dakikalık basit bir ekran kaydı videosu hazırladı. Bu videoda, bilgisayardaki bir dosyanın Dropbox klasörüne sürüklenmesiyle buluttaki diğer bilgisayarla nasıl anında senkronize olduğu animasyonlarla açıklandı. Video, teknoloji meraklılarının yoğun olarak bulunduğu topluluk platformlarında paylaşıldı. Sonuç olarak, Dropbox'ın bekleme listesindeki kullanıcı sayısı tek bir gecede 5.000'den 75.000'e yükseldi. Bu muazzam talep, ürünün kodlanması için gereken finansal desteği ve motivasyonu sağladı.

Airbnb: Temel Konaklama İhtiyacını En Yalın Haliyle Çözmek

Airbnb'nin doğuş hikayesi, tam anlamıyla bir "minimum" ve "viable" dengesidir. 2007 yılında San Francisco'da yaşayan Brian Chesky ve Joe Gebbia, kiralarını ödemekte zorlandıkları bir dönemde şehirde büyük bir tasarım konferansının düzenleneceğini öğrendiler. Otellerin tamamen dolu olduğunu fark eden ikili, evlerindeki boş odayı değerlendirmeye karar verdi.

Ürün geliştirmek için ne zamanları ne de bütçeleri vardı. Hızlıca "airbedandbreakfast.com" adında tek sayfalık basit bir web sitesi kurdular. Evlerine yerleştirdikleri üç adet şişme yatağı (airbed) ve sabah kahvaltısını (breakfast) içeren bir ilan açtılar. Bu basit teklif sayesinde konferansa katılan 3 misafir, geceliği 80 dolardan evde konakladı. Kurucular, bu süreçte sadece kira parasını çıkarmakla kalmadı; insanların otel yerine yabancıların evinde kalmaya ve bunun için internet üzerinden ödeme yapmaya istekli olduğunu bizzat deneyimleyerek doğruladı.

Zappos: Stoksuz Satış ile İş Modelini Test Etmek

Çevrimiçi ayakkabı satışı devi Zappos'un kurucusu Nick Swinmurn, insanların internetten ayakkabı satın almak isteyip istemeyeceğinden emin değildi. O dönemde yaygın olan inanış, insanların ayakkabıyı denemeden asla satın almayacağı yönündeydi. Swinmurn, devasa bir depo kurup yüz binlerce dolarlık ayakkabı stoku satın almak yerine benzersiz bir MVP yöntemi uyguladı.

Yerel ayakkabı mağazalarına giderek raflardaki ayakkabıların fotoğraflarını çekti. Bu fotoğrafları, kurduğu çok basit bir e-ticaret sitesine yükledi. Siteden bir sipariş geldiğinde, fiziksel olarak o ayakkabı mağazasına gidiyor, ayakkabıyı perakende fiyatından satın alıyor ve postaneden müşteriye gönderiyordu. Bu süreçte Zappos hiçbir kâr elde etmedi, hatta operasyonel olarak zarar etti. Ancak Swinmurn, insanların internetten ayakkabı siparişi verdiğini ve bu iş modelinin arkasında devasa bir pazar potansiyeli yattığını sıfır stok riskiyle kanıtlamış oldu.