16 Ara 2025·8 dk
Tam Mühendislik Ekibi Olmadan Dahili Web Uygulamaları Oluşturun
Tam bir mühendislik ekibine ihtiyaç duymadan şirket içi web uygulamaları oluşturmanın pratik yolu—gereksinimler, platformlar, güvenlik, yaygınlaştırma ve bakım.
Tam bir mühendislik ekibine ihtiyaç duymadan şirket içi web uygulamaları oluşturmanın pratik yolu—gereksinimler, platformlar, güvenlik, yaygınlaştırma ve bakım.
Dahili araç, ekibinizin işi yürütmesi için kullandığı herhangi bir web uygulamasıdır—müşteriler için değil, çalışanlar için yapılmıştır. Genellikle şirket verilerine bağlanır, bir süreci uygular (kimin ne yapabileceğini belirler) ve formlar, tablolar ve panolar gibi basit ekranlarla görünürlük sağlar.
Elektronik tablolar ve e‑postayla muhtemelen hâlihazırda yaklaşık olarak yürüttüğünüz bazı günlük dahili araçlar:
Her süreç için dahili bir web uygulamasına ihtiyaç yok. Ama muhtemelen ihtiyaç duyarsınız eğer:
Dahili araçlar genellikle operasyonlara ilk faydayı sağlar; ancak finans, İK, BT ve müşteri destek ekipleri kısa sürede etkileri hisseder: daha az devralma, daha az hata ve güncellemeleri kovalamaya daha az zaman harcanması.
İnşa etmeden önce bir veya iki metrik seçin:
Bu metriklerde bir ay içinde iyileşme ölçebiliyorsanız, doğru türde bir araç inşa ediyorsunuz demektir.
Bir dahili araç projesini yavaşlatmanın en hızlı yolu, “önemli” ama belirsiz bir şeyle başlamaktır (ör. “yeni bir operasyon sistemi”). Bunun yerine, bitirip yayına alabileceğiniz, öğrenebileceğiniz tek bir iş akışını seçin—sonra genişletin.
Haftalık (veya günlük) olarak gerçekleşen, net bir sahibi olan ve görünür acı yaratan bir süreç arayın: elektronik tablolar arasında kopyala‑yapıştır, sohbette onay kovalamaca, ya da saatler süren raporlama. İyi bir ilk kullanımın doğal bir bitiş durumu olmalı ve başarısı için on farklı ekibe bağlı olmamalı.
Örnekler: satın alma talepleri, erişim talepleri, olay kayıtları, onboarding kontrol listeleri, basit envanter takibi, içerik onayları.
Herhangi bir şeyi inşa etmeden önce mevcut adımları yazın:
Bu mükemmel dokümantasyonla ilgili değil—israfı ve kaldırabileceğiniz devralmaları görmekle ilgili.
Her kayıt veya talep için net bir sonuç olmalı. Örneğin: “Bir satın alma talebi, onaylandığında, bir PO numarası atandığında ve talep eden bilgilendirildiğinde tamamlanmış sayılır.” Eğer “tamamlandı”yı tanımlayamıyorsanız, uç durumları kapsamak için sürekli özellik ekleyeceksiniz.
İlk yayında neyi dahil etmeyeceğinizi baştan kararlaştırın: gelişmiş izinler, karmaşık raporlama, çok bölümlü yönlendirme veya geçmiş verilerin temizlenmesi gibi. Sürüm 1, iş akışının en acı veren kısmını değiştirmeli—tüm olası varyasyonları değil.
Bir no-code ya da low-code oluşturucuya dokunmadan önce, uygulamanın ne yapması gerektiğini ekip üyelerinizin zaten kullandığı dille yazın. Açık gereksinimler yeniden işi azaltır ve kimsenin ihtiyacı olmayan özellikleri inşa etmemenizi sağlar.
Çoğu dahili araçta tekrarlayan küçük bir rol seti olur:
Her rol için bir cümle yazın: neye ihtiyaçları var ve hangi işlemleri yapmamaları gerekir.
Dili sade tutun ve her hikayeyi odaklı bırakın:
Zorunlu alanları (ve nedenlerini) listeleyin, sonra temel kuralları ekleyin:
İyi bir v1 genellikle sadece şunları gerektirir:
Bu ekranları bir sayfada tanımlayabiliyorsanız, inşa etmeye hazırsınız demektir.
Ekranları oluşturmadan önce, dahili uygulamanızın hangi veriyi tutacağını ve verinin nerede yaşayacağını kararlaştırın. Çoğu dahili araç, UI kötü olduğu için başarısız olmaz—insanlar hangi dosyanın, sistemin veya sekmenin “gerçek” olduğunu bilmediği için başarısız olur. Burada biraz planlama daha sonra sürekli yeniden işi önler.
Bilginin bugün nerede olduğunu listeleyin: elektronik tablolar, CRM, HRIS, ticketing araçları, paylaşılan gelen kutuları veya bir veritabanı. Her sistemin neyi iyi yaptığı ve neyin eksik olduğu not edin (ör. CRM müşteri kayıtlarını tutuyor ama onaylar e‑posta içinde yapılıyor).
İlk versiyonu küçük tutun. Tanımlayın:
Bir tabloyu bir cümlede tanımlayamıyorsanız, muhtemelen onu eklemek için çok erken.
Uygulama canlıyken güncellemelerin nerede yapılacağını kararlaştırın. Elektronik tablo salt‑okunur mu olacak? Müşteri verileri CRM'de mi kalacak, dahili uygulama onayları mı takip edecek? Bunu yazın ve veriyi düzenleyen herkesle paylaşın.
İçe aktarmalar gerçekliğin karmaşasını gösterir. Basit kurallar koyun: değerleri nasıl temizleyeceksiniz (tarihler, isimler, durumlar), nasıl çoğaltmaları çözeceksiniz (hangi kayıt kazanır) ve uç durumları kim onaylayacak. Her tablo için bir sahip atayın ki veri soruları ortaya çıktığında hesap verebilir biri olsun.
İsterseniz hızlı bir takip için ekibinizin inşa ve eğitim sırasında başvurabileceği tek sayfalık bir veri sözlüğü oluşturun.
Platform seçimi "en iyi hangisi"den çok ilk kullanım durumunuza, ekibinizin konfora ve aracın ne kadar süreyle kullanılacağına bağlıdır.
No-code araçlar formlar, temel onaylar ve dahili panolar için en hızlısıdır. Platformun şablonları ve sınırları içinde yaşayabiliyorsanız idealdir.
Low-code platformlar daha fazla esneklik sağlar (özel mantık, daha iyi veri işleme, zengin UI) ama genelde daha fazla kurulum ve “builder” kavramlarına hakim birine ihtiyaç gerektirir.
Hafif özel build (genellikle basit bir CRUD uygulaması) gereksinimler netse şaşırtıcı derecede küçük ve sürdürülebilirdir—ancak dağıtım, güncellemeler ve güvenlik için zaman zaman mühendislik yardımı gerekir.
Eğer tam mühendislik hattı kurmadan “özel build hızı” istiyorsanız, Koder.ai gibi bir vibe‑coding platformu pratik bir orta yol olabilir: iş akışını sohbetle tanımlarsınız, planlama modunda yineleyip gerçek bir uygulama üretebilirsiniz (çoğunlukla ön yüzde React, arka uçta Go + PostgreSQL). Kaynak kodu dışa aktarma, dağıtım/barındırma ve anlık görüntülerle geri alma gibi özellikler faydalıdır.
Arayüze aşık olmadan önce şu temel özellikleri kontrol edin: kimlik doğrulama, rol tabanlı erişim kontrolü ve denetim günlükleri (kim neyi ne zaman değiştirdi). Sistemlerinizle entegrasyonların varlığını doğrulayın (Google Workspace/Microsoft 365, Slack/Teams, CRM, HRIS) ve yedeklemeler ile net bir kurtarma sürecinin olduğunu teyit edin.
Nerede barındırılabileceğini (satıcı bulutu vs şirket bulutu), hangi veri yerleşimi seçeneklerinin bulunduğunu ve veriyi taşımaya karar verdiğinizde ne kadar kolay dışa aktarım olduğunu sorun. Çalışma süresi (uptime) taahhütleri, durum sayfaları ve destek düzenlemeleri (yanıt süreleri, onboarding yardımı, kritik sorunlar için bir iletişim hattı) hakkında bilgi alın.
Veri yerleşimi önemliyse (gizlilik veya sınır ötesi transfer kuralları için), uygulamanın hangi bölgede çalışacağını seçebileceğinizi teyit edin. Örneğin, Koder.ai küresel olarak AWS üzerinde çalışır ve veri konumu gereksinimlerini desteklemek için farklı bölgelerde uygulama dağıtabilir.
Lisanslar sadece bir parça. Ayrıca tahmin edin:
Emin değilseniz, zorunlu gereksinimleri karşılayan en küçük platformu seçin ve verinizi daha sonra temizce dışa aktarabileceğinizden emin olun.
İlk sürümünüz tamamlanmış hissetmeden önce faydalı olmalı. Küçük bir ekran seti ve bir elektronik tablo sürecini baştan sona değiştirecek bir iş akışı hedefleyin.
Çoğu dahili aracın ihtiyaç duyduğu ekranlarla başlayın:
Formları kısa tutun. “Olması güzel olur” alanları eklemek istiyorsanız, bunları Daha Sonra listesine alın.
Gerçek devralmaları yansıtan 4–6 durum tanımlayın (ör. Yeni → İnceleme → Onaylandı → Çalışma İçinde → Tamamlandı). Sonra ekleyin:
İyi bir test: biri bir bildirim aldığında, bir sonraki adımı tam olarak bilmelidir.
Engeller yeniden işi önler:
Raporlama basit ama değerli olabilir:
Bu ekranlar için somut bir şablon isterseniz, /blog/internal-app-mvp-layout sayfasındaki düzeni inceleyin.
Güvenlik işi yavaşlatmak zorunda değil, ama özellikle dahili araçlar “hızlı web uygulaması”ndan müşteri verileri, bordro detayları veya operasyon kayıtları tutan bir şeye dönüştüğünde kasıtlı olması gerekir.
İnsanlara sadece işlerini yapmak için gerekli olan erişimi verin. Bu, rolleri önceden tanımlamakla (örn. “Talep eden”, “Onaylayan”, “Admin”) daha kolay olur. Rol tabanlı izinler dahili uygulamalar için asgari gerekliliktir.
Önleyici birkaç kural:
Şirketiniz Google Workspace, Microsoft 365, Okta veya benzeri kullanıyorsa, tek oturum açmayı (SSO) tercih edin. Bu parola tekrar kullanımını azaltır ve çalışan offboarding'ini hemen yapar.
SSO yoksa, platformun sağladığı güvenli giriş özelliklerini kullanın (mümkünse MFA) ve temel bir parola politikası belirleyin (uzunluk; sadece uyumluluk gerekiyorsa döndürme ekleyin).
Pek çok dahili uygulama için net bir değişiklik geçmişi gerekir: hangi onayı kim verdi, bir kaydı kim düzenledi ve ne zaman oldu. Yerleşik denetim günlükleri, kayıt versiyonlama veya en azından kullanıcıların manuel olarak değiştiremeyeceği “son güncelleyen/son güncelleme zamanı” alanları arayın.
Dahili uygulamaları küçük kayıt sistemleri olarak ele alın:
İlk dahili uygulamanız, ekibinizin zaten yaşadığı araçlara bağlandığında çok daha faydalı olur. Ama amaç “her şeyi entegre etmek” değil—kopyala/yapıştır adımlarını ortadan kaldırmaktır.
Günlük konuşmaların ve kaynak verinin bulunduğu sistemlerle başlayın:
Basit, tekrarlanabilir tetikleyiciler genellikle en iyi yatırım getirisini sağlar:
Eğer API'leri (doğrudan veya Zapier/Make aracılığıyla) kullanıyorsanız birkaç gerçeği planlayın:
Canlıya almadan önce örnek veriler ve birkaç uç durum ile test edin (eksik alanlar, alışılmadık isimler, iptal edilen talepler). Bir geri alma planı dokümante edin: entegrasyon yanlış çalışırsa ne yapacağınız—kimi bilgilendireceğiniz, değişiklikleri nasıl geri alacağınız ve entegrasyonu geçici olarak nasıl devre dışı bırakacağınız.
Formal bir QA departmanına ihtiyaç yok; tekrarlanabilir bir kontrol listesine, gerçek senaryolara ve kısa bir düzeltme‑yeniden test döngüsüne ihtiyacınız var.
Dahili aracınızın desteklemesi gereken 5–8 temel akışı yazın (örn. “talep gönder → yönetici onaylar → finans ödemeyi işaretler”). Her akışı gerçekçi verilerle uçtan uca test edin—"test123" gibi sahte değerler yerine.
Gerçekte sıkça olan hataları seçin:
Eğer uygulama ekleri destekliyorsa, büyük bir PDF, telefondan çekilmiş bir resim ve boşluk içeren dosya adları gibi tuhaf ama gerçek dosyaları test edin.
En az üç test hesabı oluşturun: normal kullanıcı, onaycı/yönetici ve admin. Her birinin sadece olması gerekenleri görüp yapabildiğini doğrulayın.
Sağduyu kontrolleri:
Uygulamayı “çok fazla” veri ile deneyin:
Sahada kullanacak kişilere gerçek senaryoları çalıştırmalarını ve tereddüt ettikleri noktaları seslendirmelerini isteyin. Sorunları tek bir yerde kaydedin (bir elektronik tablo yeterli).
Her sorunu önem derecesine göre etiketleyin (bloklayıcı / rahatsız edici / iyi‑olur) ve üstteki öğeleri düzeltip hatayı bulan senaryoyu her seferinde yeniden test edin.
İyi bir yaygınlaştırma büyük bir lansmandan çok ilk haftanın sıkıcı olmasıyla ilgilidir: daha az sürpriz, net sahiplik ve yardım almanın öngörülebilir bir yolu.
Günlük acıyı hisseden (ve geribildirim vermeye istekli) bir ekiple başlayın. Net bir başlama tarihi belirleyin ve soruların nereye gideceğini tanımlayın—genellikle özel bir Slack/Teams kanalı ve bir isimlendirilmiş sahip.
Pilot kapsamını sıkı tutun: hedef, iş akışının uçtan uca çalıştığını kanıtlamak, tüm uç durumları kaplamak değil. Geri bildirimleri tek bir yerde toplayın (basit bir form veya paylaşılan doküman) ve sabit aralıklarla gözden geçirin (örn. iki günde bir).
Üç hafif varlık oluşturun ve kullanıcıların çalıştığı yerde sabitleyin:
Eğitimi role göre yapın: bir talep edenin ihtiyaçları onaycı veya adminden farklıdır.
Elektronik tablolardan taşıyorsanız basit bir sıra izleyin:
Canlı demeden önce doğrulayın:
İsterseniz kontrol listesini tekrarlanabilir kılmak için dahili bir sayfada yayınlayın, örn. /ops/internal-app-rollout.
İlk sürüm “bitti” değildir—canlı bir aracın başlangıcıdır. İyi haber: çoğu dahili araç, net sorumluluk ve hafif bir değişim süreci kurulduğunda iş sahipleri ve yöneticiler tarafından korunabilir.
Üç rol seçin ve uygulamanın README veya ana ekranına yazın:
Üretimde rastgele düzenlemelerden kaçının. Ne değiştiğini, kimin ihtiyacı olduğunu ve başarının ne demek olduğunu yakalayan kısa bir talep formu (hatta paylaşılan bir doküman) kullanın.
Değişiklikleri toplu halde onaylamak için haftalık veya iki haftalık gözden geçirme zamanlaması belirleyin. Araç içinde kısa sürüm notları yayınlayın (bir paragraf: ne değişti, kimleri etkiler ve yeni alanlar varsa).
Platform destekliyorsa, daha güvenli güncellemeler için anlık görüntüler (snapshot) ve geri alma kullanın. Örneğin, Koder.ai anlık görüntülemeyi içerir; böylece değişiklikleri yayınlayıp geribildirim toplayıp bir iş akışı bozulursa hızlıca geri alabilirsiniz.
Aylık olarak şunları kontrol edin:
Bunu kısa bir geribildirim nabzı ile eşleştirin: “Gelecek ay sizi en çok hangi şey zaman kazandırır?”
Erişim nasıl verilir, verinin nerede olduğu ve değişiklikleri nasıl geri alacağınız gibi bilgileri minimal ama gerçekçi bir dokümantasyonda tutun. Ayrıca erişim devri ve temel bir satıcı çıkış planı hazırlayın (veriyi nasıl dışa aktarır ve kritik iş akışlarını başka bir yerde nasıl yeniden oluşturursunuz).
No-code ve low-code çok şeyi kapsar, ama bir noktada mühendislik yardımı getirmek, platformu zorlamaktan daha ucuz ve daha güvenli olabilir.
Mühendislik desteğini düşünün eğer:
Yaygın yol: basit bir UI + iş akışı ile başlayın, sonra sadece gerektiği yerde küçük özel servisler ekleyin—ör. bir doğrulama API'si, zamanlanmış bir iş veya bir legacy sisteme bağlanan konektör.
Bu, değer üretme hızını korurken kırılgan platform çözümlerinden kaçınmanıza yardımcı olur. Birçok ekip “builder” ön yüzünü kullanmaya devam eder ve araç kritikleşince sadece arka ucu değiştirir.
Kısa bir teklif isteyin ki şu maddeleri içersin:
İşi bir sayfada açıklayamıyorsanız, önce ücretli bir keşif sprinti ile başlayın ve yineleyin.
Mükemmel bir iş vakasına ihtiyacınız yok, ama uygulamanın inşa etmeye değip değmeyeceğini ve ne kadar çaba çok olduğunu söyleyecek basit bir yol lazım. Hesabı basit tutun, sonra planı kısa bir kontrol listesiyle test edin.
Zaman tasarrufuyla başlayın, sonra hata azalımının değerini ekleyin.
Aylık kaydedilen saatler = (görev başına kurtarılan dakika ÷ 60) × haftalık görev sayısı × 4
Aylık değer = kaydedilen saatler × toplam işgücü maliyeti/saat
Örnek: 8 dakika tasarruf × 120 görev/hafta ≈ 64 saat/ay. Saatlik 45$ ile yaklaşık 2.880$/ay eder.
Sonra hata azaltımını tahmin edin: azalan çoğaltmalar, kaçırılan onaylar, yanlış faturalar. Ayda bir önlenen hata bile aracı karşılayabilir.
Gereksinimler: kullanıcılar, roller, 3–5 ana ekran, zorunlu iş akışı adımları, tamamlanma tanımı.
Veri modeli: kaynak of truth, zorunlu alanlar, ID'ler, tablo başına izinler, saklama/dışa aktarım ihtiyaçları.
Güvenlik: SSO, en az ayrıcalık erişimi, denetim günlüğü, offboarding süreci, yedekler.
Yayın: pilot grup, eğitim notları, destek kanalı, başarı metrikleri.
Belirsiz sahiplik, dağınık veri girişleri ve çok fazla özelliği aynı anda gönderme.
Tek bir iş akışı seçin, v1 kapsamını belirleyin, en basit kullanışlı versiyonu oluşturun, pilot yapın ve gerçek kullanıma göre yineleyin.
Hızlı ilerlemek ama tam mühendislik yatırımı yapmak istemiyorsanız, önce Koder.ai'de iş akışını prototiplemeyi düşünün: ekranları, rolleri ve durum mantığını hızlı doğrulayabilir, sonra kaynak kodu dışa aktarabilir veya araç değerini kanıtladıktan sonra dağıtabilirsiniz. (Öğrendiklerinizi paylaşırsanız Koder.ai ayrıca kredi kazanma programı sunar ve yönlendirmeler bir referral link ile izlenebilir.)
Bir dahili araç, çalışanların (müşteriler için değil) iş yürütmesi için kullandığı bir web uygulamasıdır. Genellikle:
Kullanıcılar ekibinizse ve amaç daha düzgün bir yürütme ise, bu bir dahili araçtır.
Aşağıdaki durumlarda bir dahili uygulama oluşturun:
Süreç nadir veya hâlâ günlük olarak değişiyorsa, kararlı hale gelene kadar hafif tutun (doküman + elektronik tablo).
Bir ay içinde ölçebileceğiniz 1–2 metrik seçin:
Önce mevcut durumu (kabaca bile olsa) baz alın, sonra yayından sonra yeniden ölçün ki etkisini kanıtlayabilesiniz.
Aşağıdaki özelliklere sahip bir iş akışını seçin ki aşırı geliştirmeyin:
İyi başlangıçlar: satın alma talepleri, erişim talepleri, onboarding kontrol listeleri, olay kayıtları, basit envanter takibi, içerik onayları.
Teknik olmayan, açık dille gereksinimleri şöyle yazın:
Sonra prototipi 3 temel ekranda tutun: , , (yorum/geçmiş/aksiyonlar).
Minimal bir veri modeliyle başlayın:
Yayına sonra hangi sistemin güncelleme yapacağı konusunda tek bir kaynak (source of truth) belirleyin ve herkesle paylaşın. Örneğin: CRM müşteri verilerinin sahibi olsun, dahili uygulama onay durumunun sahibi olsun, eski elektronik tablo salt‑okunur yapılsın.
Kural şu şekilde:
Değişmez kontrol listesi: kimlik doğrulama/SSO seçenekleri, rollere dayalı erişim kontrolü, denetim günlükleri, yedekleme/geri yükleme ve temiz veri dışa aktarımı.
Temel güvenlikleri erken kapsayın:
Erken değer getiren entegrasyonlara öncelik verin:
API/Zapier/Make kullanıyorsanız planlayın:
Basit bir kontrol listesiyle test edin ve yayınlayın:
Yayın için: bir ekipte pilot, 1 sayfalık hızlı başlangıç, kısa video ve SSS ile temiz bir geçiş yapın (dondurma → içe aktar → doğrula → duyur).
Uygulamayı ilk günden mini bir kayıt sistemi gibi ele alın.