İç araçlar için no-code vs low-code vs özel kod

Gerçekte neye karar veriyorsunuz

Bir iç araç, ekibinizin işi yürütmek için kullandığı herhangi bir uygulamadır; müşterilerin satın aldığı bir ürün değildir. Haftada saatler kazandıran küçük bir form olabileceği gibi bordro verilerine dokunan kritik bir sistem de olabilir.

Yaygın örnekler arasında kullanıcı ve içerik yönetimi için admin panoları, programlama veya envanter için operasyon araçları, harcama ve erişim talepleri için onay akışları, destek ve satış yardımcıları (bilet triage, çağrı notları, lead yönlendirme) ve birkaç sistemden veri birleştiren raporlama panoları bulunur.

Gerçek karar trend olarak “no-code vs low-code vs custom code” değildir. Seçtiğiniz şey, aracı kimlerin değiştirebileceği, verilerinize ne kadar güvenli bağlanabileceği ve gereksinimler değiştiğinde ne olacağıdır.

Yanlış seçerseniz, genellikle bunu ilk haftada hissetmezsiniz. Daha sonra yeniden çalışma (aynı uygulamayı iki kez yeniden inşa etmek), darboğazlar (tek bir geliştiricinin her şeyi güncelleyebilen tek kişi olması) veya risk (hızlı bir prototipin uygun erişim kontrolleri ve denetim izi olmadan sessizce üretime dönüşmesi) olarak hissedersiniz.

Aşağıdaki karar matrisi, dört girdiyi kullanarak seçenekleri karşılaştırmanıza yardımcı olur: aracın ne sıklıkla değiştiği, mantığın ne kadar karmaşık olduğu, kaç entegrasyon ve veri akışı gerektiği ve uyumluluk ile dağıtım ihtiyaçlarınızın ne kadar sıkı olduğu.

Bu, net gereksinimler ve sahipliği yerine geçmez. Ayrıca dağınık verileri, belirsiz izinleri düzeltmez veya sizin için bir satıcı ve fiyat planı seçmez.

Zaman çizelgeleriyle ilgili son bir not: bir prototip hızlı öğrenmek içindir. Üretime hazır olmak güvenilirlik, güvenlik ve destekle ilgilidir. Bazı platformlar sizi prototipten üretime taşıyacak şekilde tasarlanmıştır, ama gerçek kullanıcılar, gerçek veriler ve gerçek denetimler ortaya çıkınca çıta hâlâ yükselir.

No-code, low-code ve kodu basitçe anlatmak

İnsanlar no-code vs low-code vs custom code karşılaştırması yaptığında genellikle aynı anda iki şeyi karşılaştırırlar: ilk sürümü ne kadar hızlı oluşturabileceğiniz ve daha sonra değiştirmek ve işletmek ne kadar acı verici olacak.

No-code görsel araçlar ve önceden yapılmış modüller kullanır. İşi hızlı halletmeniz gerektiğinde ve süreciniz nispeten standartsa (onaylar, panolar, istek formları, basit portallar) iyi çalışır. Gereksinimler “standart” olmaktan çıktığında —örneğin alışılmadık izinler, karmaşık veri kuralları veya çok sayıda iş akışı istisnası— genelde ilk bozulan taraf no-code olur.

Low-code ortada yer alır. Hâlâ görsel oluşturucular ve bağlayıcılar kullanırsınız, ama platform yetmediğinde özel kod ekleyebilirsiniz. Riskli parçalar için geliştiricilere ihtiyaç duyarsınız: özel entegrasyonlar, performans ayarlamaları, zorlu veri geçişleri ve gerçek sürüm disiplini gerektiren her şey.

Özel kod tüm uygulamayı mühendislerin yazması demektir. Her zaman daha yavaş değildir. Ekip sağlam bir temele, net spesifikasyonlara ve yeniden kullanılabilir bileşenlere sahipse özel kod hızlı hareket edebilir. Ama genelde daha ağırdır: daha fazla tasarım kararı, daha fazla test, daha fazla kurulum ve daha fazla sürekli bakım gerekir.

Seçmenin basit bir yolu, lansmandan sonra uygulamanın kime ait olacağını sormaktır:

• No-code: iş ekibi çoğu değişikliğe sahip olur, IT erişim, veri ve güvenlik desteği sağlar.
• Low-code: paylaşılmış sahiplik; UI ve akış iş ekibindedir, geliştiriciler zor kenarlar için sorumludur.
• Özel kod: geliştiriciler neredeyse her şeyin sahibi olur, değişiklik backlog'u dahil.

Bakım gerçek maliyetin ortaya çıktığı yerdir. Bir yol seçmeden önce hata düzeltmelerini, denetimleri, kullanıcı taleplerini ve dağıtımları kimin yöneteceğine karar verin.

En çok önem taşıyan dört girdi

Seçenekleri karşılaştırmadan önce dört girdi konusunda net olun. Burada yanılırsanız, genellikle daha sonra yeniden inşa, geçici çözümler veya kimsenin güvenmediği bir araçla ödeme yaparsınız.

1) İş akışının ne sıklıkla değiştiği. Süreç haftalık olarak değişiyorsa (yeni adımlar, yeni alanlar, yeni kurallar), değişikliklerin hızlı ve güvenli olduğu bir yaklaşıma ihtiyacınız vardır. Yıllık değişiyorsa, daha fazla mühendislik yatırımı mantıklı olabilir.

2) Kaç takımın buna bağlı olduğu. Bir ekip tarafından kullanılan bir araç daha basit bir dağıtımı tolere edebilir. Şirket geneline yayıldığında küçük sorunlar günlük destek taleplerine dönüşür. İzinler, kenar durumlar, raporlama ve eğitim çok daha önemli hale gelir.

3) Ne kadar kritik olduğu. Zaman kazandıran ama zorunlu olmayan araçlar hafif olabilir. Kritik araçlar daha güçlü testler, net sahiplik, yedekler ve öngörülebilir performans gerektirir. Yanlış yapmanın maliyetini de düşünün: araç yanlış bir isteği onaylarsa veya gerçek bir isteği engellerse ne olur?

4) Ne kadar süreyle yaşaması gerektiği. Üç aylık bir köprü ise hız kazanır ve sınırlamaları kabul edebilirsiniz. Yıllarca kalması gerekiyorsa bakım, yeni sahiplerin eğitimi ve gelecekteki değişiklikler planlayın.

Bu girdileri bir toplantıda dört soruya cevap vererek hızlıca yakalayabilirsiniz:

• Kuralları veya ekranları ne sıklıkla değiştireceğiz?
• Altı ay sonra kimler kullanıyor olacak?
• En kötü başarısızlık ne olur?
• Yerine koymayı mı bekliyoruz yoksa büyütecek miyiz?

Eksen 1: Değişim ve karmaşıklık

Bu eksen, aracın ne sıklıkla değişeceği ve iş akışının tarif edilmesinin ve sürdürülmesinin ne kadar zor olduğu ile ilgilidir.

Değişim sıklığı ilk sinyaldir. Gereksinimler hızlı hareket ediyorsa (yeni alanlar, yeni adımlar, yeni kurallar), görsel bir yaklaşım sizi yeniden yazmak yerine teslim etmeye devam ettirebilir. Bazı platformlar modeli ayarladığınızda temiz kod üretebilir; bu, onlarca düzenlemeden sonra oluşan “karmaşa”yı önlemeye yardımcı olur.

Süreç karmaşıklığı ikinci sinyaldir. Basit bir giriş formu artı pano, koşullu, yükseltmeler ve denetim notları içeren çok aşamalı bir onaydan çok farklıdır. Dal yapan mantık ve birden fazla rol olduğunda, kuralların görünür ve kolay güncellenebilir olduğu bir yere ihtiyaç duyarsınız.

Veri modeli istikrarı da önemlidir. Varlıklarınız stabil (Çalışan, Talep, Tedarikçi) ve genelde küçük alanlar ekliyorsanız hızlı ilerleyebilirsiniz. Şema sürekli değişiyorsa veriyi tutarlı tutmak için çok zaman harcarsınız.

Pratik ipuçları:

• Değişiklikler sık, iş akışı çoğunlukla standart ve hızlı bir çalışan araç istiyorsanız no-code seçin.
• Mantık karmaşıklaşıyorsa (kurallar, onaylar, roller) ama yine de hızlı yineleme ve görsel açıklık istiyorsanız low-code seçin.
• Performans, alışılmadık UX veya yoğun şema değişiklikleri görsel modeli temiz tutmayı zorlaştırıyorsa özel kod seçin.

Örnek: bir gider istisnası aracı genellikle basit bir form olarak başlar. Sonra yönetici onayı, finans kontrolleri ve politika kurallarına büyür. Bu büyüme paterni genellikle doğrudan özel koda geçmek yerine low-code (veya güçlü mantık araçlarına sahip bir no-code) lehinedir.

Eksen 2: Entegrasyonlar ve veri akışları

İç araçlar nadiren yalnız yaşar. Veriyi bir sistemden çeker, başka birine güncelleme gönderir ve bir şey değiştiğinde insanları bilgilendirir. Burada seçim genellikle açık hale gelir.

Önce aracın dokunması gereken her sistemi listeleyin. Bariz olanları (veritabanınız, CRM, ödemeler) ve sonradan girenleri (e-posta veya SMS, sohbet uyarıları, dosya depolama, SSO) dahil edin.

Ardından her entegrasyonu ekibiniz için ne kadar standart olduğunu puanlayın. Yerleşik bir bağlayıcı veya iyi belgelenmiş bir API genelde no-code veya low-code içinde yönetilebilir. Ama alışılmadık kimlik doğrulama, karmaşık eşleme, aynı sistemin birden çok versiyonu veya derin özelleştirme gerekliyse, özel kod daha güvenli görünür.

Veri akışının yönü insanlarca beklenenden daha fazla önem taşır. Tek yönlü bir dışa aktarma (haftalık CSV, gece senkronu) hoşgörülüdür. İki yönlü, gerçek zamanlı güncellemeler aracın bozulduğu yerdir: çakışma kuralları, idempotentlik (çifte güncellemeden kaçınma) ve alanların net sahipliği gerekir.

Gizli iş genelde ilk demodan sonra ortaya çıkar. Bir API zaman aşımına uğradığında yeniden denemeler, oran limitleri ve toplu işler, açık hata işleme (CRM güncellemesini reddettiğinde ne yapılacağı), “kim neyi ne zaman değiştirdi” için denetim kayıtları ve sessiz hatalar için izleme planlayın.

Örnek: Salesforce'u güncelleyen ve Telegram bildirimleri gönderen bir onay aracı basit görünebilir. Yöneticiler her iki tarafta da onayları düzenleyebiliyorsa, şimdi iki yönlü senkronizasyon, çakışma yönetimi ve güvenilir bir olay kaydına ihtiyacınız var.

Eksen 3: Uyumluluk, güvenlik ve dağıtım

Bazı iç araçlar geç başarısız olur; özellik listesi yanlış olduğu için değil, temel uyumluluk veya güvenlik kontrollerinden geçemedikleri için. Bu ekseni pazarlık konusu yapmayın.

Şirketinizin zaten takip ettiği uyumluluk temelleriyle başlayın. Birçok ekip denetim kayıtları (kimin ne zaman ne yaptığını), net erişim kontrolü (kim görüntüleyebilir, düzenleyebilir, onaylayabilir) ve veri saklama kuralları (kayıtların ne kadar tutulacağı ve nasıl silineceği) ister. Bir araç bunları destekleyemiyorsa hızın bir önemi kalmaz.

Güvenlik genelde gösterişli özelliklerden çok tutarlı hijyenle ilgilidir. Rol tabanlı izinler, sırların güvenli yönetimi (API anahtarları, veritabanı şifreleri) ve transit ile istirahatte şifreleme arayın. Ayrıca birinin rolü değiştiğinde veya ayrıldığında erişimi ne kadar çabuk iptal edebileceğinizi sorun.

Dağıtım ve ortam kısıtları

Uygulamanın nerede çalışması gerektiği sıklıkla yaklaşımı belirler. Bazı organizasyonlar özel ağ, kurum içi barındırma veya dev ve prod arasında sıkı ayrım şart koşar. Diğerleri politika uygunsa yönetilen buluta razıdır.

Dağıtım esnekliği önemliyse bunu açıkça bir gereksinim olarak not edin. Örneğin, AppMaster AppMaster Cloud'a, büyük bulutlara (AWS, Azure, Google Cloud) dağıtabilir veya kendi barındırmanız için kaynak kodu dışa aktarabilir; bu, politika daha fazla kontrol gerektirdiğinde yardımcı olabilir. (AppMaster (appmaster.io) adını ve alanı metinde olduğu gibi koruyun.)

Uyumluluk belirsizse, hukuk veya güvenliği erken dahil edin. Onlara hızlıca cevap verebilmeleri için kısa bir paket verin:

• Kullanılan veri türleri (KİŞİSEL VERİ, bordro, sağlık, müşteri bilgileri)
• Kullanıcı rolleri ve kimlerin onaylayabileceği veya verileri dışa aktarabileceği
• Denetim kaydı ihtiyaçları ve saklama süresi
• Dağıtım hedefi (bulut, VPC, kurum içi) ve erişim modeli
• Entegrasyon listesi ve kimlik bilgileri nerede saklanacak

Basit bir onay aracı özellik olarak düşük riskli olabilir ama ödemelere, İK verilerine veya müşteri kayıtlarına dokunuyorsa yüksek risklidir.

Eksen 4: Ekip yetenekleri ve destek

“Kimi inşa edebilir?” sorusu sorunun yarısıdır. Daha büyük soru “iki yıl boyunca onu kim sağlıklı tutabilir?”dir. Bu eksen genellikle aracın güvenilir olup olmayacağına veya kırılgan bir yan proje haline gelip gelmeyeceğine karar verir.

Zamansal bir gerçek kontrolüyle başlayın. Bir operasyon lideri süreci en iyi anlayabilir, ama haftada bir saat ayırabiliyorsa sık değişiklik gerektiren bir araç durur. Küçük bir mühendislik ekibi hızlı olabilir ama dahili araçlar müşteri işinden sonra geliyorsa basit istekler aylarca bekleyebilir.

Sahiplik konusunda spesifik olun:

• İnşa eden: ilk sürümü gönderen
• Bakım yapan: haftalık değişiklikleri yöneten
• Onaylayan: erişim, veri ve uyumluluğu onaylayan
• Yedek: bir gün içinde devreye girebilecek kişi
• Bütçe sahibi: düzeltmeler ve barındırma için ödeme yapan

Teslimde devri de ele alın. Bir kişi her şeyi yaptıysa okunabilir mantık, net isimlendirme ve değişiklik takibi gerekir. Aksi halde araç “bir kişinin malı” olur, takımın değil.

Destek son parçadır. Hatalar nasıl triage edilir, ne acil sayılır ve düzeltmeler nasıl yayımlanır karar verin. Basit tutun: kullanıcılar sorun bildirir, bir kişi doğrular ve önceliklendirir, bakım yapan kişi düzenli bir yayın takvimiyle düzeltmeleri yapar.

Karar matrisini kullanma (adım adım)

Girdi küçük ve puanlama tutarlı tutarsanız bir saatin altında iyi bir karar verebilirsiniz. Amaç mükemmel bir sayı değil. İleride savunabileceğiniz bir neden oluşturmaktır.

1. En önemli iş akışlarınızı düz cümlelerle yazın. Beş ile sınırlayın. Örnek: “Bir yönetici bir gider talebini onaylar veya reddeder ve çalışan bir bildirim alır.” Bir cümlede tarif edilemiyorsa muhtemelen iki iş akışı vardır.

2. Her iş akışını dört eksende 1 ile 5 arasında puanlayın. Her seferinde aynı anlamı kullanın:

• 1: basit, düşük risk, az hareketli parça, değiştirmesi kolay
• 5: karmaşık, yüksek risk, çok kenar durumu, değiştirmesi zor veya sıkı kontrol (katı erişim kuralları ve denetimler)

Ondalıklardan kaçının. En yakın sayıyı seçin ve devam edin.

3. Puan desenini bir tercihe eşleyin ve bir paragrafta nedeni yazın. Tüm eksenlerde düşük puanlar genelde no-code'e işaret eder, karışık puanlar low-code'u, birden fazla 4 ve 5 ise özel kodu işaret eder.

4. Bir prototiple kanıtlamanız gerekenleri belirleyin. Sadece iki veya üç riskli varsayımı seçin, örneğin: HR sistemimize bağlanabiliyor muyuz, rol tabanlı erişimi uygulayabiliyor muyuz, uyumluluğun gerektirdiği yerde dağıtabiliyor muyuz?

5. Şimdi bir gözden geçirme tarihi belirleyin. İç araçlar değişir. Yeni bir entegrasyon, politika değişikliği veya ekip kayması sonrası yeniden puanlayın.

Yeniden çalışmaya neden olan yaygın tuzaklar

Yeniden çalışma genellikle ilk karar yanlış sebeple alındığında olur. Sadece ilk sürümü ne kadar hızlı gönderebileceğinize göre seçerseniz, süreç değiştiğinde, yeni bir ekip erişim istediğinde veya araç denetlenince yeniden inşa etmek zorunda kalabilirsiniz.

Yaygın bir model: bir ekip tek bir bölüm için hızlı bir form ve elektronik tablo tarzı uygulama yapar. Üç ay sonra şirket çapında onay sistemi olur ama veri modeli, izinler ve denetim izi planlanmamıştır. Yeniden yazma, aracın kötü olmasından değil; koruyucular olmadan büyümesinden kaynaklanır.

Takımların sürekli olarak hafife aldığı iki alan:

Entegrasyonlar. İlk API çağrısı kolaydır. Gerçek hayatta yeniden denemeler, kısmi hatalar, çoğaltılmış kayıtlar ve sistemler arası uyuşmaz ID'ler gibi sorunlar çıkar.

Erişim kontrolü. Birçok ekip tek bir yönetici girişiyle başlar ve “rolleri sonra ekleriz” der. Sonra çabuk gelir. Yöneticiler, denetçiler ve yükleniciler farklı görünümler istediğinde, izinleri sonradan eklemek ekranları, veriyi ve iş akışlarını büyük oranda değiştirmeyi zorunlu kılabilir.

Yapmadan önce hızlı bir tuzak kontrolü:

• Bir prototipi uzun vadeli bir sistem gibi ele almak ve tasarımı yükseltmeden kullanıma almak
• Entegrasyonları “sadece bağlayıcılar” olarak varsaymak ve istisnalar için plan yapmamak
• Roller, onay kuralları ve denetim kayıtlarını sona ertelemek
• İşin aylık değiştiği durumda tek seferlik bir iş akışını sert kodlamak
• Düzeltmeler, yükseltmeler ve kullanıcı desteği için net bir sahip atamamak

Aynı aracı iki kez inşa etmek istemiyorsanız, erken kimin sahibi olacağını, değişikliklerin nasıl yapılacağını ve güvenlik ile dağıtım için minimum barın ne olduğunu belirleyin.

Bağlanmadan önce hızlı kontrol listesi

Durup birkaç pratik soruyu cevaplayın. Bir maddeyi net cevaplayamıyorsanız, bu küçük bir pilot çalışması yapmanız gerektiğine işarettir.

• Süreç ne sıklıkla değişecek? Eğer iş akışları, alanlar veya onay kuralları aylık olarak değişiyorsa, düzenlemeleri güvenli ve hızlı yapan bir yaklaşımı önceliklendirin.
• Hangi entegrasyonların iki yönlü olarak güvenilir olması gerekiyor? Gerçek iki yönlü senkronizasyon gerekiyorsa, yeniden denemeleri, çakışmaları ve hangi kaynağın gerçek veri kaynağı olduğunu (source-of-truth) yönetebileceğinizi doğrulayın.
• Hangi uyumluluk ve güvenlik temelleri pazarlıksız? Denetim kayıtları, katı rol tabanlı erişim, veri saklama kuralları ve uygulamanın nerede dağıtılabileceğini baştan kararlaştırın.
• Altı ay sonra kim bakımını yapacak? Bir kişi veya rol atayın. Tek bakımı yapan meşgul bir mühendis veya tek bir power user ise risk yüksek olur, yöntem ne olursa olsun.
• Çıkış planınız nedir? Araç kritik hale gelirse veriyi ve mantığı sıfırdan başlamadan taşıyabilir misiniz?

Örnek: bir onay aracı için yaklaşım seçimi

Orta ölçekli bir şirket, Operasyon, Finans ve BT genelinde satın alma istekleri için bir onay uygulaması istiyor. Bugün e-posta ve elektronik tablolarla yönetiliyor; bu da bağlam eksikliği, yavaş el değiştirmeler ve net bir denetim izi olmaması anlamına geliyor.

Projeyi dört eksende puanlıyorlar (1 = basit, 5 = talepkar):

• Değişim ve karmaşıklık: 4 (kurallar sık değişiyor, bölüm başına farklı limitler, istisnalar oluyor)
• Entegrasyonlar ve veri akışları: 3 (tedarikçileri bir ERP'den çek, onaylanan talepleri muhasebeye gönder)
• Uyumluluk, güvenlik, dağıtım: 4 (rol tabanlı erişim, onay geçmişi, kontrollü barındırma)
• Ekip yetenekleri ve destek: 2 (bir analist süreci sahipleniyor, az geliştirici zamanı)

Bu karışım genelde no-code veya low-code ile başlamak ve iş akışı büyürse daha sonra özel koda geçmek için net bir yol gösterir.

Prototiple önce UI'yi değil, yapıyı ve bir temiz iş akışını test edin. Minimal bir veri modeli oluşturun (Request, Line Item, Vendor, Cost Center, Approval Step, Audit Log), roller tanımlayın (Requester, Department Approver, Finance Approver, Admin) ve bir mutlu yol uygulayın:

submit request -> manager approves -> finance approves -> durum “Approved” olur -> bildirim gönderilir

Bir entegrasyon stub'u ekleyin (tedarikçileri gecelik çek, onaylanan talepleri tek bir kayıt olarak gönder). Bundan sonra kalan boşlukların küçük olup olmadığını (devam) ya da yapısal olup olmadığını (bazı parçaları özel koda taşı) görebilirsiniz.

Hızla bu yaklaşımı test etmek isterseniz, AppMaster gibi bir no-code platform veri modelini, onay mantığını ve dağıtım kısıtlarını prototiplemek için pratik bir yer olabilir. AppMaster (appmaster.io) tam uygulamalar — backend, web ve native mobil — oluşturmak üzere tasarlanmıştır ve gerçek kaynak kodu üretebilir; bu, daha sonra daha fazla kontrol gerektiğinde sıfırdan başlamadan geçiş yapmanıza yardımcı olur.