7 günde e-ticaret MVP'si: gerçek ödemelerle küçük bir mağazayı yayınlayın

Ne yayınlıyorsunuz (ve ne yayınlamıyorsunuz)

Haftada bitirebileceğiniz bir e-ticaret MVP'si için “gerçek ödemeler” tek bir şeyi ifade eder: gerçek bir müşteri ödeme yapabilir, siz siparişi görebilirsiniz ve tahmin yürütmeden sevkiyat yapabilirsiniz.

İlk sürümü dar tutun: tek bir ülke, tek bir para birimi ve tek bir ödeme yöntemi (genelde kartlar). Her şeyi desteklemeye çalışırsanız, haftayı sınır durumlarıyla geçirirsiniz, satışla uğraşmazsınız.

En kısa yol, parayı hareket ettirip yerine getirilmeyi tetikleyecek adımlardan sadece birkaçını yapan çok küçük bir mağazadır:

• Net fiyat ve stok durumunu gösteren bir ürün sayfası
• Miktarı değiştirebilen ve toplamları gösteren sepet
• İsim, e-posta ve gönderim adresini toplayan bir ödeme sayfası
• Onay sayfası (mümkünse bir e-posta makbuzu da)

"Tamamlandı" mükemmel bir vitrin değildir. "Tamamlandı": bir siparişi almak, başarıyla tahsil etmek ve topladığınız bilgilerle aynı gün yerine getirmektir. Ardışık 10 siparişi elle düzeltme gerektirmeden yapabiliyorsanız, çalışan bir MVP'niz var demektir.

Bu hedefi korumak için baştan hangi özelliklerin kapsam dışında olduğunu belirleyin. İstek listeleri, incelemeler, gelişmiş arama, karmaşık stok kuralları, kuponlar, birden çok ödeme yöntemi ve birden çok para birimi bu hafta ödenmenizi sağlamak için gerekli değildir.

Önce bir cihaz hedefi seçin. Alıcıların çoğu sosyal reklamdan geliyorsa, mobile-first web düşünün. İşletmelere satıyorsanız, masaüstü-öncelikli de olabilir. Her iki durumda da önce bir ekran boyutu için tasarlayın, sonra uyarlayın.

Koder.ai gibi sohbet tabanlı bir araçla inşa ediyorsanız, ekranları ve akışları üretmeden önce kapsamı yazılı olarak belirleyin. Kesin bir kapsam “bir özellik daha”nin 8. güne dönüşmesini engellemenin en kolay yoludur.

Hâlâ işleyen en küçük özellik seti

Bir e-ticaret MVP'si, bir yabancının ürünü bulup ödeme yapabildiği ve sizin e-posta-yazışma gerektirmeden siparişi yerine getirebildiğinizde "gerçek" sayılır.

Ürünlerle başlayın. Bir başlık, fiyat, bir ana görsel, kısa açıklama ve öğeyi silmeden gizleyebilmek için açık/kapalı anahtarı gerekir. Varyantlar, paketler ve karmaşık fiyatlandırmayı sonra bırakın.

Kataloğunuz basit kalabilir: bir ürün liste sayfası ve bir ürün detay sayfası. Kategori ya da stokta olma gibi temel filtreler yeterlidir; birinci haftada tam bir arama motoru inşa etmeyin.

Sepet ve ödeme sıkıcı ve öngörülebilir olmalı. Sepet; ekle, kaldır, adet değiştir ve net bir ara toplam göstermek zorunda. Kargo ve vergi için ilk etapta tek bir basit kural seçin (örneğin sabit kargo ve gerekiyorsa vergi).

Minimal uçtan uca akış genelde şunları içerir:

• Ürün listesi
• Ürün detayı
• Sepet
• Ödeme (müşteri bilgileri + gönderim adresi + özet)
• Admin alanı (ürünler ve siparişler)

Admin, MVP'lerin sıkça başarısız olduğu yerdir. Grafiklere ihtiyacınız yok. Kilitli bir giriş, ürün ekleme/düzenleme yolu ve durumu değiştirebileceğiniz bir sipariş listesi (yeni, ödendi, gönderildi, iade) yeterlidir.

Örnek: üç mum satıyorsunuz. Her birinin bir fotoğrafı ve bir fiyatı var. Alıcı iki adet ekler, sabit 5$ kargo görür, adresini girer, öder, ardından siz etiket yazdırdıktan sonra siparişi gönderildi olarak işaretlersiniz.

Koder.ai gibi vibe-coding platformu kullanıyorsanız, promptu kesin tutun: “Sadece bu sayfalar, sadece bu alanlar, hesap yok, kupon yok, istek listesi yok.”

Ödemeler: gerçek ve sıkıcı tutun

Ödemeler yaratıcı olmaktan kaçınılması gereken yerdir. Hızlıca entegre olabileceğiniz bir sağlayıcı seçin ve sadece kart ödemeleriyle başlayın. Dijital cüzdanlar, taksitli ödeme ve banka transferleri bekleyebilir.

En büyük seçim ödeme akışıdır:

• Hosted checkout genelde en hızlı ve en güvenlidir; çünkü sağlayıcı hassas UI'nın çoğunu ele alır.
• Gömülü kart formları daha şık görünebilir ama daha fazla kenar durumu ve güvenlik işi ekler.

Ödemeleri oluşturuldu, ödendi, başarısız, iptal edildi, iade edildi gibi anlaşılması kolay bir dizi durum olarak ele alın.

Uzlaşma ve destek için sadece gerekenleri saklayın: sağlayıcı ödeme ID'si, isteğe bağlı sağlayıcı müşteri/oturum ID'si, tutar, para birimi ve dahili sipariş ID'niz. Ham kart verilerini asla saklamayın ve gerçekten ihtiyaç duymuyorsanız kendi ödeme alanlarınızı icat etmeyin.

Webhooks siparişleri güvenilir kılar. Ödemeden sonra tarayıcı yönlendirmesinin "ödendi" anlamına geldiğini varsaymayın. Olayı doğrulayan bir webhook işleyici ekleyin ve eşleşen siparişi ödenmiş olarak işaretleyin.

Tekrarlamalara karşı güvenli yapın. Webhook'lar birden fazla kez teslim edilir; bu yüzden işleyiciniz idempotent olmalıdır: bir sipariş zaten ödenmişse hiçbir şey yapmamalı ve yine de başarı döndürmelidir.

Koder.ai ile hızlı inşa ediyorsanız, önce ödeme durumlarını ve minimal alanları tanımlayın, sonra webhook uç noktasını ve sipariş güncelleme mantığını üretin. Bu netlik klasik karmaşayı önler: ödenmiş müşteriler, ödenmemiş siparişler ve saatler süren manuel kontrol ihtiyacı.

7 günlük inşa için gün gün plan

Gün 1: kapsamı kilitleyin. Bir sayfalık bir spec yazın: bir alışverişçinin ne yapabileceği, bir adminin ne yapabileceği ve kapsam dışı olanlar. Bir ödeme sağlayıcı seçin. Toplamları nasıl hesaplayacağınızı kararlaştırın (şimdi vergi/kargo mı, yoksa sonra mı). Beş ana ekranı taslağını çıkarın: katalog, ürün sayfası, sepet, ödeme, ödeme sonucu.

Gün 2: kataloğu yayınlayın. Sadece ihtiyacınız olan alanlarla ürünleri saklayın: isim, fiyat, para birimi, foto, kısa açıklama, aktif bayrağı. Bir "tüm ürünler" sayfası (veya basit kategoriler) ve bir ürün detay sayfası oluşturun. Gerçek akışları test etmek için yaklaşık 10 test ürünü ekleyin.

Gün 3: sepet ve sipariş taslakları. Ekle/kaldır ve adet değişikliği uygulayın. Ödeme başladığında bir sipariş taslağı oluşturun ve fiyatları anlık görüntü olarak kaydedin ki sonradan ürün düzenlemeleri eski siparişleri değiştirmesin. Müşteri e-posta ve gönderim adresini erken yakalayın.

Gün 4: test modunda ödemeler. Ödeme oluşturmayı checkoute bağlayın. Başarılı, iptal edilmiş ve başarısız ödemeleri ele alın. Ödeme durumunu siparişte kaydedin. Sipariş numarası ve sonraki adımları gösteren net bir onay sayfası gösterin.

Gün 5: yerine getirme için temel admin. Admini küçük tutun: ürün oluştur/düzenle/devre dışı bırak, durum güncellemeleri (paid, packed, shipped, refunded) olan bir sipariş listesi ve göndermek için gerekenleri gösteren basit bir "siparişi gör" sayfası.

Gün 6: dağıtım ve güvenlik. Ayrı staging ve production ortamları kurun, logları açın ve test kartlarıyla tüm akışı prova edin. Geri alma planını ihtiyaç duymadan önce yazın.

Gün 7: canlıya geçin (küçük, kontrollü). Gerçek düşük tutarlı bir satın alma ile son kontrolü yapın, e-posta/makbuzları onaylayın, sonra mağazayı önce küçük bir kitleye açın. Koder.ai kullanıyorsanız, checkout bozulursa hızlı geri dönmek için her büyük değişiklikten önce snapshot alın.

Karışık siparişlerden kaçınmak için saklamanız gereken veriler

Bir hafta içindeki mağaza, sipariş netliğine bağlıdır. Birisi ödediğinde hızlıca cevap verebilmelisiniz: ne satın aldılar, nereye gönderilecek ve mevcut durum nedir?

Küçük, sıkıcı bir veri modeliyle başlayın. Bu beş kayıt neredeyse her şeyi kapsar:

• Product: id, başlık, fiyat, para birimi, aktif
• Customer: id, e-posta, isim (opsiyonel)
• Order: id, customer_id (veya e-posta), gönderim adresi alanları, durum, toplamlar snapshot'ı, created_at
• OrderItem: order_id, product_id, title_snapshot, unit_price_snapshot, quantity
• Payment: order_id, provider, provider_payment_id, amount, currency, status, raw_event_id

Adresleri minimal tutun ki ödeme hızlı olsun. Genelde sadece isim, satır1, şehir, posta kodu ve ülke yeterlidir. Telefon taşıyıcı gerektiriyorsa opsiyonel olabilir.

Toplamları satın alma anında snapshot olarak kaydedin. Daha sonra Product tablosundan toplamları yeniden hesaplamayın. Fiyatlar değişir, kargo oranları ayarlanır ve "müşteri X ödedi ama sipariş şimdi Y diyor" gibi uyuşmazlıklar çıkar. Her öğe için birim fiyatı, ayrıca sipariş ara toplamı, kargo, vergi (sıfır olsa bile) ve genel toplamı saklayın.

Durumları yerine getirmeye uygun açık terimlerle kullanın, ödeme sağlayıcısının jargonunu değil: new, paid, packed, shipped, canceled. İade gerçek destekleniyorsa refunded ekleyin.

Ödeme güncellemelerinde idempotency planlayın. Aynı webhook iki kez veya sıra dışı gelebilir. Sağlayıcıdan benzersiz bir olay ID'si saklayın ve çoğaltmaları yok sayın.

Örnek: bir webhook ödemeyi "succeeded" olarak iki kez işaretliyor. Sisteminiz iki gönderim oluşturup iki onay e-postası göndermemeli. Eğer Koder.ai üzerinde Go backend ve PostgreSQL ile inşa ediyorsanız, (provider, raw_event_id) üzerinde benzersiz bir kısıtlama ve durum güncellemesi etrafında bir transaction genelde yeterlidir.

Temel admin: yalnızca siparişleri yerine getirmeye yarayan

Admin bir "gösterge tablosu" değil. Hızlıca üç soruya cevap veren küçük bir arka oda olmalıdır: ne satılıyor, ne ödendi ve ne gönderilecek.

Tek bir admin girişi ile başlayın. Bir rol yeterli. Güçlü bir parola, temel rate limiting ve kısa oturum zaman aşımı kullanın. Bu hafta personel yönetimi ve izinleri atlayın. İkinci bir kişinin yardım etmesi gerekiyorsa, erişimi kasıtlı paylaşın ve sonra parolayı değiştirin.

Ürün yönetimini basit tutun: oluştur/düzenle/ana görseli yükle, fiyat belirle, kullanılabilirliği değiştir. Stok sayıları yoksa bunları oluşturmayın. Genelde stokta/stoğun dışında anahtarı aşırı satışları önler.

Sipariş görünümünüz paketleme fişi gibi okunmalı. Sipariş ID veya müşteri e-postasıyla aramayı kolay yapın, sonra gösterin:

• Müşteri adı, e-posta, gönderim adresi
• Ürünler, miktarlar ve nihai toplamlar (kargo ve vergi dahil)
• Ödeme durumu (paid, failed, refunded)
• Yerine getirme durumu (new, packed, shipped)
• Zaman damgaları ve kısa bir dahili not

Durum eylemlerini iki düğme ile sınırlayın: “Mark packed” ve “Mark shipped”. Gönderildi olarak işaretlediğinizde isteğe bağlı olarak bir takip notu saklayın (taşıyıcı + takip kodu veya “Yerel teslim alma ayarlandı”). Otomatik e-postalar yavaşlatacaksa bu hafta bekleyebilir.

CSV dışa aktarımı opsiyoneldir. Yalnızca hafta birde kullanacağınızı biliyorsanız ekleyin.

Koder.ai gibi bir araç kullanıyorsanız, admini aynı uygulamada tutun, ancak korumalı bir rotanın arkasına koyup geçerli bir oturum gerektirin.

İlk başarılı ödemeyi adım adım gerçekleştirme

Test modunda başlayın. Hedefiniz "bir ödeme sayfası" değil; bir siparişin ödenip kaydedilip yerine getirilmeye hazır olmasıdır.

Bir kuralınızı katı tutun: ham kart bilgilerini sunucunuzda saklamayın. Hassas verinin doğrudan ödeme sağlayıcısına gitmesi için hosted checkout veya istemci tarafı tokenizasyonu kullanın.

İlk ödenmiş siparişin yolu

1. Sunucuda test ürünü ve fiyatı oluşturun. Checkout fiyatları tarayıcıdan değil veritabanınızdan çekmeli.
2. Test modunda bir checkout oturumu başlatın. Backend ödeme oturumunu oluşturur ve yalnızca istemcinin yönlendirilmesi için gerekeni döndürür.
3. Çift tıklamaya karşı koruma. Pay düğmesini ilk tıklamadan sonra devre dışı bırakın. Sunucu tarafı idempotency anahtarı (örneğin sepet ID'si + kısa zaman penceresi) kullanarak tekrarların aynı oturumu döndürmesini sağlayın.
4. Ödemeyi sunucuda doğrulayın. Sağlayıcı webhook'unu gerçek kaynak olarak kabul edin. Olayı doğrulamadan ve beklenen tutar/para birimiyle eşleşmediği sürece siparişi ödenmiş saymayın.
5. Başarısız yolları test edin. Başarısız ödeme, iptal edilmiş checkout ve süresi dolan oturum çalıştırın. Her biri gizemli bir durumda değil, net bir sipariş durumunda bitmeli.

Hataları düzeltmeyi kolaylaştırın

Ödeme hatalarını işlem yapılabilir bağlamla loglayın: sipariş ID, oturum ID, müşteri e-postası (varsa), beklenen toplam, sağlayıcı hata kodu ve "Tutar uyuşmazlığı" veya "Webhook imza hatası" gibi kısa bir mesaj.

Örnek: müşteri iki kupa almaya çalışıyor. Sunucunuz $24 + kargo hesaplıyor, oturumu oluşturuyor ve siparişi beklemede olarak kaydediyor. Müşteri sayfayı kapatırsa sipariş iptal oluyor. Öderse webhook onu ödenmiş yapıyor ve güvenle yerine getirebiliyorsunuz.

Gerçekçi takip edilebilen bir dağıtım iş akışı

Bir haftanız olduğunda dağıtımlar sessizce checkout'u bozan şey haline gelebilir. Amaç şatafatsız DevOps değil. Amaç sürprizleri azaltan ve kaçış kapağı veren tekrarlanabilir bir rutin.

İki ortam kurun: staging ve production. Staging mümkün olduğunca production'a benzeyin: aynı ayarlar, aynı şablonlar, aynı vergi/kargo kuralları ama ödemeler test modunda olsun. Son kontrolleri stagingde yapın, sonra aynı build'i production'a terfi ettirin.

Sürüm numaralandırmalı yayın kullanın. Sadece v1, v2, v3 bile olsa her sürümü etiketleyin ve önceki sürümü hazır tutun. Rollback tek bir eylem olmalı: önceki build'e geri dönmek veya bir snapshot geri yüklemek. Platformunuz snapshot ve rollback destekliyorsa (Koder.ai destekliyorsa), her prod yayından önce snapshot almak alışkanlığınız olsun.

Veritabanı migration'larını MVP haftasında riskli kabul edin. Geriye uyumlu değişiklikleri tercih edin: yeni tablolar veya sütunlar ekleyin, yeniden adlandırma veya silme yapmayın; yeni sürüm kararlı olana kadar eski kod yollarını çalışır tutun. Veri doldurma gerekiyorsa bunu bir istek içinde değil, ayrı bir iş olarak yapın.

Gizli anahtarları repoya koymayın. API anahtarları, webhook imza sırları, veritabanı URL'leri ve admin parolaları için environment variables veya bir secret manager kullanın.

Yayın kontrol listesi:

• Stagingde test kartı ve webhook olayı ile uçtan uca checkout'un çalıştığını doğrulayın
• Migration'ları önce stagingde sonra productionda çalıştırın ve sipariş oluşturmanın hala çalıştığını doğrulayın
• E-postaları (sipariş onayı, başarısız ödeme) gönderip doğru göründüğünü kontrol edin
• Bir ön sürüm snapshot'ı alın ve sürüm numarasını not edin
• Hızlı ikinci bir gözden geçirme yapın: bir kişi gönderir, diğeri listeyi kontrol eder

7 günlük MVP'yi yavaşlatan yaygın tuzaklar

En hızlı şekilde hedefi kaçırmanın yolu para akışını gizlice bozan "güzel" özellikler inşa etmektir. Amaç ödeme alan, güvenilir sipariş yaratan ve yerine getirmeyi sağlayan bir mağazadır.

Yaygın hata: tarayıcıya nihai fiyatı bırakmak. Toplamlar, indirimler veya kargo istemci tarafında hesaplanırsa biri yanlış tutarı ödeyecektir. Sunucu tek gerçek kaynak olsun: ürün ID'lerinden ve miktarlardan siparişi yeniden oluşturun, sonra ödemeyi oluştururken toplamları tekrar hesaplayın.

Kargo ve vergi kuralları da zaman yiyebilir. Ekipler talep yokken her ülkeyi ve sınır durumunu desteklemeye çalışarak günler kaybeder. Birinci hafta için bir basit kural seçin ve ona bağlı kalın.

Ödemeler checkout'ta "çalışıyor" görünse de işler webhooks eksikse başarısız olur. Müşteri öder ama veritabanınız siparişi ödenmiş olarak işaretlemezse yerine getirme bekler. Webhook işleme zorunlu kabul edin.

Dikkat edilecek beş tuzak:

• İstemci tarafı toplamlarına güvenmek yerine sunucuda yeniden hesaplama yapmamak
• Talep olmadan karmaşık kargo ve vergi tabloları oluşturmak
• Yalnızca "ödeme başarılı" yönlendirmelerine güvenip webhook'ları atlamak
• Net bir sipariş onay mesajı veya e-postası unutmak
• Geri dönüş yolu olmadan doğrudan production'a dağıtmak

Örnek: müşteri ödemeyi tamamlar, sonra sekmeyi kapatır. Webhook yoksa müşteri başarısız olduğunu varsayar, tekrar dener ve siz iki kez ücretlendirmeyle karşılaşabilirsiniz.

Koder.ai ile inşa ediyorsanız, anlık görüntüleri ve rollback'i rutininizin bir parçası yapın: küçük değişiklikler gönderin, bilinen iyi bir sürümü tutun ve bir şey bozulursa hızlıca kurtarın.

Canlı ödemeleri açmadan önce hızlı kontroller

Bunları önce stagingde yapın, sonra canlıya geçmeden hemen önce tekrarlayın. Amaç basit: bir müşteri bir kez ödesin, siz bir kez kaydedin ve yerine getirebilin.

Alışverişçi yoluyla başlayın. Bir ürünü sepete ekleyin, ödeme tamamlayın ve net bir başarı sayfasına ulaştığınızdan emin olun. Adminde doğru toplamlarla ödenmiş siparişi görebildiğinizi onaylayın.

Sonra webhook'ları zorlu şekilde test edin: gecikmeler ve tekrarlar. Webhook'lar geç gelebilir, iki kez gelebilir veya sıra dışı gelebilir. Sipariş güncelleme mantığınız idempotent olmalı ki tekrarlar asla çift sipariş yaratmasın.

Ön lansman kontrol listesi:

• Uçtan uca test siparişi verin ve adminde işlem/ödeme ID'sinin kaydedildiğini doğrulayın
• Aynı webhook olayını yeniden gönderin ve hiçbir şeyin kopya oluşturmadığını doğrulayın
• Bir ürünü devre dışı bırakın ve artık satın alınamadığını doğrulayın
• Adminde bir siparişi statüler arasında (new -> paid -> shipped) ilerletin ve dahili not ekleyin
• Küçük bir değişiklik dağıtın ve dakikalar içinde geri alın; sipariş verilerini kaybetmemelisiniz

Duyuru yapmadan önce bir gerçek canlı tahsilat yapın. Gerçek bir kart, küçük bir miktar ve kendi gönderim adresinizi kullanın. Siparişin tam olarak bir kez, net bir zaman damgası ve durumla göründüğünden emin olun.

Koder.ai kullanıyorsanız, bunu snapshotlarla provayla: dağıt, sipariş ver, geri al, mevcut siparişlerin hala doğru şekilde yüklendiğini doğrula.

Örnek senaryo: bu hafta gönderebilecek küçük bir mağaza

12 paket kahve satan küçük bir kavurucu düşünün. Abonelik, incelemeler veya sadakat programına ihtiyacı yok. Gerçek para alan ve yerine getirilebilir temiz siparişler yaratan basit bir mağaza istiyor.

2. günde katalog yeterli olur: her ürün net bir foto, fiyat ve kısa açıklama (kavurma seviyesi, tat notları, paket boyutu). Seçenekleri minimal tutun: ürün başına bir boyut ve bir gönderim seçeneği (örneğin tek bir ülkede sabit ücreti).

3. günde checkout tek işi yapmalı: gönderim bilgilerini topla, kartla tahsil et ve müşterinin ekran görüntüsü alabileceği bir onay sayfası göster. Bir sipariş ID'si ve kısa özet (ürünler, toplam, gönderim adresi) gösterin. Müşteri destek için e-posta atarsa, bu sipariş ID'si en hızlı arama yoludur.

4. günde admin kasıtlı olarak sade kalır. Kavurucu giriş yapar, yeni siparişleri görür ve siparişleri paid, packed, shipped olarak ilerletir. Takip bilgisi daha sonra gelebilir. İlk haftada "Posta ile gönderildi, etiket 15:10'da yazdırıldı" gibi bir not genelde yeterlidir.

Bu aynı zamanda Koder.ai gibi sohbet-öncelikli oluşturucularla iyi çalışan bir kapsam: az sayıda ekran, az sayıda tablo ve net iş akışı.

2. hafta için beklemeye değer fikirler: indirim kodları, daha iyi arama, stok sayıları ve daha fazla otomatik e-posta. Gerçek siparişler size neyin önemli olduğunu gösterecek; ondan sonra ekleyin.

MVP yayına girdikten sonra sonraki adımlar

İlk haftayı yayınlanmış olarak bir öğrenme sprinti gibi değerlendirin. Gerçek siparişleri sistemden geçirip en büyük sürtünmeyi kanıtlayarak kaldırın.

Küçük bir pilotla başlayın: arkadaşlardan, iş arkadaşlarından veya doğrudan mesaj atabileceğiniz küçük bir kitleden 10 ücretli sipariş hedefleyin. Her kişiye nerede tereddüt ettiklerini sorun. Düşüşleri basit bir tablodaki adımlarla takip edin: ürün sayfası -> sepete ekleme -> ödeme başlatıldı -> ödeme başarılı.

Pilot sonrası sadece bir değişiklik yapın. En iyi erken iyileştirmeler genelde basittir: daha net kargo maliyetleri, daha iyi ürün fotoğrafları, daha az ödeme alanı. Notlarınızdaki bir sonraki en büyük engeli seçin, düzeltin ve küçük bir partiyle tekrar deneyin.

Müşteri desteği de eksik olanı hızlıca gösterir. Sık gelen sorular için kısa cevaplar saklayın: siparişim nerede, iptal edebilir miyim, ödeme neden başarısız oldu, kargo ne kadar ve ne zaman gelir, adresi değiştirebilir misiniz.

Checkout'u riske atmadan hızlı iterasyon yapmak isterseniz, Koder.ai sohbetten sonraki sürümü üretmenize ve snapshot/rollback ile değişiklikleri güvenli şekilde test etmenize yardımcı olabilir.