"SaaS Öldü" Efsanesi: Yapay Zeka Destekli Kurum İçi Geliştirmede Başarısız Olmaktan Alınan Dersler

@emooove
JAPONCA14 Ağu 2026
134K
405
66
7
389

TL;DR

Bir CEO, yapay zeka ile kurum içi araçlar oluşturma deneyimini paylaşıyor. Oluşturma süreci kolay olsa da bakım, güvenlik ve kullanıcı deneyimi (UX) gibi konuların hala büyük engeller olduğunu ve SaaS çözümlerinin çoğu şirket için bu sorunları daha iyi çözdüğünü vurguluyor.

"SaaS öldü" ifadesi son zamanlarda trend oluyor. Argüman şu: yapay zekanın kod yazabildiği bir çağda yaşadığımız için SaaS için aylık ücret ödemeyi bırakıp ihtiyacımız olanı kendi bünyemizde kurmalıyız.

Şirketim Emooove'da son birkaç aydır iç sistemlerimizi tamamen kendi bünyemizde kurmaya odaklandık. Bunu gerçekten yapmış biri olarak hem başarıları hem de acı dersleri deneyimledim. Bugün, "SaaS öldü" anlatısına dair kendi bakış açımı bu gerçek dünya deneyimine dayanarak paylaşmak istiyorum.

Açık olmak gerekirse, bunu bir sistem kullanıcısı/kurucusu perspektifinden yazıyorum, bir SaaS sağlayıcısı olarak değil.

Herkesin Sistem Kurabildiği Muhteşem Bir Çağ

Öncelikle, bir öncül olarak, Claude Code'un ortaya çıkışı gerçekten "herkesin bir sistem kurabildiği" bir çağı başlattı. Bu bir abartı değil.

Emooove'da yalnızca iki aydır bizimle olan bir işe alım lideri, kurum içi bir ATS (Başvuru Takip Sistemi) kurdu. Mühendis olmayan, sıfır mühendislik deneyimine sahip biri. Buna rağmen, başvuranların içe aktarılmasından seçim yönetimine ve panolara kadar her şeyi yöneten işlevsel bir sistem oluşturdu.

Ayrıca, çekirdek işimiz olan satış ajansı hizmetlerinin operasyonel verimliliğini ve kalitesini artırmak için şu anda bir iç sistem geliştiriyoruz. Kendimi her gün buna adıyorum ve başlayalı iki haftadan az oldu, oldukça iyi bir şey yaratmanın eşiğinde olduğumuzu hissediyorum.

Aksi halde ayda on binlerce veya yüz binlerce yen SaaS ücreti ödetecek bir şeyi kendi içinde inşa edebiliyorken, insanların neden "SaaS öldü" demek istediğini anlamak kolay.

Ancak Her Şey Yolunda Gitmiyor

Asıl mesele bu. Gerçekten denediğimizde her şey güllük gülistanlık değildi.

1. Bakım İnanılmaz Zor

İyi ya da kötü, bir şeyleri "anında" inşa edebilirsiniz, bu yüzden hızla şekillenirler. Ancak gereksinimler tam olarak belirlenmediği için birçok pürüz vardır.

ATS'mizde şunları gördük:

  • İçe aktarılması gereken kayıtlar aktarılmadı.
  • Pano sayıları bir şekilde hatalıydı.
  • Kritik butonlar eksikti ve operasyonlar durma noktasına geldi.

"Kullanmaya başladıktan sonra fark ettiğimiz" birçok eksiklikle karşılaştık. Dahili satış destek sistemimizde ise sabah aniden erişemediğimiz ve ekranın açılmadığı bir gün bile oldu.

Elbette bunlar gereksinimleri daha dikkatli tanımlayarak veya ilerledikçe iyileştirmeler yaparak bir ölçüde çözülebilir. Ancak bu sırada normal iş operasyonları aksar. "Kolay ve hızlı" olacağını bekleyerek kurmaya başlarsanız zor durumda kalırsınız. "Kur ve bitir" zihniyetiyle değil, "kur ve düzeltmeye devam et" zihniyetiyle başlamanız gerektiğini fark ettim.

İşe alım ölçeğimiz küçük olduğu için ATS bir süre dursa bile idare edebiliriz. Ama bunun çok paydaşlı bir sistem olduğunu düşünmek bile beni ürpertiyor. Kullanıcı sayısı ve etki alanı arttıkça tek bir arızanın getirdiği kayıp büyüyor ve zorluk seviyesi fırlıyor.

Bunu iç sistemler için tolere edebilirsiniz; ancak harici satışa yönelik veya iletişim formu gibi dış dünyaya açık bir şey inşa etme konusunda son derece dikkatli olmalısınız.

2. UI/UX Asla Cilalanmıyor

Sistemi kendim kurarken şunu fark ettim: sonuç bir şekilde vasat oluyor.

Yapay zekanın ilk ürettiği ekranlar "fena değil" görünüyor, ancak gerçekte kullandığınızda detaylar hantal. Tekrar tekrar talimat vererek sonunda iyi görünmesini sağlayabilirsiniz, ancak bu yoğun bir takıntı ve zaman gerektirir. Çoğu insan muhtemelen yarı yolda taviz verecektir.

SaaS arayüzleri cilalıdır çünkü profesyonel tasarımcılar yıllarca kullanıcı geri bildirimlerini yansıtmıştır; bu bedavaya elde edilecek bir şey değil.

3. Güvenlik Sorunu

En korkutucu kısım bu.

Mühendis olmayanlar bile Claude Code'u kullanarak "doğaçlama" bir tavırla işlevler ve UI/UX oluşturabilir. Peki güvenlik konusunda da aynı şekilde yol almak mümkün mü? En azından benim için değil. Kimlik doğrulama, yetki yönetimi, güvenlik açığı yanıtı—"çalışmak" ve "güvenli olmak" tamamen farklı şeyler.

Bizim durumumuzda, şanslıyız ki güvenlik mühendisi deneyimi olan birine sahibiz ve bu kısmı onların halletmesini sağlıyoruz. Yine de bir miktar endişe kalıyor. Uzmanı olmayan bir kuruluşun, müşteri bilgilerini gelişigüzel kurulmuş bir sisteme koyup açığa çıkardığını düşünmek beni soğuk terler içinde bırakıyor.

İkili "Yaşa ya da Öl" Mantığı Yanlış

Kurum içi geliştirmenin olumsuz noktalarını sıraladım, ancak dürüst olmak gerekirse birçok iyi yanı da var.

  • İşinize tam uygun bir şey inşa edebilirsiniz.
  • Bir şeyi düzeltmek isterseniz ertesi gün yapabilirsiniz.
  • Neredeyse hiç aylık maliyet yoktur.
  • Şirket, "sistemleri kendimiz kurabiliriz" bilgi birikimini ve güvenini kazanır.

Sorun, her şeyi "SaaS yaşayacak mı, ölecek mi?" ikiliğinde basitleştirmeye çalışmak. SaaS benimsemek mi yoksa kurum içi geliştirmek mi şirketin durumuna bağlıdır. Deneyimime dayanarak dikkate alınması gereken beş nokta şunlar:

Nokta 1: İçeride mühendisleriniz var mı?

Yoksa, mühendis olmayanların gelişigüzel başa çıkamayacağı güvenlik gibi alanlarda başarısız olursunuz. En korkutucu kısım, tehlikelerin farkına varmadan işlevleri inşa edebilmektir. Belirleyici nokta, kilit alanları gözden geçirecek deneyimli birini bulup bulamadığınızdır.

Nokta 2: Paydaş sayısı

Çok fazlaysa, bir arıza meydana geldiğinde kayıp büyük olur ve zorluk seviyesi keskin bir şekilde artar. Tersine, küçük organizasyonlar daha kolay deney yapabilir çünkü işler durursa özür dileyebilirler. Etki alanı küçük operasyonlarla başlamak gerçekçidir.

Nokta 3: Dışa dönük ve iç sistemler

İç sistemlerde bir şey olursa risk sınırlıdır. Ancak dışa dönük her şey için tek bir bilgi sızıntısı geri döndürülemez olabilir. SaaS, sorumluluğun bir kısmını satıcıya devretmenize olanak tanırken, kurum içi geliştirmede her şey sizin sorumluluğunuzdadır. SaaS'ın "kanıtlanmış gönül rahatlığının" değeri dışa dönük her şey için artar.

Nokta 4: Bakım için iş gücü ayırabilir misiniz?

Bakım, tahmin ettiğinizden daha fazladır. Kurum içi geliştirme "kur ve bitir" değil, "düzeltmeye devam et"tir. Bu öngörüyle başlayabilir misiniz? İsteksiz bir tavırla başlarsanız, kusurları düzeltmeye gömülürsünüz ve bu çekirdek işinize baskı yapar.

Nokta 5: Yapay zeka geliştirmeyi seviyor musunuz/istiyor musunuz?

Sonunda iş buna geliyor. Düşündüğünüzden daha sıkıcı ve zor ve yapay zeka söz dinlemediğinde sinir bozucu (gülüyor). Buna rağmen sonuna kadar götürebilir misiniz? Bundan keyif alanlar için harika bir çağ, ancak bunun yalnızca görev bilinciyle sürdürülebilecek bir şey olduğunu düşünmüyorum.

Özet: SaaS Ölmedi. Sadece Daha Fazla Seçenek Var.

Başlıkta "başarısız oldu" kelimesini kullandım, ancak daha doğrusu "birçok kez neredeyse başarısız oldu". Kurum içi geliştirmeye devam ediyoruz çünkü deneyimli mühendislerimiz var, organizasyonumuz hâlâ küçük, ağırlıklı olarak iç kullanım için, bakım için zaman ayırmaya hazırız ve her şeyden önce bunu yapmak istiyorum. Beş noktanın da karşılandığı ayrıcalıklı bir ortamda olduğumuz için yaptığımızı söyleyebilirsiniz.

Tersine, bu koşulları karşılamayan bir şirket "SaaS öldü" sözünü harfiyen alıp çekirdek operasyonlarını kurum içinde kurmaya çalışırsa, gerçekten başarısız olur.

SaaS ölmedi. Sadece "inşa etme" seçeneği artık herkese açık. Şirketinizin durumunu sakin bir şekilde değerlendirin ve hem SaaS'ı hem de kurum içi geliştirmeyi kullanın. Bu kullanışlı ama bir o kadar da istikrarsız çağla başa çıkmanın doğru yolu bu değil mi?

YouMind’da yeniden üret

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
Üreticiler için

Markdown'ınızı temiz bir 𝕏 makalesine dönüştürün

Kendi uzun yazılarınızı yayımlarken görselleri, tabloları ve kod bloklarını 𝕏 için biçimlendirmek zahmetlidir. YouMind, eksiksiz bir Markdown taslağını temiz ve hemen paylaşılabilir bir 𝕏 makalesine dönüştürür.

Markdown'dan 𝕏'e deneyin

Çözülecek daha fazla kalıp

Son viral makaleler

Daha fazla viral makale keşfet