David Sacks: Yapay Zeka + SaaS — Yeni Bir Startup Oyun Planı

“AI + SaaS”'in Startup Stratejisine Etkisi

Yapay zeka, abonelik uygulamasına eklediğiniz sıradan bir özellik değil. Kurucular için neyin “iyi” bir ürün fikri olduğu, rakiplerin sizi ne kadar hızlı kopyalayabildiği, müşterilerin ne için ödeme yapacağı ve çıkarım maliyetleri fatura üzerinde göründüğünde iş modelinizin devam edip etmeyeceği değişir.

Bu yazı, David Sacks ile sıklıkla ilişkilendirilen ve daha geniş AI + SaaS tartışmalarında dönen temaların pratik bir sentezidir—sözlük sözüyle bir döküm ya da biyografi değil. Amaç, tekrar eden fikirleri kurucu ya da ürün lideri olarak gerçekten almanız gereken kararlara çevirmektir.

Neden kurucular SaaS’i yeniden düşünüyor

Klasik SaaS stratejisi artımsal iyileştirmeyi ödüllendiriyordu: bir kategori seç, daha temiz bir iş akışı oluştur, koltukları sat ve zamanla geçiş maliyetlerine güven. AI, ağırlık merkezini sonuçlara ve otomasyona kaydırıyor. Müşteriler giderek "İşin benim için yapılmasını sağlar mısınız?" sorusunu soruyor, "İşi daha iyi yönetmeme yardım eder misiniz?" yerine.

Bu, startup’ın başlangıç çizgisini değiştirir. Daha az UI, daha az entegrasyon ve daha küçük bir başlangıç ekibi gerekebilir—ama sistemin doğru, güvenli ve her gün kullanmaya değer olduğuna dair daha net kanıt gerekir.

Bu yazı size ne kararlar aldıracak

Bir fikri değerlendiriyorsanız ya da mevcut bir SaaS ürününü yeniden konumlandırmaya çalışıyorsanız, bu rehber şu seçimlerde yardımcı olmayı amaçlar:

• Ne inşa edeceksiniz: bir özellik mi, bir copilot mu, yoksa tam iş akışını ele alan AI-öncelikli bir ürün mü
• Kime satacaksınız: hangi alıcı sonucu umursuyor ve bütçeyi kontrol ediyor
• Pazara nasıl gideceksiniz: AI ürünleri için hangi dağıtım ve güven sinyalleri önemli
• Finansal olarak nasıl işler hale getirilir: değerle uyumlu fiyatlandırma ve gerçek model maliyetlerini karşılamak

Sürekli döneceğimiz kilit sorular

Okurken dört soruyu aklınızda tutun: Yapay zeka hangi işi tamamlayacak? Kim bu acıyı ödeyecek kadar hissediyor? Fiyatlandırma ölçülebilir değeri nasıl yansıtacak? Başkaları benzer modellere erişince avantajınız nasıl kalıcı olur?

Geri kalan yazı bu cevaplar etrafında modern bir “startup oyun planı” kurar.

Eski SaaS Oyun Planı vs. AI Kayması

Klasik SaaS, yazılımı öngörülebilir bir iş modeline dönüştürdüğü için işe yarıyordu. Abonelik satıyor, zaman içinde kullanım genişlettiriyor ve iş akışı kilitlenmesine güveniyordunuz: bir ekip ürün içinde alışkanlıklar, şablonlar ve süreçler oluşturduğunda ayrılmak zor olurdu.

Bu kilitlenme genellikle açık ROI ile gerekçelendirilirdi. Slogan basitti: “Ayda $X ödeyin, Y saat kazanın, hataları azaltın, daha fazla anlaşma kapatın.” Bunu güvenilir şekilde sunduğunuzda yenilemeler kazanırdınız—ve yenilemeler bileşik büyüme yaratırdı.

AI ile neler değişiyor

AI, rekabet hızını değiştiriyor. Eskiden çeyrekler sürebilecek özellikler haftalar içinde kopyalanabiliyor, bazen aynı model sağlayıcılarına bağlanarak. Bu, birçok SaaS şirketinin dayandığı “özellik hendeği”ni sıkıştırır.

AI-yerel rakipler farklı bir yerden başlar: yalnızca var olan iş akışına bir özellik eklemezler—iş akışını değiştirmeye çalışırlar. Kullanıcılar copilots, ajanlar ve “sadece ne istediğini söyle” arayüzlerine alışıyor; beklentiler tıklamalar ve formlardan sonuçlara kayıyor.

AI demolarında sihirli gelebilir, bu yüzden farklılaşma çıtası hızla yükselir. Herkes özet, taslak veya rapor üretebiliyorsa, esas soru şu olur: müşterinin neden sizin ürüne iş yerinde güvenmesi gerekiyor?

Değişmeyen ve daha da önemli olanlar

Teknolojik kaymaya rağmen temeller değişmedi: gerçek bir müşteri acısı, bunu hisseden belirli bir alıcı, ödeme istekliliği ve sürekli değerle sürdürülmüş tutundurma.

Odaklanmak için faydalı bir hiyerarşi:

Değer (sonuç) > özellikler (kontrol listeleri).

AI check-listleri göndermek yerine (“otomatik notlar, otomatik e-posta, otomatik etiketleme ekledik”), müşterilerin tanıyacağı bir sonuçla başlayın (“kapatma süresini %20 azaltın”, “destek birikimini yarıya düşürün”, “uyumlu raporları dakikalar içinde gönderin”). Özellikler stratejinin değil kanıtların parçasıdır.

AI yüzey katmanını kopyalamayı kolaylaştırdığı için derin sonucu sahiplenmelisiniz.

Doğru Wedge’i Seçmek: Özellik, Copilot veya AI-Öncelikli

Birçok AI + SaaS startup’ı "AI" ile başlar ve ancak sonra hangi işi yaptıracağını arar—bu, durmalarına neden olur. Daha iyi yaklaşım bir wedge (keskin giriş noktası) seçmektir: müşteri aciliyeti ile sizin doğru veriye erişiminizi eşleştiren dar bir giriş noktası.

Üç yol, üç takas

1) AI özelliği (mevcut bir ürün kategorisinin içinde). Tanıdık bir iş akışına bir AI yeteneği eklersiniz (ör: “ticket özetle”, “takip e-postası taslağı”, “fatura otomatik etiketleme”). Bu, alıcılar kategoriyi zaten anladıkları için erken gelir elde etmenin en hızlı yolu olabilir.

2) AI copilot (insan-döngüde). Ürün kullanıcı yanında durur ve tekrar eden bir görevi hızlandırır: taslak oluşturma, triage, araştırma, inceleme. Copilot’lar kalite önemli olduğunda ve kullanıcı kontrol isterken iyi çalışır, ama günlük değer kanıtlamanız gerekir—sadece eğlenceli bir demo yeterli değildir.

3) AI-öncelikli ürün (iş akışı otomasyon etrafında yeniden kurulur). Burada ürün “yazılım + AI” değil, açık girdiler ve çıktılar olan otomatik bir süreçtir (çoğunlukla ajan tarzı). Bu en farklılaştırılmış olabilir, ama derin alan bilgisi, güçlü guardrail’lar ve güvenilir veri akışları gerektirir.

Doğru wedge nasıl seçilir

İki filtre kullanın:

• Müşteri aciliyeti: Ağrılı, sık ve maliyetli bir problem mi, net bir sahibi var mı? "İyi olur" AI özellikleri bütçe incelemesinde zor kalır.
• Veri erişimi: Doğru olmak için gereken bağlamı tutarlı şekilde erişebiliyor musunuz (dokümanlar, ticketlar, CRM verisi, politikalar) ve bunu kullanma izniniz var mı?

Eğer aciliyet yüksek ama veri erişimi zayıfsa, copilot ile başlayın. Veri bol ve iş akışı netse AI-öncelikli düşünün.

“Wrapper risk”ten kaçının

Ürününüz bir commodity modele ince bir UI’yle sarıldıysa, daha büyük bir satıcı benzerini paketlediğinde müşteri anında geçebilir. Paniklemek yerine panzehir, bir iş akışına sahip olmak ve ölçülebilir sonuçları kanıtlamaktır.

Gerçek bir şey inşa ettiğinizi gösteren sinyaller

• Ölçülebilir sonuçlar: zaman tasarrufu, hata azalması, daha hızlı çevrim süresi, daha yüksek dönüşüm
• Tekrarlanabilir iş akışı: ürün tutarlı bir sürece uyar, tek seferlik yenilik değil
• Net alıcı: belirli bir rol bütçeye sahip ve acıyı hissediyor
• Kanıt döngüsü: haftalar içinde gösterilebilen önce/sonra örnekleri ve sonuçların takibi

Dağıtım Önceliği: Yeni Startup’lar Dikkati Nasıl Kazanır

Birçok ürün benzer modellere erişebildiğinde, kazanan kenar genellikle "daha iyi AI"dan "daha iyi erişim"e kayar. Kullanıcılar gün içi işlerinde ürününüzle karşılaşmazsa, model kalitesi önemli olmayacaktır—yeterli gerçek kullanım elde edemezsiniz ki ürün-pazar uyumuna doğru yineleyebilesiniz.

“Varsayılan iş akışı” olun (yeni bir hedef değil)

Pratik konumlandırma hedefi, bir görevin insanların zaten kullandığı araçların içinde yapılmasının varsayılan yolu olmaktır. Müşterilerden “başka bir uygulama” benimsemelerini istemek yerine, iş zaten nerede yapılıyorsa orada görünür olun—e-posta, dokümanlar, ticketing, CRM, Slack/Teams ve veri ambarları.

Bunun önemi:

• Dikkat kıttır; geçiş maliyetleri gerçektir
• AI değeri, mevcut olaylarla tetiklendiğinde (yeni ticket, yeni lead, yeni PR) en açık haldedir
• Gömülü dağıtım kullanımın bileşik hale gelmesini sağlar: kurulduğunuzda akışın içinde olursunuz

Erken işe yarayan kanallar (ve neden)

Entegrasyonlar & marketler: En küçük işe yarar entegrasyonu inşa edip ilgili markete gönderin (ör. CRM, destek masası, chat). Marketler yüksek niyetli keşif sunar ve entegrasyonlar kurulum sürtünmesini azaltır.

Outbound: Ağrılı, sık bir iş akışına sahip dar bir role hedefleyin. Somut bir sonuçla öne çıkın ("triage süresini %40 azalt") ve hızlı bir kanıt adımı sunun (15 dakikalık kurulum, haftalar süren pilot değil).

İçerik: “X’i nasıl yapıyoruz” playbook’ları, teardown yazıları ve şablonlar yayınlayın. İçerik, insanların kopyalayabileceği artefaktlar içerdiğinde özellikle etkilidir (promptlar, kontrol listeleri, SOP’lar).

Ortaklıklar: İdeal kullanıcıyı zaten elinde tutan ajanslar, danışmanlar veya bitişik yazılımlarla eşleştirin. Ortak pazarlama ve yönlendirme marjı sunun.

İlk 10 ücretli müşteriye en hızlı yol için kontrol listesi

1. Bir persona + bir iş akışı seçin (her biri bir cümle)
2. Bir ölçülebilir vaad sunun (zaman tasarrufu, gelir, risk azaltma)
3. “Araç içi” bir giriş noktası gönderin (plugin, webhook, sidebar, e-posta yönlendirme)
4. Müşterinin gerçek verisiyle 30 dakika içinde bir demo hazırlayın
5. Basit bir ücretli plan koyun (sonsuz bedava değil) ve ilk günde kart alın
6. 50 hedefli outreach yapın; 10 görüşme ayarlayın; 3 ücretli deneme hedefleyin
7. İlk 3 başarıyı tek sayfalık vaka çalışmalarına dönüştürün ve outbound’ta tekrar kullanın
8. Onboarding’i, yeni bir kullanıcının ilk oturumda değere ulaşana kadar sıkıştırın
9. Aynı nişte satış zaten sıradan hale gelene kadar tekrarlayın
10. Ancak o zaman bir sonraki bitişik iş akışına genişleyin

AI Ürünleri için Fiyatlandırma ve Paketleme

AI, maliyeti ve değeri “bir koltuk”a bağlanmamış şekilde değiştirir. Bir kullanıcı bir düğmeye basıp uzun bir iş akışını tetikleyebilir (pahalı), ya da tüm gün hafif görevler yapabilir (ucuz). Bu birçok ekipte koltuk bazlı planlardan sonuç/ kullanım/ kredi bazlı modellere geçişi zorlar.

Koltuklardan değere: sonuçlar, kullanım, krediler

• Sonuçlar: müşterinin gerçekten istediği şeye göre ücretlendirin (örn. "nitelikli lead’ler zenginleştirildi", "ticketlar çözüldü", "sözleşmeler incelendi")
• Kullanım: ölçülebilir aktiviteye göre ücret alın (işlenen dokümanlar, dakikalar, üretilen mesajlar)
• Krediler: kullanımı müşterinin anlayacağı basit bir birime çevirin ("1 kredi = 1 sayfa analiz"), sonra paketler halinde satın

Amaç fiyatı sağlanan değerle ve hizmet maliyetiyle hizalamaktır. Model/API faturanız token, görüntü veya araç çağrılarıyla büyüyorsa, planlar net limitler içermeli ki ağır kullanım gizlice negatif marja dönüşmesin.

Örnek paket katmanları (katman başına ne değişir)

Starter (birey / küçük ekip): temel özellikler, küçük aylık kredi paketi, standart model kalitesi, topluluk veya e-posta desteği.

Team: paylaşılan çalışma alanı, daha yüksek krediler, iş birliği, entegrasyonlar (Slack/Google Drive), yönetici kontrolleri, kullanım raporlaması.

Business: SSO/SAML, denetim kayıtları, rol tabanlı erişim, daha yüksek limitler veya özel kredi havuzları, öncelikli destek, satın alma dostu faturalama.

Gördüğünüz gibi ölçeklenenler: limitler, kontroller ve güvenilirlik—sadece “daha fazla özellik” değil. Eğer koltuk fiyatı kullanacaksanız, hibrit düşünün: temel platform ücreti + koltuklar + dahil krediler.

Kaçınılması gereken yaygın hatalar

Sonsuza kadar ücretsiz kulağa dostça gelir, ama müşterileri oyuncağınız gibi davranmaya alıştırır ve nakit yakabilir.

Ayrıca belirsiz limitler ("limitsiz AI") ve sürpriz faturalarden kaçının. Üründe kullanım ölçerleri gösterin, eşik uyarıları gönderin (80/100%), ve aşım ücretlerini açıkça belirtin.

Basit bir test planı (2–3 deney)

1. Koltuk vs. hibrit: dönüşüm ve brüt marj karşılaştırması. Metrik: ücretli dönüşüm %, model maliyetleri sonrası marj
2. Kredi paket boyutları: küçük/orta/büyük paketler. Metrik: yükseltme oranı ve aşım sıklığı
3. Sonuç bazlı fiyat pilotu için bir iş akışı. Metrik: tutunma (30/90 gün), ödeme istekliliği, faturalama destek talepleri

Eğer fiyatlandırma kafa karıştırıcıysa muhtemelen öyledir—birimi sıkılaştırın, metreyi gösterin ve ilk planı satın alınması kolay tutun.

Tutundurma ve Güven: Demoyu Günlük Kullanıma Çevirme

AI ürünleri demoda genellikle "sihirli" görünür çünkü prompt küratörlüdür, veriler temizdir ve bir insan çıktı yönlendirir. Günlük kullanım daha karmaşıktır: gerçek müşteri verisi kenar durumlar içerir, iş akışları istisnalar gösterir ve insanlar sistemin kendinden emin şekilde yanlış yaptığı o tek vakaya göre sizi yargılar.

Güven, tutundurmayı sağlayan gizli özelliktir. Kullanıcılar sonuçlara güvenmezse, ilk günden etkilenmiş olsalar bile ürünü sessizce kullanmayı bırakırlar.

Tutundurma yolculuğu: onboarding → ilk değer → alışkanlık → yenileme

Onboarding belirsizliği azaltmalı, yalnızca butonları açıklamakla kalmamalıdır. Ürünün iyi yaptığı şeyleri, yapmadıklarını ve hangi girdilerin önemli olduğunu gösterin.

İlk değer, kullanıcının somut bir sonuç aldığı andır (kullanılabilir bir taslak, daha hızlı çözülen bir ticket, yaratılmış bir rapor). Bu anı açık hale getirin: ne değiştiğini ve ne kadar zaman kazandırdığını vurgulayın.

Alışkanlık, ürünün tekrarlanan bir iş akışına sığmasıyla oluşur. Hafif tetikleyiciler oluşturun: entegrasyonlar, zamanlanmış çalıştırmalar, şablonlar veya "kaldığınız yerden devam et".

Yenileme, güvenin denetimidir. Alıcılar sorar: “Bu tutarlı çalıştı mı? Riski azalttı mı? Ekip nasıl çalışıyor?” Ürününüz bu soruları kullanım kanıtı ve açık ROI ile yanıtlamalıdır.

Güven kazandıran UX kalıpları

İyi bir AI UX belirsizliği görünür kılar ve geri dönüşü kolaylaştırır:

• Guardrail’lar: onaylı kaynaklar, güvenli modlar, politika kontrolleri
• Güven göstergeleri: sistemin tahmin yaptığını ve nedenini gösterme (atıflar, kaynak bilgisi, tazelik, kapsama)
• Kolay geri alma: tek tıklamayla geri al, sürüm geçmişi, önceki duruma döndürme
• İnsan-döngü: hassas adımlar için onaylar ve AI emin olmadığında yükseltme yolları

Güvenilirlik beklentileri: KOBİ vs. kurumsal

KOBİ’ler, ürün hızlı, uygun fiyatlı ve açıkça verim artırıyorsa ara sıra hata tolere edebilir—özellikle hatalar kolayca yakalanıp geri alınabiliyorsa.

Kurumsal müşteriler ise öngörülebilir davranış, denetlenebilirlik ve kontroller bekler. İzinler, loglar, veri işleme garantileri ve net hata modları onlar için satın alma kararının parçasıdır.

Savunulabilirlik: “Biz AI Kullanıyoruz”un Ötesi

Müşterinin bir ay sonra kolayca sizi değiştiremeyeceği basit neden moat’tır. AI + SaaS’ta "modelimiz daha akıllı" iddiası genelde dayanmaz—modeller hızla değişir ve rakipler aynı yetenekleri kiralayabilir.

Gerçekten savunulabilir olanlar

En güçlü avantajlar genellikle AI’ın etrafında durur, içinde değil:

• Özel iş akışı: ekrandan onaya, istisnalara kadar gerçek bir ekibin çalışma şeklini sahiplenirsiniz—sizi değiştirmek ekipleri yeniden eğitmeyi ve süreçleri yeniden yazmayı gerektirir
• Dağıtım: zaten dikkate sahipsiniz (bir kitle, kanal ortağı, ekosistem listesi, topluluk), böylece müşteriyi daha ucuz ve hızlı alırsınız
• Marka ve güven: özellikle düzenlemeli veya hassas işlerde ekipler güvenli ve öngörülebilir hissettiren araçlarla kalır
• Veri hakları (sadece “veri” değil): savunulabilirlik, veriyi kullandığınıza dair izinler, net sözleşmeler ve müşteri kontrollü ayarlardan gelir—belirsiz “veriyi sahipleniyoruz” iddiaları yerine
• Entegrasyonlar: CRM, ticketing, ERP, kimlik gibi sistemlerle derin bağlar geçiş sürtünmesi yaratır ve ürününüzü varsayılan yapar

Veri iddiaları konusunda dikkatli olun

Birçok ekip “müşteri verisiyle eğitiyoruz” diyerek abartır; bu ters teper. Alıcılar giderek tam tersini istiyor: kontrol, denetlenebilirlik ve verinin izole tutulma seçeneği.

Daha iyi bir duruş: açık izinler, net saklama kuralları ve yapılandırılabilir eğitim ("eğitim yok" seçeneği dahil). Savunulabilirlik, satıcıyı yasal ve güvenlik ekiplerinin çabucak onayladığı vendor yapmakla da gelir.

Münhasır veri olmadan inşa edilebilecek iş akışı hendekleri

Gizli veri setlerine ihtiyaç duymadan değiştirilmeyi zorlaştırabilirsiniz. Örnekler:

• Gerçek bir ekibin çalışma şekline uyan bir onay ve istisna sistemi (kim geçersiz kılabilir, ne zaman yükseltilir, nasıl dokümante edilir)
• UI içinde en iyi uygulamaları kodlayan tekrar kullanılabilir playbook kütüphanesi (şablonlar, politikalar, kontrol listeleri)
• Prodüksiyonda AI’ı güvenli yapan insan-döngü kontrolleri (güven eşiği, inceleme kuyrukları, rollback)
• Entegrasyon temelli bağlam (CRM/ticket/dokümanlara izinlere duyarlı erişim) ki cevaplar müşterinin sistemlerine dayansın

Eğer AI çıktınız demo ise, iş akışınız hendektir.

AI Gerçek Maliyet Varken Birim Ekonomisi

Geleneksel SaaS birim ekonomisi yazılımın servis maliyetinin ucuz olduğunu varsayar: ürünü inşa ettikten sonra ek kullanıcı neredeyse maliyeti değiştirmez. AI bunu değiştirir. Ürününüz her iş akışında inference çalıştırıyorsa—çağrı özetleme, e-posta taslağı, ticket yönlendirme—COGS kullanım ile birlikte artar. Bu, “büyük büyüme”nin brüt marjı sessizce sıkıştırabileceği anlamına gelir.

Neden brüt marj farklı görünür

AI özellikleriyle değişken maliyetler (model inference, tool çağrıları, retrieval, GPU zamanı) lineer veya daha kötü ölçeklenebilir. Ürünü çok seven müşteri aynı zamanda en pahalı müşteri olabilir.

Bu yüzden brüt marj sadece bir finans satırı değil; ürün tasarım kısıtıdır.

İlk günden takip etmeniz gereken metrikler

Müşteri ve işlem düzeyinde birim ekonomiyi takip edin:

• CAC ve CAC geri ödeme süresi
• Tutunma (logo ve net gelir) ve genişleme vs. daralma
• Kullanıcı/çalışma alanı başına COGS (ve kilit aksiyon başına)
• Kullanım eğrileri: kullanıcı başına aksiyonlar zaman içinde, zirve vs. kararlı kullanım
• Kohort bazlı brüt marj (ağır vs. hafif kullanıcılar)

İnference maliyetlerini kontrol altına almak için taktikler

Erken dönemde genelde işe yarayan pratik kollar:

• Önbellekleme ve dedupe (aynı şeyi tekrar özetlemeyin)
• Görev başına model seçimi (sınıflandırma için küçük model, kompleks akıl yürütme için büyük)
• Sert limitler ve makul varsayılanlar (oran limitleri, bağlam penceresi kapakları, toplu işler)
• Prompt ve bağlam optimizasyonu (kısa girdiler, daha iyi retrieval, daha az tool çağrısı)

API’ler vs. özel modeller: ne zaman yatırım yapılmalı

Ürün-pazar uyumunu ararken API’lerle başlayın: hız mükemmellikten önce gelir.

Özel ince ayar ya da modeller düşünün when (1) inference maliyeti COGS’unuzu belirgin şekilde etkiliyor, (2) tescilli veriniz ve stabil görevleriniz var, ve (3) performans iyileşmeleri doğrudan tutunma veya ödeme istekliliğine dönüşüyor. Model yatırımını ölçülebilir bir iş sonucuna bağlayamıyorsanız, API satın almaya devam edin ve dağıtıma odaklanın.

Kurumlara Satış: Sonuçlar, Alıcılar ve Kanıt

AI ürünleri, demo zekice diye satın alınmaz—alınır çünkü risk yönetilebilir görünür ve avantaj açık olur. İş alıcıları üç soruya cevap arar: Bu ölçülebilir bir sonucu iyileştirir mi? Ortamımıza uyum sağlar mı? Verilerimize güvenebilir miyiz?

Alıcıların ciddiye almak için bekledikleri

Orta seviye takımlar bile artık bir dizi “kurum hazır” sinyal bekliyor:

• Güvenlik temelleri: SSO/SAML, rol tabanlı erişim, transit/at rest şifreleme
• Yönetici kontrolleri: kullanıcı sağlama, çalışma alanı kontrolleri, kullanım limitleri/guardrail’lar
• Denetlenebilirlik: denetim logları, sürüm/geçmiş, AI ile üretilen eylemler için izlenebilirlik
• Net veri işleme: ne saklanır, model sağlayıcılara ne gönderilir, saklama seçenekleri ve verinin (eğitim için) nasıl kullanıldığı ya da kullanılmadığı

Bunlar belgelenmişse, satış döngüsünde /security’ye erken yönlendirin. Bu, geri dönüşleri azaltır ve güveni artırır.

Yöneticilere sonuç, son kullanıcılara kullanılabilirlik sat

Farklı paydaşlar farklı sebeplerle satın alır:

• Yönetici alıcılar (CFO/COO/VP): sonuçla yaklaşın—kazandırılan saatler, çevrim süresi azaltma, hata azalması, hızlanan gelir tahsilatı, artan dönüşüm, düşen destek yükü. Basit bir önce/sonra hikayesi ve inandırıcı bir ROI modeli verin.
• Takım liderleri ve son kullanıcılar: kullanılabilirlikle yaklaşın—iş akışlarına nasıl uyduğu, neyi yerine getirdiği ve neyi yapmayacağı. "Gün 1" değeri (şablonlar, entegrasyonlar, varsayılanlar) ve "Gün 30" değeri (otomasyon, özetler, takipler) gösterin.

Pilotları sözleşmeye dönüştüren kanıt

Alıcının risk düzeyine uygun kanıt kullanın: kısa ücretli pilot, referans çağrısı, metrikli hafif vaka çalışması ve net bir yayılma planı.

Basit kurumsal hazır olma kontrol listesi

• Güvenlik sayfası ve veri işleme SSS’i kamuya açık (/security)
• SSO ve rol tabanlı izinler mevcut
• Denetim logları yöneticilere erişilebilir
• Net yönetici kontrolleri (provisioning, erişim, limitler)
• Pilot planı: başarı metrikleri, zaman çizelgesi, sahibi ve yayılma adımları
• İş değerine eşlenen fiyatlandırma ve paketleme (/pricing)

Amaç “evet” demeyi güvenli hissettirmek ve değeri kaçınılmaz kılmaktır.

Ekip ve Operasyon Modeli: Küçük, Hızlı ve Odaklı

AI, “yağsız” olmanın anlamını değiştirir. Otomasyon, daha iyi araçlar ve model API’leri işleri sıkıştırdığı için küçük bir ekip, çok daha büyük görünen bir deneyim sunabilir. Kısıt artık "inşa edebilir miyiz?" değil, "hızlı karar verip hızlı öğrenebilir miyiz?" olur.

Küçük ekipler, büyük kaldıraç

Erken aşamada 3–6 kişilik bir ekip genelde 15–20 kişilik bir ekipten daha iyi performans gösterir çünkü koordinasyon maliyetleri çıktıyı daha hızlı aşar. Daha az teslim hattı, daha hızlı döngüler demektir: sabah müşteri görüşmesi, öğleden sonra düzeltme, ertesi gün sonucu doğrulama mümkün olur.

Ama amaç sonsuza dek küçük kalmak değil—wedge kanıtlanana kadar odaklı kalmaktır.

Erken dönemde önemli birkaç rol

Her fonksiyonun dolu olmasına gerek yok. Öğrenmeyi yönlendiren net sahipler gerekir:

• Ürün sahibi (genelde kurucu): wedge’i belirler, “yapılacak işi” tanımlar ve kapsamı sıkı tutar
• Büyüme/dağıtım: bir kanalı sahiplenir (outbound, içerik, ortaklar, topluluk) ve dönüşümü uçtan uca izler
• Customer success (part-time bile olabilir): pilotları alışkanlığa dönüştürür, itirazları dokümante eder ve kanıtı inşa eder
• Mühendislik/ML (gerekli olduğunda): bir güçlü generalist + ML derinliği ancak kalite için gerçekten çekirdekse

Eğer kimse retention ve onboarding’e sahip değilse, demo kazanmaya devam edersiniz ama günlük kullanım kazanmaktan vazgeçersiniz.

İnşa et vs. satın al: farklılaşanı gönderin

Çoğu ekip, mühendislik zamanını ürün kenarına harcamak için altyapı için satın almalı veya yönetilen servisleri kullanmalıdır:

• Satın al: auth, faturalama, analitik, feature flag, CRM, temel destek araçları
• Kullan: model sağlayıcılar ve değerlendirme araçları; ürün-pazar uyumunu bulana kadar
• İnşa et: iş akışı, veri geri besleme döngüsü ve sonuçları ölçülebilir kılan UX

Pratik kural: 6 ay içinde farklılaştırmayacaksa inşa etmeyin.

Pratik not: Koder.ai ile inşa döngüsünü kısaltmak

AI + SaaS ekiplerinin küçük kalabilme sebeplerinden biri, inanılır bir MVP oluşturmanın eskisinden daha hızlı olmasıdır. Koder.ai gibi platformlar bu kaymaya odaklanır: sohbet tabanlı bir arayüzle web, backend ve mobil uygulamalar oluşturabilir, sonra kaynak kodu dışa aktarabilir veya dağıtabilirsiniz—wedge üzerinde yineleme yaparken hızlı denemeler göndermek için kullanışlıdır.

İki özellik bu oyun planıyla iyi örtüşür: planlama modu (inşa etmeden önce kapsam disiplini zorlamak) ve anlık görüntüler/geri alma (onboarding, fiyat kapıları veya iş akışı değişikliklerini test ederken hızlı yinelemeyi güvenli kılar).

İlk 90 gün için işletim ritmi

Operasyon modelini basit ve tekrarlı tutun:

• Haftalık metrik incelemesi: aktivasyon, ilk-değer süresi, tutunma, işlem başına maliyet ve pipeline
• Haftada 5–10 müşteri konuşması: kaydedilip özetlenip backlog’a beslensin
• Gönderim ritmi: küçük sürümler haftada 2–3 kez; her 2–3 haftada bir daha büyük bir bahis

Bu ritim netlik zorlar: ne öğreniyoruz, ne değiştiriyoruz ve rakamları hareket ettirdi mi?

Basit Kontrol Listesi: Yeni Startup Oyun Planını Uygulamak

Bu bölüm “AI + SaaS” kaymasını bu hafta çalıştırabileceğiniz eylemlere çevirir. Kontrol listesini kopyalayın, ardından karar ağacıyla planınızı teste tabi tutun.

Kopyalanabilir kontrol listesi (yazdırın)

• Bir wedge seçin: 2–4 haftada kazanabileceğiniz tek bir iş
• ICP’nizi isimlendirin: rol, şirket büyüklüğü, iş akışı ve acının hissedildiği an
• Sonucu tanımlayın: “X saat tasarruf”, “hataları Y% azalt”, “ticketları Z dakikada kapat”
• Erken kanıt alın: ölçülebilir önce/sonra sonuçları olan 5–10 tasarım ortağı
• Niyetle fiyatlandırın: değerle eşleşen bir fiyat birimi seçin (koltuk, kullanım, iş akışı veya sonuç)
• Dağıtımı planlayın: dikkat nereden gelecek—SEO, ortaklıklar, marketler, outbound, topluluk?
• Onboarding’i kaçınılmaz yapın: ilk 10 dakika açık bir “aha” anına ulaşmalı
• Günlük kullanım için tasarla: hatırlatıcılar, entegrasyonlar, şablonlar ve ertesi gün için geri gelme nedeni
• Güven özellikleri inşa edin: denetim logları, izinler, veri sınırları ve net hata modları
• Birim ekonomiyi izle: müşteriniz başına AI maliyetini ve hangi aksiyonların harcama patlatığını bilin

Karar ağacı: wedge → alıcı → fiyat → dağıtım → tutundurma

Kısa “eğer/o zaman” yolu:

1. Wedge seçin

• Wedge temel sistemleri değiştirmeyi gerektiriyorsa → sınırlandırın (önce bir eklenti olarak başlayın)
• Değer mevcut iş akışında verilebiliyorsa → önce onu gönderin

2. Alıcıyı doğrulayın

• Kullanıcılar sevdiyse ama bütçeyi kimse üstlenmiyorsa → bütçe sahibine yeniden çerçeveleyin
• Alıcı kanıt istiyorsa → somut metrikli 2 haftalık pilot yapın

3. Fiyatı belirleyin

• Maliyet kullanım ile ölçekleniyorsa → limitsiz planlardan kaçının; katmanlar/limitler ekleyin
• Değer sonuçlarla ölçekleniyorsa → sonuç bazlı ya da iş akışı bazlı fiyat düşünün

4. Dağıtımı seçin

• Problem acil ve spesifikse → outbound işe yarar
• Birçok kişi arıyorsa → içerik/SEO
• İş platformun içinde yaşıyorsa → marketplace + entegrasyonlar

5. Tutundurmaya kilitlenin

• Demo etkisi var ama haftalık düşüş oluyorsa → onboarding + alışkanlık tetiklerini düzeltin
• Güven endişeleri yaygınsa → kontroller, görünürlük ve yönetişim ekleyin

Yaygın tuzaklar (ve yerine ne yapılmalı)

• Demo-öncelikli ürün: bir kere etkileyici, sonra unutulur → tekrarlanabilir iş akışı ve hatırlatıcılar oluşturun
• Belirsiz ICP: “herkes” müşteri olur → bir rol ve bir kullanım durumu seçin
• Zayıf onboarding: kullanıcılar değere hızlı ulaşmaz → kurulum adımlarını azaltın; şablonlar gönderin
• Kötü fiyatlandırma: maliyeti karşılayamayacak kadar ucuz ya da satın alınması karmaşık → değere göre fiyatlayın, katmanları basit tutun

Sonraki okumalar

Daha fazla oyun planı ve çerçeveye göz atın: /blog. Bu konunun daha derin bir incelemesini istiyorsanız, şu kaynağa bakın: /blog/david-sacks-on-ai-saas-a-new-startup-playbook.