SaaS nasıl yapılır? Fikirden ilk ödeme yapan müşteriye

SaaS nasıl yapılır sorusunun kısa cevabı şu: önce bir grup işletmenin para ödeyeceği tek bir problemi elle çözersiniz, sonra bu çözümü birden çok müşterinin kendi verisiyle kullanabileceği tek bir yazılıma dönüştürürsünüz. Hesaplar, abonelik tahsilatı, fatura ve destek ilk günden bu yazılımın parçasıdır; kodlama işin yalnızca bir bölümüdür.

Bu rehberi UlvionTech mühendislik ekibi, bir hizmeti ya da şirket içinde kullandığı bir aracı abonelikli ürüne çevirmek isteyen kurucular ve KOBİ sahipleri için hazırladı. Bir ürün fikrinin kapsamını nasıl daraltacağınızı ayrı bir yazıda ele aldık; burada odak, tek seferlik bir uygulamadan farklı olarak bir SaaS ürününü satmanın ve yayında tutmanın neler gerektirdiği. Vergi, ödeme ve kişisel veri kurallarını Ekim 2026 itibarıyla resmî kaynaklarına bağlayarak verdik. Bunlar bilgi amaçlıdır; kendi durumunuz için mali müşavirinize ve hukukçunuza danışın.

SaaS ürünü nedir, tek seferlik özel yazılımdan farkı ne?

SaaS ürünü (Software as a Service, hizmet olarak yazılım), müşterilerin kurulum yapmadan internet üzerinden kullandığı ve çoğunlukla aylık ya da yıllık abonelikle ödediği yazılımdır. Yazılımı siz geliştirir, sunucuda siz çalıştırır ve güncellemeyi siz yaparsınız; müşteri yalnızca hesabını açar ve kullanır. Tek seferlik özel yazılımda ise bir şirket kendi süreci için yazılım yaptırır, sistemin sahibi olur ve kullanıcıları yalnızca kendi ekibidir.

SaaS ile tek seferlik özel yazılım arasındaki fark teknik olmaktan çok ticaridir. Aynı ölçütlerle yan yana konduğunda tablo şöyle:

UlvionTech ekibi olarak bize göre tablonun en çok hafife alınan satırı, ürün kararlarıdır. Tek bir müşteriye yazılım geliştirirken onun her isteği yapılacak bir iştir; SaaS'ta ise bir müşterinin isteğine evet demek, diğer bütün müşterilerin ekranını da değiştirmek demektir. Bu yüzden SaaS ürün yönetimini, yani ürüne kimin karar verdiğini, kod yazılmadan önce netleştirmeyi şart görüyoruz.

Bir hizmeti ya da iç aracı SaaS'a dönüştürmeye değer mi?

Bir hizmeti ya da şirket içinde kullandığınız bir aracı SaaS'a dönüştürmek, aynı problemi yaşayan başka şirketler bunun için düzenli ödeme yapmaya hazırsa değer. Örneğin depo için yazdırdığınız bir stok takip programı sizin işinizi çok kolaylaştırıyor olabilir. Onu başka firmalara satmak ise onların farklı ürün yapılarını, farklı kullanıcılarını ve farklı sorularını da üstlenmek demektir. Bu karar için şu ayrımı öneriyoruz:

• SaaS'a dönüştürün: aynı problemi aynı şekilde yaşayan, adını sayabildiğiniz bir müşteri grubu varsa ve bunların birkaçı bugün elle sunduğunuz çözüm için para ödüyorsa.
• SaaS'a dönüştürün: iş kuralları müşteriden müşteriye az değişiyorsa ve farklar ayarlarla karşılanabiliyorsa.
• Tek seferlik yazılım olarak kalsın: araç yalnızca sizin sürecinize göre şekillendiyse ve başka firmalar onu kullanmak için kendi süreçlerini değiştirmek zorunda kalacaksa.
• Hizmet olarak kalsın: müşterilerin asıl satın aldığı şey uzmanlığınız ve zamanınızsa, yazılım bunu yalnızca hızlandırıyorsa.
• Bekleyin: ürünle ilgilenecek, müşteriyle konuşacak ve önceliklere karar verecek bir kişi yoksa.

Ürünü sahiplenecek birinin olması, bizim gözümüzde en belirleyici ölçüttür. SaaS ürünü bir kez teslim edilip biten bir proje değildir; her ay yeni sorular, istekler ve ödeme sorunlarıyla gelen bir iştir. Şirkette bu işi sahiplenecek biri yoksa, iyi yazılmış bir ürün bile müşteri kaybeder. Yazılımı yalnızca kendi ekibiniz kullanacaksa özel yazılım mı hazır yazılım mı karşılaştırmamız daha doğru bir başlangıç noktasıdır.

SaaS nasıl yapılır? Fikirden ilk ödeme yapan müşteriye yedi aşama

SaaS, fikirden ilk ödeme yapan müşteriye kadar yedi aşamada yapılır: problemi ve ödeyecek kişiyi yazmak, çözümü elle satmak, kapsamı yazıya dökmek, hesap ve kiracı modelini kurmak, tek iş akışını geliştirmek, tahsilatı ve faturayı bağlamak, ilk on müşteriyi kazanmak. Bunlardan yalnızca dördüncü, beşinci ve altıncı aşama kod yazmayı gerektirir. Her aşama bir sonrakine geçmek için gereken kanıtı üretir; bu yüzden ilk iki aşamanın atlanmamasını öneriyoruz, çünkü yazılım bütçesinin en ucuz kısmı onlardır.

1. Problemi ve ödeyecek kişiyi yazın: hangi tür şirketin, hangi roldeki kişinin, hangi işi yaparken zaman ya da para kaybettiğini bir sayfada tarif edin. "Herkes" bir müşteri grubu değildir.
2. Çözümü elle satın: bir tablo, bir form ve bir ödeme bağlantısıyla birkaç müşteriye hizmeti elle verin. Bu aşamada ödeme yapan çıkmıyorsa, yazılıma geçmeden önce teklifi ya da hedef müşteriyi değiştirin.
3. Kapsamı yazıya dökün: ilk sürümün hangi iş akışını kapsayacağını ve hangilerini kapsamayacağını yazın. Bu adımın ayrıntılarını MVP geliştirme ve SaaS MVP planlama rehberimizde anlattık.
4. Hesap ve kiracı modelini kurun: her müşteri firmanın bir hesap, her kullanıcının bir rol olduğu temel yapı, ilk ekranlardan önce gelir.
5. Tek iş akışını ve tek paketi geliştirin: bir ana iş akışı, tek bir fiyat paketi ve ürünü yönetmeniz için basit bir iç ekran.
6. Tahsilatı, faturayı ve ilk kullanım akışını bağlayın: müşterinin kendi başına kaydolup ilk sonucunu alabildiği ve ödeme yapabildiği bir yol. Tahsilat ilk müşterilerde yarı elle yürüyebilir.
7. İlk on müşteriyi tek tek kazanın: her birinin kurulumuna eşlik edin, nerede takıldığını not edin ve ürünü bu notlarla geliştirin.

Bizim önerimiz, ilk on müşteriyi tanıdığınız sektörde ve doğrudan konuşarak aramaktır. SaaS'ı bir hizmetten türeten kurucuların en büyük avantajı burada yatar, çünkü bugün hizmet verdiğiniz firmalar ilk müşteri adaylarınızdır. Onlardan gelen geri bildirim, bütçeyi kimsenin istemediği özelliklere harcamanızı önler. Bu aşamada müşteri sayısından çok, her müşterinin ürünü ikinci ay da kullanıp kullanmadığına bakılmasını öneririz.

Çok kiracılı yapı, roller ve ilk kullanım akışı nasıl kurulur?

Çok kiracılı yapı (multi-tenant), birden çok müşteri firmanın aynı yazılımı ve çoğu zaman aynı veritabanını kullandığı, ama her firmanın yalnızca kendi verisini gördüğü SaaS mimarisidir. Roller ve ilk kullanım akışıyla birlikte, bir SaaS ürününü tek seferlik uygulamadan ayıran üç temel parçayı oluşturur ve üçü de ilk sürümde yer almalıdır. Kimlik doğrulama, işlem e-postaları ve yedek gibi ertelenemeyecek diğer altyapı kalemlerini MVP rehberimizde listeledik. Burada bu üç parçanın neden sonradan eklenemeyeceğine odaklanıyoruz.

SaaS'ta kiracı nedir, müşteri verisi nasıl ayrılır?

Kiracı, ürününüzü kullanan her müşteri firmadır. Çok kiracılı yapıda her kayıt bir firmaya bağlıdır ve her sorgu yalnızca o firmanın verisini getirir. Bu ayrımı sonradan eklemek, var olan her tabloya, her sorguya ve her rapora geri dönmek demektir.

Biz veri ayrımı kuralını veri erişim katmanında ya da bazı veritabanlarının sunduğu satır düzeyinde güvenlik (row-level security) özelliğiyle zorunlu kılmayı tercih ediyoruz; tek tek ekranlara bırakılan bir kural kolayca unutulur. Bir geliştiricinin unuttuğu tek bir filtre, bir firmanın verisini başka bir firmaya göstermeye yeter. Bu hatanın bedeli yalnızca teknik değildir; müşterinin güveni ve KVKK yükümlülükleri de işin içine girer.

SaaS'ta roller ve yetkiler nasıl kurulur?

Rol, bir kullanıcının kendi firması içinde neyi görebileceğini ve neyi değiştirebileceğini belirler. İlk sürüm için iki rol çoğu ürüne yeter: firmayı, kullanıcıları ve aboneliği yöneten bir firma yöneticisi ile günlük işi yapan kullanıcı. Ayrıntılı yetki tablolarını müşteriler istediğinde eklemek kolaydır; firma yöneticisi kavramını sonradan eklemek ise davet ve ödeme akışlarını yeniden yazmayı gerektirir.

Ürünü işleten kendi ekibiniz için de ayrı bir iç rolü baştan düşünmekten yanayız. Destek verirken müşterinin ekranını onun izniyle ve kayıt altında görebilmek, telefonda dakikalarca ekran tarif etmekten çok daha hızlıdır.

SaaS'ta ilk kullanım akışı (onboarding) nasıl kurulur?

İlk kullanım akışı, yeni bir müşterinin kayıt olduktan sonra ürünün ilk faydasını gördüğü ana kadar izlediği yoldur. Tek seferlik yazılımda bu işi bir eğitim toplantısı görür; SaaS'ta ise müşteri ürünü çoğu zaman kimseyle konuşmadan dener. İlk sürümde süslü turlar yerine üç şeye öncelik verilmesini öneririz: örnek verilerle dolu bir başlangıç ekranı, ilk işi yapmaya götüren tek bir yönlendirme ve takıldığında yazabileceği bir destek kanalı. İlk müşterilerin kurulumuna bizzat eşlik etmek, bu akışın nerede koptuğunu en hızlı gösteren yöntemdir.

SaaS'ta abonelik ve fatura nasıl yönetilir?

SaaS'ta abonelik ve fatura üç kuralla yönetilir: kart verisi lisanslı bir ödeme kuruluşunda ya da bankada kalır, paket, deneme, başarısız ödeme ve iptal kuralları baştan yazılır ve her tahsilatta doğru e-belge kesilir. Tek seferlik projede birkaç faturayla biten iş, burada her ay ve her müşteri için tekrar eder. Kart bilgisini kendi sunucunuzda tutmanızı önermiyoruz: Ekim 2026 itibarıyla PCI DSS (yeni sekmede açılır) güvenlik standardı, kart verisini saklayan, işleyen ya da ileten ve bu verinin güvenliğini etkileyebilecek kuruluşlara uygulanır. Kartı ödeme kuruluşunun kendi sayfasında almak, kart verisinin sunucunuza hiç uğramamasını sağlar; size kalan uyum yükümlülüğünü ödeme kuruluşunuzla netleştirin.

Tahsilatı bir bankanın altyapısı ya da TCMB'nin 6493 sayılı Kanun kapsamında listelediği ödeme kuruluşlarından (yeni sekmede açılır) biri üzerinden yapmak daha güvenli bir yoldur. Abonelik kurallarını ise bir abonelik faturalama hizmetine ya da kendi kodunuza bırakabilirsiniz. Hangisini seçerseniz seçin, şu kuralların baştan yazılması gerekir:

• Paketler: ilk sürümde tek paket; sonradan eklenecek paketler arasındaki farkı kullanıcı sayısı ya da kullanım miktarı gibi ölçülebilir bir sınırla kurun.
• Deneme süresi: kart istenip istenmeyeceği ve süre bitince hesabın ne olacağı.
• Yükseltme ve düşürme: dönem ortasında paket değişince farkın nasıl hesaplanacağı.
• Başarısız ödeme: tahsilatın kaç kez yeniden deneneceği, müşteriye hangi e-postanın gideceği ve hesabın ne zaman kısıtlanacağı.
• İptal ve veri: abonelik bitince verinin ne kadar süre saklanacağı ve müşterinin verisini nasıl dışa aktaracağı.
• Fatura: her tahsilat için faturanın hangi belgeyle, hangi sistem üzerinden kesileceği.

Türkiye'de SaaS faturası, alıcının e-Fatura kullanıcısı olup olmamasına göre ayrıca planlanmalıdır. Gelir İdaresi Başkanlığı'nın e-Arşiv Fatura açıklamasına (yeni sekmede açılır) göre, e-Arşiv Fatura uygulamasına dahil olan mükellefler e-Fatura uygulamasına kayıtlı alıcılara e-Fatura düzenler. Kayıtlı olmayan mükelleflere ve vergi mükellefi olmayanlara ise e-Arşiv Fatura düzenlemek zorundadır; kural Ekim 2026 itibarıyla GİB'in e-Belge sitesinde bu şekilde yer alıyor. Bu durumda her yeni abonede alıcının e-Fatura kullanıcısı olup olmadığını kontrol eden ve doğru belgeyi kesen bir akış gerekir.

e-Fatura ve e-Arşiv Fatura akışı, bir özel entegratörle ya da kullandığınız muhasebe yazılımıyla kurulan bir entegrasyonla çözülebilir. Hangi uygulamaya tabi olduğunuzu mali müşavirinizle netleştirin. Ürünü tüketicilere de satacaksanız, abonelik, cayma hakkı ve yenileme konularında 6502 sayılı Tüketicinin Korunması Hakkında Kanun (yeni sekmede açılır) ve ona bağlı düzenlemeler de devreye girer. Bizim önerimiz, ilk birkaç müşteride tahsilatı ve faturayı yarı elle yürütmek ve otomasyonu, kurallar gerçek ödemelerle netleştikten sonra yazmaktır.

Bir SaaS ürününü yayında tutmak neler gerektirir?

Bir SaaS ürününü yayında tutmak beş iş demektir: destek vermek, kullanım limitlerini yönetmek, güncellemeleri bütün müşterilere güvenle göndermek, sistemi ayakta tutmak ve müşteri verisini KVKK'ya uygun işlemek. Bu işler ilk ödeme yapan müşteriyle başlar ve ürün yaşadıkça sürer. Biz maliyet konuşurken bu kalemlerin geliştirme bedelinden ayrı, aylık bir yük olarak ele alınmasını isteriz, çünkü teklif aşamasında en kolay unutulan kalemler bunlardır.

Destek yükü ve kullanım limitleri nasıl yönetilir?

SaaS'ta destek yükü müşteri sayısıyla birlikte büyür ve ilk aylarda genellikle kurucunun zamanının önemli bir kısmını alır. Ürüne baştan bir destek kanalı, sık sorulan sorular için kısa bir yardım sayfası ve müşterinin hangi hesapta, hangi işlemi yaparken hata aldığını gösteren kayıtlar koymayı tavsiye ederiz.

SaaS'ta kullanım limitleri ilk sürümde tanımlanmalıdır. Bir müşterinin yüklediği dosya, gönderdiği e-posta ya da tetiklediği yapay zekâ çağrısı size maliyet çıkarıyorsa, paket sınırları bu maliyeti karşılamalıdır. Her paket için bu kalemlerin sınırını ve sınır aşılınca ne olacağını ilk sürümde yazın.

Güncelleme, yedek ve çalışma süresi nasıl planlanır?

SaaS'ta tek kod tabanından çıkan bir güncelleme çoğu zaman bütün müşterilere birlikte gider, bu yüzden yayın süreci tek seferlik bir projeden daha dikkatli olmalıdır. Otomatik testler, önce bir test ortamında deneme, gerektiğinde geri alınabilen yayınlar ve veritabanı değişikliklerinin eski veriyi bozmadan uygulanması bu sürecin parçalarıdır. Sistemin ayakta olup olmadığını dışarıdan izleyen bir kontrol ve geri yüklemesi denenmiş otomatik yedek de ilk müşteriden önce hazır olmalıdır.

Müşterilerinize bir çalışma süresi taahhüdü (SLA) vermeden önce, bu taahhüdü hangi altyapı ve hangi nöbet düzeniyle tutacağınızı yazıya dökmenizi öneririz.

SaaS sahibi KVKK'da veri işleyen mi, veri sorumlusu mu?

KVKK açısından SaaS sahibi çoğu zaman iki rolde birden bulunur. Ekim 2026 itibarıyla 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun (yeni sekmede açılır) 3. maddesi veri işleyeni, veri sorumlusunun verdiği yetkiye dayanarak onun adına kişisel veri işleyen kişi olarak tanımlar. Müşterilerinizin ürüne girdiği verilerde konumunuz genellikle budur; kendi kullanıcılarınızın hesap bilgileri içinse veri sorumlususunuz.

6698 sayılı KVKK'nın 12. maddesi, verilerin başka biri tarafından işlenmesi hâlinde veri güvenliği tedbirlerinde veri sorumlusunun o kişiyle birlikte sorumlu olduğunu düzenler. Verilerin kanuni olmayan yollarla elde edilmesi durumunda ise veri sorumlusu bunu en kısa sürede ilgilisine ve Kurula bildirir. Kanun bildirimi veri sorumlusuna yüklediği için, müşterilerinizle yapacağınız veri işleme sözleşmesine ihlali onlara gecikmeden bildirme taahhüdünü koymanızı öneririz. Erişim kayıtları ve bir ihlal bildirim süreci de ilk kurumsal müşteriyle birlikte gündeme gelir; ayrıntılar için bir hukukçuya danışın.

İlk sürümde hangi kullanım olayları ölçülmeli?

SaaS'ta ürün analitiği, hangi müşterinin ürünü düzenli kullandığını ve kimin ayrılmak üzere olduğunu gösterir. İlk sürümde birkaç olay yeter: kayıt, ilk anlamlı işlem, davet edilen kullanıcı, ödeme ve iptal. Biz bu olayları ürünün kendi veritabanında tutmayı ve yalnızca gerektiğinde, KVKK açısından değerlendirerek dış bir araca göndermeyi tercih ediyoruz.

SaaS kendi kodunuzla mı, hazır bir platformla mı yapılmalı?

Uzun ömürlü bir SaaS ürünü için kendi kodunuzla, yani size ait özel yazılımla ilerlemek çoğu durumda daha sağlam bir temeldir; kod yazmadan uygulama kurmaya yarayan hazır platformlar ise fikri denemek için hızlı bir yoldur. SaaS sizin satacağınız ürün olduğu için, üzerine kurulduğu platformun sınırları doğrudan ürününüzün sınırları olur. Kendi kodunuzla yapmanın getirdikleri şunlar:

• İş kuralları size göre: fiyatlandırma, roller ve iş akışı bir platformun ayarlarına değil, müşterilerinizin ihtiyacına göre şekillenir.
• Veri sizde: verinin nerede tutulduğuna, nasıl yedeklendiğine ve nasıl dışa aktarıldığına siz karar verirsiniz; bu, KVKK görüşmelerinde ve kurumsal müşterinin güvenlik sorularında elinizi güçlendirir.
• Maliyet aynı hızla büyümez: platform ücretleri genellikle kullanıcı, kayıt ya da işlem sayısıyla artar; kendi kodunuzda maliyet sunucu ve bakım üzerinden büyür. Üç ila beş yıllık toplamı kendi rakamlarınızla karşılaştırın.
• Kendi entegrasyonlarınız: muhasebe, e-Fatura, ERP ya da müşterinin kendi sistemleriyle bağlantıyı ihtiyaç duyduğunuz derinlikte kurarsınız.
• Kendi markanız ve alan adınız: ürün, başka bir platformun adı altında değil, kendi adınızla görünür.
• Değişiklik hızı: bir müşterinin istediği özellik için bir platformun yol haritasını beklemezsiniz.
• Sahiplik: kod deposu, sunucu ve alan adı şirketinizin adına olur; ürünü satmak ya da yatırım almak istediğinizde neyin size ait olduğu bellidir.

Kendi kodunuzla ilerlemenin bir bedeli de var: ilk sürüm daha uzun sürer, başlangıç maliyeti daha yüksektir ve sistemi yayında tutacak birinin olması gerekir. Yapay zekâ destekli geliştirme, deneyimli bir ekibin elinde bu farkı daraltıyor; nerede işe yarayıp nerede yetmediğini yapay zekâ ile uygulama geliştirme yazımızda ele aldık. Bizce seçim şu durumlara göre yapılmalı:

• Hazır platform yeter: fikri birkaç hafta içinde birkaç müşteriye göstermek istiyorsanız ve ürün tek bir basit iş akışından oluşuyorsa.
• Hazır platform yeter: müşteri sayısı ve veri hacmi küçük kalacaksa, veri ayrımı ve ödeme kuralları karmaşık değilse.
• Kendi kodunuz gerekir: ürün müşteriden düzenli ödeme alacak, birden fazla firmanın verisini tutacak ve yıllarca geliştirilecekse.
• Kendi kodunuz gerekir: satış görüşmelerinde veri konumu, entegrasyon ya da özel iş kuralı soruları geliyorsa.

Bizim tavrımız şu: hazır platformu bir deney aracı olarak kullanmakta sakınca görmüyoruz. Ama ödeme yapan müşterisi olan bir ürünü, platformun sınırına dayandığı gün başka bir temele taşımak, baştan kendi koduyla kurmaktan genellikle daha zahmetli bir iştir.

SaaS geliştirme süresini ve maliyetini ne belirler?

SaaS geliştirme süresini ve maliyetini ilk sürüme alınan iş akışı sayısı, rol sayısı, abonelik kuralları, entegrasyonlar ve yayına hazırlık işleri belirler. Kapsamı yazılmamış bir ürün için rakam vermiyoruz, çünkü her rakam tahmin olur; teklifleri nasıl karşılaştıracağınızı yazılım yaptırma maliyeti yazımızda ayrıntılı anlattık. İlk sürüm, aynı büyüklükte tek seferlik bir uygulamadan daha uzun sürer, çünkü kullanıcıya görünmeyen parçalar ilk günden gerekir.

• İş akışı sayısı: ilk sürüme giren her ek akış ekran, veri ve test demektir; süreyi en çok bu büyütür.
• Rol ve kullanıcı türü: firma yöneticisi, kullanıcı ve son müşteri gibi her tür ayrı ekranlar ve yetkiler getirir.
• Abonelik kuralları: aylık tek paket hızlı kurulur; deneme süresi, kullanım bazlı fiyat ve dönem ortası paket değişikliği her biri kendi akışını ve testini ister.
• Fatura ve muhasebe entegrasyonu: karşı sistemin dokümantasyonu ve test ortamı ne kadar hazırsa entegrasyon o kadar hızlı ilerler; bu kısmın takvimi tamamen sizin elinizde değildir.
• Yayına hazırlık: izleme, yedek, yardım sayfası ve destek için iç ekran ilk müşteriden önce gerekir.
• Karar hızı: sizin tarafınızda öncelikleri belirleyecek kişinin haftada ayırabildiği zaman, süreyi teknik kararlar kadar etkiler.

SaaS teklifinde yazılım ekibine hangi sorular sorulmalı?

Bir yazılım ekibiyle SaaS projesini konuşurken şu soruları sormanızı öneririz; cevapların netliği, teklifin kapsama dayanıp dayanmadığını gösterir. Görüşmeye hazırlanırken yazılım brief şablonumuz da işinize yarar.

• Müşteri firmaların verisi birbirinden nasıl ayrılacak, bu kural hangi katmanda zorunlu kılınacak?
• Firma yöneticisi ve kullanıcı rolleri ilk sürümde var mı, kullanıcı daveti nasıl işleyecek?
• Tahsilat hangi banka ya da ödeme kuruluşu altyapısıyla yapılacak, kart verisi bizim sunucumuza uğrayacak mı?
• Başarısız ödeme, iptal ve paket değişikliği senaryoları kapsamda mı?
• e-Fatura ve e-Arşiv Fatura akışı nasıl kurulacak, hangi sistemle entegre olacak?
• Yedekler nerede tutulacak, geri yükleme ne zaman denenecek, kesintiyi kim ve nasıl fark edecek?
• Destek verirken müşterinin ekranını kayıt altında görebileceğimiz bir iç araç olacak mı?
• Kod deposu, sunucu hesapları ve alan adı kimin adına açılacak?
• Yayından sonra hangi süre için, hangi kapsamda destek verilecek?

SaaS yaparken en sık hangi hatalar yapılır?

SaaS yaparken yapılan hataların büyük kısmı sıralama hatasıdır: yanlış parçayı çok erken ya da doğru parçayı çok geç yapmak. Yeni bir projeye başlarken bu kalıpları bir kontrol listesi gibi gözden geçirmenizi öneriyoruz.

• Faturalama ve yönetim panelini çok erken yazmak: ödeme yapan tek müşteri yokken çok paketli abonelik, kupon ve ayrıntılı raporlar geliştirmek. Kurallar ilk müşterilerle zaten değişir.
• Kiracı ayrımını sonraya bırakmak: ilk sürümü tek müşteri varmış gibi yazıp ikinci müşteride bütün veri modelini yeniden ele almak.
• Destek vermenin yolunu düşünmemek: hata kayıtları, müşteri hesabını görme imkânı ve yardım sayfası olmadan her soruyu telefonla çözmeye çalışmak.
• Her müşteriye ayrı sürüm yapmak: büyük bir müşterinin isteği için kodu ayrı bir kola ayırmak. Bir süre sonra tek ürün yerine bakımı ayrı ayrı yapılan birkaç ürün ortaya çıkar.
• Fiyatı hiç denememek: ücretsiz kullanıcı toplayıp ödeme istemeyi ertelemek. Ödeme isteyene kadar talebin var olup olmadığını bilemezsiniz.
• Ürünün sahibi olmamak: öncelikleri belirleyen, müşteriyle konuşan ve gerektiğinde hayır diyebilen bir kişi atamamak.

UlvionTech olarak biz olsak ne yapardık?

Bir hizmeti SaaS'a dönüştürmek isteyen bir KOBİ ile çalışsak, işe hizmeti bugün kimlerin satın aldığını ve hangi adımı en çok tekrar ettiğinizi konuşarak başlardık. Kapsamı yazıya döker; tek bir iş akışını, tek bir paketi ve ilk günden doğru kurulmuş kiracı ayrımını içeren bir ilk sürüm önerirdik. Tahsilatı lisanslı bir ödeme kuruluşuna ya da bankaya, faturayı mali müşavirinizle kararlaştırılan akışa bırakır; çok paketli abonelik ve ayrıntılı yönetim panelini ilk ödeme yapan müşterilerden sonraya ayırırdık.

Yazılı kapsamdan sonra sabit fiyat verir; kod deposunu, sunucu hesaplarını ve alan adını ilk günden şirketinizin adına açardık. İlk on müşterinin kurulumunu sizinle birlikte izler, takıldıkları yerleri bir sonraki sürümün kapsamına yazardık. SaaS platform geliştirme hizmetimiz bu yaklaşımla çalışır. Sistemi yalnızca kendi ekibiniz ya da tek bir müşteriniz kullanacaksa, web uygulaması geliştirme daha uygun bir başlangıçtır.

Hangi durumlarda bizimle çalışmamalısınız?

Bazı durumlarda bir yazılım ekibiyle SaaS geliştirmek erken ya da gereksizdir ve bunu baştan söylemeyi doğru buluyoruz.

• Fikri henüz doğrulamadıysanız: bir tablo ve bir ödeme bağlantısıyla birkaç müşteriye hizmeti elle verip para alabildiğinizi görmek için yazılıma gerek yok.
• Bir deneme yeterliyse: kod yazmadan uygulama kurmaya yarayan bir platform, fikri birkaç müşteriye göstermek için yeter; ödeme yapan müşteriler gelince kendi koduna geçmek daha mantıklıdır.
• Ürünü sahiplenecek kimse yoksa: müşteriyle konuşacak, öncelik belirleyecek ve destek sorularını takip edecek bir kişi olmadan geliştirilen SaaS, yayından sonra sahipsiz kalır.
• Kendi yazılım ekibiniz varsa: ürünü uzun süre geliştirecek bir ekibiniz zaten varsa, onu güçlendirmek dışarıdan bir ekiple başlamaktan daha doğru olabilir.

Bu ölçütlere göre hazır olduğunuzu düşünüyorsanız, hizmetinizi kimin satın aldığını ve hangi işi en çok tekrar ettiğinizi birkaç cümleyle bize yazın; ilk görüşmede hangi parçanın ilk sürüme gireceğini birlikte netleştirelim.