Yapay zeka ile SaaS yapmak: ilk MVP’yi çıkarma rehberi

Yapay zeka ile SaaS yapmak bugün gerçekten mümkün: Claude Code ya da Codex gibi bir kodlama ajanı giriş, abonelik, panel ve API’yi günler içinde yazabilir. Ama işe yarayan bir MVP için ajana “bana SaaS yap” demek yetmez; tek bir ana akışa indirgenmiş bir kapsam, ajanın her oturumda okuduğu yazılı bir spec ve para ile veri izolasyonu gibi kritik yollarda testler gerekir. Bu yazıda kapsamdan deploy’a kadar izlediğim yolu adım adım anlatıyorum.

Hedefim kod bilmeyen ya da az bilen birinin de takip edebileceği bir rehber. Vibe coding ile prototip çıkarmak kolay; zor olan, birinin kredi kartını girdiği bir ürünü ayakta tutmak. O yüzden hızlı ilerleyeceğimiz yerleri ve yavaşlamamız gereken yerleri ayrı ayrı işaretliyorum.

1. Kapsamı tek bir ana akışa indir

MVP’ler genelde kod yüzünden değil, kapsam yüzünden batar. Ajan her istediğini yazar; sorun, yazdırdığın her özelliğin test edilmesi, bakımı ve hatası olmasıdır.

Başlamadan bir cümle yaz: “Kullanıcı ___ yapar ve karşılığında ___ alır.” Örneğin: “Bir ajans müşterisinin sosyal medya gönderilerini yükler, müşteri tek bir bağlantıdan onaylar.” Bu cümlenin dışında kalan her şey ikinci sürüme gider.

İlk sürümde genelde şunlar yeterli:

• Kayıt, giriş, şifre sıfırlama
• Bir organizasyon (kiracı) ve davet edilen üyeler
• Tek bir ana akış (yukarıdaki cümle)
• Tek bir ücretli plan, aylık abonelik
• Basit bir ayarlar sayfası ve faturalandırma portalına bağlantı

Bildirim merkezi, rol matrisi, çoklu dil, mobil uygulama, yönetici paneli… Hepsi sonra. Müşteri ana akışı için para ödüyorsa gerisini zaten söyler.

2. Ajanın uyacağı yazılı bir spec hazırla

Ajanlar konuşmadan konuşmaya hafıza taşımaz. Claude Code her oturumda proje kökündeki CLAUDE.md dosyasını, Codex ve birçok başka ajan AGENTS.md dosyasını okur. Kararlarını buraya yazarsan her yeni oturum aynı kurallarla başlar. İkisini de kullanacaksan içeriği tek dosyada tutup diğerinden ona yönlendirebilirsin.

İşe yarayan bir spec kısa ve somut olur:

# Proje: OnayLink (MVP)

## Ürün
Ajanslar gönderi yükler, müşteri tek bağlantıdan onaylar ya da yorum yazar.

## Yığın
- Next.js (App Router, TypeScript), Tailwind
- Supabase: Postgres, Auth, Storage
- Stripe: tek plan, aylık abonelik, Checkout + Customer Portal
- Testler: Vitest (birim), Playwright (uçtan uca)

## Kurallar
- Her tabloda organization_id var; RLS her tabloda açık.
- Abonelik durumu yalnızca Stripe webhook'undan güncellenir.
- Veritabanı değişiklikleri yalnızca migration dosyasıyla yapılır.
- Gizli anahtarlar .env.local'da; koda ve loglara yazılmaz.
- Yeni paket eklemeden önce sor.
- Her işin sonunda: pnpm lint && pnpm test

## Kapsam dışı (şimdilik)
Roller, çoklu dil, mobil, yönetici paneli.

“Kapsam dışı” bölümü önemli. Ajanlar yardımsever olmaya çalışır ve sormadığın şeyleri ekler; yazılı bir sınır bunu belirgin şekilde azaltır.

3. Yığını seç: sıkıcı olanı

Yapay zeka ile çalışırken en iyi yığın, ajanın en çok örnek gördüğü yığındır. Benim bu tür MVP’ler için önerim:

• Next.js + TypeScript: Ön yüz ve API aynı projede. TypeScript, ajanın yaptığı hataların bir kısmını derleme anında yakalar.
• PostgreSQL (Supabase ya da başka bir yönetilen Postgres): İlişkisel veri, satır düzeyi güvenlik (RLS) ve migration desteği. Supabase kimlik doğrulama ve dosya depolamayı da aynı yerde verir.
• Hazır kimlik doğrulama: Supabase Auth, Auth.js ya da Clerk gibi bir çözüm. Şifre saklamayı ve oturum yönetimini ajana sıfırdan yazdırma.
• Stripe abonelikleri: Checkout ödeme sayfası, Customer Portal da plan değişikliği ve iptal için. Kart formunu kendin yazmazsın.
• Vercel ya da benzeri bir platform: Git’e push ettiğinde deploy eder, her dal için önizleme adresi verir.

Kurulum için ihtiyacın olanlar: Node.js (LTS), pnpm, Git, bir GitHub hesabı, Supabase CLI, Stripe CLI ve bir kodlama ajanı (claude ya da codex).

pnpm create next-app@latest onaylink --typescript --tailwind --app
cd onaylink
git init && git add -A && git commit -m "chore: boş proje"

Spec dosyasını bu klasörün köküne koy ve onu da commit et.

4. İlk prompt: önce plan, sonra kod

İlk mesajda kod istemiyorum; plan istiyorum. Planı okuyup düzeltmek, yanlış yazılmış 40 dosyayı geri almaktan çok daha ucuz.

CLAUDE.md dosyasını oku. Henüz kod yazma.
Bu MVP için bir uygulama planı çıkar:
1. Veritabanı tabloları (alanlar, ilişkiler, RLS politikaları)
2. Sayfalar ve API rotaları
3. Stripe akışı (hangi webhook olayları, abonelik durumu nerede tutulur)
4. Sırayla 6–8 küçük adım; her adımın sonunda neyin test edileceği
Belirsiz bulduğun noktaları en sonda soru olarak listele.

Planı oku, sorulara cevap ver, gerekirse spec’i güncelle. Sonra adımları tek tek yaptır:

Planın 1. adımını uygula: organizations, memberships ve projects tabloları
için migration yaz, RLS politikalarını ekle. Bittiğinde migration'ı yerel
veritabanına uygula, iki farklı kullanıcıyla birbirinin verisini
göremediğini gösteren bir test yaz ve çalıştır. Sonra dur.

“Sonra dur” kısmı bilinçli. Her adımdan sonra diff’e bakıp commit atıyorum; böylece ajan yanlış yöne saptığında geri dönülecek temiz bir nokta oluyor.

5. Çok kiracılı veri izolasyonu: en tehlikeli yer

SaaS’ta en kötü hata “Müşteri A, Müşteri B’nin verisini gördü” hatasıdır. Ajanın yazdığı kod genelde çalışır görünür, çünkü geliştirirken tek kullanıcıyla deniyorsun. Sorun ikinci müşteri geldiğinde çıkar.

Kurallarım:

• Her tabloda organization_id. İstisna yok; alt tablolarda da.
• Filtreyi veritabanına bırak. Supabase/Postgres’te RLS’i her tabloda aç ve politikayı kullanıcının üyesi olduğu organizasyonlara göre yaz. Uygulama kodundaki where organization_id = ... filtresi tek başına yetmez; ajan yeni bir sorgu yazarken onu unutabilir.
• Service role anahtarı yalnızca sunucuda. Bu anahtar RLS’i atlar. Tarayıcıya giden hiçbir koda girmemeli; Next.js’te NEXT_PUBLIC_ önekli bir değişkene asla koyma.
• İki kullanıcıyla test. İki ayrı organizasyon oluştur, birinin oturumuyla diğerinin kaydını ID’sini bilerek çekmeye çalış. Bu test otomatik olmalı ve her değişiklikte çalışmalı.

Ajana açıkça şunu sor: “Bu projede RLS’i atlayan her yeri listele.” Cevap service role kullanan sunucu kodu ve webhook’lar olmalı; fazlası varsa nedenini sor.

6. Migration’lar: veritabanını elle değiştirme

Ajan bir tabloya sütun eklemek istediğinde bunu bir migration dosyasıyla yapmalı, panelden elle değil. Supabase CLI ile akış şöyle:

supabase start                      # yerel Postgres (Docker gerekir)
supabase migration new add_projects # boş migration dosyası
supabase db reset                   # tüm migration'ları sıfırdan uygula
supabase db push                    # uzak veritabanına uygula

db reset komutunu düzenli çalıştır: migration’lar sıfırdan sorunsuz uygulanmıyorsa canlıda da sorun çıkar. Canlıya geçtikten sonra ajanın yazdığı her migration’ı oku. DROP COLUMN, DROP TABLE, WHERE’siz UPDATE ya da büyük bir tabloya kilitleyen bir index görürsen dur ve nedenini sor. Veri silen bir migration geri alınamaz.

7. Testleri parayla ilgili yollara yaz

Her şeye test yazdırmana gerek yok; MVP’de zaman kısıtlı. Ama şu yollar test edilmeden canlıya çıkmamalı:

1. Kayıt → organizasyon oluşturma → ana akış. Playwright ile uçtan uca.
2. Stripe webhook’ları. checkout.session.completed, customer.subscription.updated, customer.subscription.deleted ve invoice.payment_failed olaylarında abonelik durumu doğru güncelleniyor mu?
3. Ödemesi olmayanın erişimi. Abonelik iptal edildiğinde ya da ödeme başarısız olduğunda ücretli özellik gerçekten kapanıyor mu?
4. Veri izolasyonu. Yukarıdaki iki kullanıcı testi.

Stripe webhook’larını yerelde böyle denersin:

stripe login
stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger checkout.session.completed

Ajana verilecek prompt:

Stripe webhook rotasını incele. İmza doğrulaması yapılıyor mu, aynı olay
iki kez gelirse ne oluyor (idempotency), abonelik durumu hangi tabloda?
Bu dört olay için test yaz: checkout.session.completed,
customer.subscription.updated, customer.subscription.deleted,
invoice.payment_failed. Testleri çalıştır ve sonucu göster.

Sık görülen hata: ajan, Stripe’ın kullanıcıyı geri gönderdiği “başarılı” sayfasında aboneliği aktif eder. O sayfanın adresini herkes elle açabilir. Durum yalnızca imzası doğrulanmış webhook’tan değişmeli.

8. Deploy ve izleme

Vercel gibi bir platformda akış basit: depoyu GitHub’a push et, projeyi platforma bağla, ortam değişkenlerini panelden gir. Her pull request kendi önizleme adresini alır; canlıya çıkmadan orada dene.

Canlıya çıkmadan önce kontrol listem:

• Ortam değişkenleri canlı ortamda girili; Stripe canlı anahtarları ile test anahtarları karışmamış
• Stripe panelinde canlı webhook uç noktası tanımlı, imza sırrı ortam değişkeninde
• Migration’lar canlı veritabanına uygulanmış
• Supabase Auth’ta yönlendirme adresleri canlı alan adına göre ayarlı
• Veritabanı yedeği açık

İzleme için Sentry gibi bir hata takip servisi ekle; kullanıcı “çalışmıyor” diye yazmadan hatayı gör. Ajana şunu söylemen yeterli: “Sentry’yi Next.js projesine ekle, sunucu ve istemci hatalarını yakalasın, kullanıcı e-postasını ve gizli değerleri olaylara ekleme.” Bir de basit bir çalışma süresi izleyicisi (uptime check) kur.

Yapay zekanın sık yaptığı hatalar

• Var olmayan API’ler uydurmak. Özellikle kütüphanelerin yeni sürümlerinde. Derleme ya da test kırılınca hatayı olduğu gibi ajana ver ve resmi dokümana bakmasını iste.
• Testi geçirmek için testi değiştirmek. Diff’te test dosyasının değiştiğini görürsen nedenini sor.
• Gereksiz paket eklemek. Spec’teki “yeni paket eklemeden önce sor” kuralı burada işe yarar.
• Hataları sessizce yutmak. catch {} blokları ödeme hatalarını görünmez yapar.
• İstemcide yetki kontrolü. Butonu gizlemek güvenlik değildir; kontrol sunucuda ve veritabanında olmalı.
• Kapsamı genişletmek. “Bunu da ekledim” diye gelen özellikleri geri al ya da ayrı bir dala taşı.
• Uzun oturumlarda bağlamı kaybetmek. Konuşma uzadıkça ajan erken verilen kararları unutur. Her adım için yeni oturum aç; kalıcı kararlar zaten spec’te. Bağlam penceresi dolmadan oturumu kapatmak hem kaliteyi hem token maliyetini korur.

Güvenlik: kısaca ama ciddi

• Gizli anahtarlar .env.local’da. Bu dosyanın .gitignore’da olduğunu kontrol et. Depoya bir kez giren anahtarı sil ve yenisini üret; geçmişten silmek yetmez.
• API anahtarlarını sohbete yapıştırma. Ajanın anahtarı görmesine gerek yok; değişkenin adını bilmesi yeter.
• Ajanın çalıştırdığı komutları oku. Özellikle rm, git push --force, veritabanı komutları ve curl … | sh. Otomatik onayı yalnızca okuma ve test gibi güvenli işlemlere ver.
• Canlı veritabanına ajanla bağlanma. Ajan yerel ya da test veritabanında çalışsın.
• Girdi doğrulaması sunucuda. Zod gibi bir şema kütüphanesiyle her API girdisini doğrulat.
• Bağımlılıkları denetle. pnpm audit çıktısını ara ara ajana ver.

Ne zaman bir insan geliştirici getirmeli?

Şu noktalardan birine geldiysen deneyimli bir geliştiriciye birkaç saatlik bir inceleme ısmarlamak mantıklı:

• İlk gerçek ödemeyi almadan önce (webhook’lar, abonelik durumu, iade)
• Müşteri verisi kişisel veri içeriyorsa (KVKK/GDPR yükümlülükleri)
• Kurumsal bir müşteri güvenlik soru formu gönderdiğinde
• Aynı hatayı ajanla üç oturumdur çözemiyorsan
• Performans sorunları başladığında (yavaş sorgular, eksik index’ler)

İncelemeyi kolaylaştırmak için spec’i, migration klasörünü ve test çıktılarını hazır tut. Ajanla yazılmış ama düzenli commit’lenmiş, testli bir proje, bir geliştiricinin hızla anlayabileceği bir projedir.

Bunu AgentVera ile nasıl yapıyorum

Yukarıdaki her şey tek bir terminalle de yapılır. Ben birden fazla ajanı aynı anda yönetmek için AgentVera kullanıyorum; işe yarayan kısımlar şunlar:

• Ön yüz ve arka yüz ayrı worktree’lerde. Çalışma alanında API ve webhook işleri için bir Claude Code ajanı, arayüz için bir Codex ajanı açıp her birine kendi git worktree’sini veriyorum. Aynı dosyaya dokunmadıkları için birbirlerini bozmuyorlar. Yöntemin ayrıntısı git worktree ile paralel geliştirme yazısında.
• Birleştirmeden önce diff. Git paneli her worktree’nin değişikliklerini gösteriyor; kod incelemesi biten her turu kontrol ediyor. Neye bakılacağı yapay zeka kod incelemesi yazısında.
• Veritabanını görmek. Veritabanı yöneticisi ile yerel Postgres’teki tabloları açıp ajanın gerçekten ne yazdığına bakıyorum; DB Guard riskli migration’ları tur sonunda işaretliyor.
• Önizleme. Önizleme ortamları her worktree’nin geliştirme sunucusunu kendi adresinde açıyor; iki dalı yan yana deneyebiliyorum.
• Token’ı izlemek. Her panelde canlı bağlam boyutu görünüyor; şiştiğinde oturumu kapatıp yenisini açıyorum.

Bunlar işi hızlandırır ama yukarıdaki kuralların yerini tutmaz: spec, testler ve senin incelemen yine şart.

Sonuç

Yapay zeka ile SaaS yapmak, kodu yazdırmaktan çok kararları yazıya dökmek ve kritik yolları korumakla ilgili. Kapsamı tek akışa indir, kararları CLAUDE.md ya da AGENTS.md’ye yaz, sıkıcı ve yaygın bir yığın seç, veri izolasyonunu veritabanında zorla, para yollarını test et, deploy’dan önce izlemeyi kur. Gerçek para ve gerçek veri girmeden önce de bir insana baktır. Ajanları paralel çalıştırmak istersen AgentVera’yı ücretsiz indirip ilk iki worktree’ni açabilirsin.