- SaaS’ın LLM ile ikame edileceği iddiasına şüpheyle yaklaşıyordum; ancak yıllık 120 dolarlık LinkedIn/X referans gösterimi hizmetini 20 dakikada kendi kodumla değiştirme deneyimimi paylaşıyorum
- Yerine geçen çözümün hedefi olan hizmette ödeme sistemi 2023’ten beri bozuktu ve müşteri desteği de sadece kırık bağlantı gönderecek düzeydeydi
- Codex kullanarak mevcut referansları JSON dosyalarına ayırıp build zamanında HTML üreten modüler bir yapıya geçtim; görsel çıktı eskisiyle aynı
- Geliştiriciler için hızlı ve ilgi çekici bir iş olsa da, geliştirici olmayanlar için LLM’in ürettiği kodu doğrulamak önemli bir giriş engeli olabilir
- Sürekli değer üretemeyen statik karakterli mikro SaaS’lar, LLM çağında ilk ikame edilme riskiyle karşı karşıya
SaaS’ın LLM ile ikame edileceği fikrine dair önceki şüpheler
- SaaS’ın LLM ile ikame edileceği teorisinin özü şu: SaaS saf bir yazılım ürünüdür ve LLM’ler özelleştirilmiş yazılım geliştirme maliyeti ile süresini dramatik biçimde düşürdüğü için, SaaS sağlayıcılarının büyük bölümü ortadan kalkacaktır
- Buna karşı çıkan görüş ise Workday gibi İK yazılımlarının yalnızca yazılım olmadığını; ülkelere göre mevzuat uyumunu (izin ücreti, maaş bordrosu vb.) garanti ettiğini ve dış/iç koşullardaki değişimlere göre sürekli güncellendiğini savunuyor
Shoutout.io kullanım deneyimi ve ayrılma nedeni
- pragmaticengineer.com’da LinkedIn ve X gönderilerine dayalı referans bölümü göstermek için Shoutout.io’yu 4 yıl boyunca yıllık 120 dolara kullandım
- Giriş yapmam yılda yaklaşık 1 kez oluyordu; son girişimin nedeni masraf kaydı için yıllık faturayı kontrol etmekti
- Ödeme bölümü 2023’ten beri bozuk halde bırakılmıştı; destek ekibine e-posta gönderdim ama yanıt olarak kırık bir bağlantı aldım
- Gelecek yıl ücretin ne kadar olacağını bile görememek, SaaS’ı bırakmamın doğrudan tetikleyicisi oldu
Codex ile 20 dakikada yapılan ikame çalışması
- Tüm SaaS’ı değil, yalnızca kendi somut kullanım senaryomu (referans gösterimi, yeni referans ekleme, tasarımı koruma) yeniden kurma yaklaşımını benimsedim
- Codex’ten üçüncü taraf bağımlılıklarını kaldırıp çözümü GitHub deposu içinde barındıracak bir plan hazırlamasını istedim
- Referansları ayrı bir JSON dosyasında yönetip derleme zamanı build aşamasında HTML üreten modüler bir yapıya dönüştürdüm
- Yerel build aşaması ekleme, Netlify build tetikleyicisi ayarlama, test, UX düzenlemeleri, şema oluşturma ve dağıtım dahil toplam 20 dakika sürdü
- Nihai çıktı görsel olarak eskisiyle aynıydı ve üçüncü taraf bağımlılığı tamamen kaldırıldı
- Müşteri destek ekibi düzgün bağlantıyı gönderdiğinde (2 saat sonra), geçiş zaten tamamlanmıştı
Yazılım mühendisleri için çıkarımlar
- Geliştiriciler gelecekte güncelleme yaparken komut satırı ve yapay zeka ajanlarını kullanarak kod tabanına referans eklemeye ve sonucu doğrulamaya alışkın; ancak geliştirici olmayanlar için LLM’in ürettiği kodu doğrulamak önemli bir giriş engeli
- Geliştiriciler bir SaaS’ı kendi kodlarına “port etme” konusunda, geliştirici olmayanlara kıyasla çok daha hızlı
- İlk denemede Codex bunu yanlış biçimde flexbox modeliyle uyguladı ve UI yerleşim framework’ünü doğrudan benim belirlemem gerekti
- Geliştirici olmayanlar da bunu çözebilir, ancak daha uzun süreceği tahmin ediliyor
- Üçüncü taraf bir özelliği doğrudan yeniden yazmak eğlenceli ve öğretici; ayrıca araçların gerçek performansını deneyimleme fırsatı sunuyor
SaaS işi için çıkarımlar
- Tüm bir SaaS’ı yeniden inşa etmekle, yalnızca belirli bir kullanım senaryosunu yeniden inşa etmek arasında zorluk açısından büyük fark var
- Shoutout; 10’dan fazla platformdan alıntı ekleme, kimlik doğrulama, ödeme gibi 10 kat daha fazla işleve sahip
- Referansları gösterdikten sonra sürekli değer üretmeyen statik SaaS’lar ikame edilmeye en açık olanlar
- Buna karşılık mevzuat uyumu, analiz, bildirim gibi gerçek zamanlı iş desteği sağlayan işlevler varsa ikame çok daha zor hale geliyor
- SaaS alım-satım iş modelinin kârlılığı düşebilir
- Shoutout, 2020’de bağımsız bir geliştirici tarafından kuruldu, 2022’de bir product studio’ya satıldı, 2025’te ise başka bir geliştiriciye yeniden satıldı
- Kullanıcı açısından bakıldığında ödeme sisteminin bozuk olması dışında hiçbir değişiklik yoktu
- Yeni sahipler yatırım yapmadan gelir artışı beklemiş olabilir; ancak ürün ihmal edilirse kullanıcılar ayrılır ve LLM ile kolayca ikame edilebilir hale geldiği bir an gelir
- "Kırık camlar (Broken Windows)"ı görmezden gelmenin geçmişe kıyasla çok daha az tolere edildiği bir dönemdeyiz
4 yorum
Bakım maliyeti de bir maliyet sonuçta
Yazılım edinimine her zaman 5 yıllık bir TCO perspektifinden bakmak gerekir. Yoksa gerçekten ileride patlayacak bir "bomba" biriktirmekten başka bir şey yapmış olmazsın.
Gerçekten çok basit düşünmüş sanırım hahaha
Bunu bir çalışan mı yazdı? Bir kez doğrudan kurduktan sonra, ileride o işlevin artık dış bir şirket yerine kurum içinde çalışır durumda tutulup yönetilmesi gerekecek; peki bu zaman ve para gerektirmeyen bedava bir şey mi??