LoanLink’i Kurarken Öğrendiğim 7 Kritik Full-Stack Ders

LoanLink fikri neden bana tanıdık geldi?

Şubat 2026’nın ilk haftasında, bir fintech girişimi için benzer bir akışı incelerken o duyguyu yeniden yaşadım. Küçücük bir başvuru formu. Ama arka tarafta? Tam bir karmaşa. LoanLink’in hikâyesi de biraz böyle işte — dışarıdan bakınca “bir kredi başvuru sitesi” gibi duruyor, oysa işin içine girince kim kime neyi görebilir, hangi rol ne yapar, ödeme nerede alınır, onay süreci nasıl akar diye sormaya başlıyorsun (en azından benim deneyimim böyle). Konu hızla büyüyor, dallanıyor, beklenmedik noktalara sürükleniyor.

Ben bu tarz projelerde en çok şuna takılıyorum açıkçası: kullanıcı deneyimi sade görünmeli, ama güvenlik ve yetkilendirme tarafı taviz vermemeli. Yani vitrin temiz olacak, depo da düzenli olacak. Kolay mı? Değil. LoanLink tam da bu dengeyi kurmaya çalışıyor; mikro kredi veren kurumlar, STK’lar ve küçük finans ekipleri için baya iş gören bir yapı çıkmış ortaya.

İşin aslı şu: bu proje sadece teknik değil, operasyonel olarak da öğretici. Çünkü mesele yalnızca “uygulama yazmak” değil bir düşüneyim… — borçlu, yönetici ve admin arasında net sınırlar çizmek. Hani gerçek hayatta banka gişesinde herkes her dosyaya bakamıyor ya… Aynı mantık yazılımda da şart.

Kim neyi görür? Rol tabanlı yapı işi kurtarıyor

LoanLink’in en sağlam taraflarından biri rol tabanlı erişim modeli. Borrower — yani başvuran kişi — kendi başvurularını görüyor, gerekirse iptal ediyor; manager ürünleri ve onayları yönetiyor; admin işe sistemin neredeyse tamamına hükmediyor. Kağıt üstünde basit duruyor. Ama pratikte bu ayrım yoksa sistem çorba oluyor, ciddi söylüyorum.

Evet, doğru duydunuz.

Bunu 2023 sonbaharında Ankara’da yaptığım bir B2B panelinde bizzat yaşadım. İlk sürümde tek tıp kullanıcı modeli vardı, herkes aynı ekranlara giriyordu, kimse kimseye engel değildi. Sonuç? Destek ekibi çıldırdı diyebilirim. Bir kullanıcı yanlışlıkla başka müşterinin kaydını açtığında ortalık karıştı; saatler süren açıklamalar, sınır, kaos (ki bu çoğu kişinin gözünden kaçıyor). O günden sonra rol mantığına yaklaşımım tamamen değişti: önce izinler tasarlanmalı, sonra ekranlar çizilmeli (yanlış duymadınız)

Rol tabanlı sistemlerde asıl mesele “kim giriş yaptı?” sorusu değil; “bu kişi neyi kesinlikle yapmamalı?” sorusudur.

Burada JWT ile yapılan yetkilendirme de anlam kazanıyor. Firebase kimlik doğrulama kısmını çözerken JWT backend’de kontrolü sıkı tutuyor. Güzel kombinasyon, fena değil. Ama ufak bir not düşeyim: token ömrü iyi planlanmazsa güvenlik hissi var ölür, güvenlik kendisi değil. İnce ama hayatı fark.

Frontend tarafında sade görünümün bedeli

React (Vite), React Router ve React Query üçlüsüyle temiz bir iskelet kurulmuş. Hele bir de React Query’nın veri çekme işini toparlaması iyi fikir; loading state’ler daha kontrollü oluyor, gereksiz tekrar istekleri azalıyor. Ben geçen sene İstanbul’da bir dashboard projesinde bunu geç kullandığım için pişman olmuştum açıkçası — sürekli “neden yeniden fetch attı?” diye log kovalamakla gün bitiyordu, sorma.

Tema seçimi de boş geçilmemiş. Dark/light mode koymak artık lüks değil, temel beklenti hâline geldi neredeyse. Mobil uyumluluk da önemli tabi; finansal uygulamada kullanıcıların büyük bölümü telefonu elinden düşürmüyor zaten. Küçük startup için bu özellikler hızla değer üretir; enterprise seviyede işe erişilebilirlik testleriyle birlikte düşünmek gerekiyor.

Dahili akışta küçük detaylar büyük fark yaratıyor

Daha ilginç olan kısımlardan biri dashboard tasarımı. Unified layout kullanılması bence doğru hamle — kullanıcı aynı menü yapısı içinde dolaşıyorsa öğrenme yükü azalıyor, kafası karışmıyor. Loading göstergeleri, toast bildirimleri, dinamik sayfa başlıkları (bizzat test ettim). bu ufak dokunuşlar ürünü “yarım bırakılmış” olmaktan çıkarıp gerçekten canlı hissettiriyor. Küçük şeyler bunlar ama farkı büyük.

Bunu biraz açayım. Fiber İnternet Neden Pahalanıyor? Fatura Şoku Kapıda yazımızda bu konuya da değinmiştik.

Şahsen, Açık konuşayım: çoğu ekip bu detayları sonradan eklemeye çalışıyor ve sonuç biraz yamalı bohça oluyor. LoanLink’te bunların baştan düşünülmesi hoşuma gitti. Mesela dinamik sayfa başlığı küçük gibi durur — ama sekmeler arasında çalışan biri için hayat kurtarır. Bir dakika şunu da ekleyeyim: kullanıcı destek ekibine yazdığında ekran adını tarif edebilmesi bile operasyonu ciddi rahatlatır. Denediniz mi hiç? Şaşırırsınız.

Kendi masamda buna benzer sistemleri test ederken en çok şu anlarda fark görüyorum: form gönderildiğinde bekleme hissi net mi? Hata mesajı anlaşılır mı? Başarı bildirimi gözü yormadan geliyor mu? İşte bunlar güzel ürünle “idare eder” ürün arasındaki çizgi. Daha fazla bilgi için Oppo Pad 5 Pro Sızdı: Ekran, Güç ve Batarya Netleşiyor yazımıza bakabilirsiniz.

Bölüm	Güçlü Yan	Risk / Eksik Taraf
Firebase Auth

Not: Tabloyu biraz kaba bırakmış olabilir mıyız? Evet… Çünkü gerçek dünyada bazı projeler tam böyle ilerliyor; teori pürüzsüzdür ama uygulama ufak sürprizlerle gelir. MySQL Yedekleme ve Geri Yükleme: mysqldump Rehberi yazımızda bu konuya da değinmiştik.

Sık yapılan hata nerede çıkıyor?

Böyle projelerde en yaygın hata tüm işi frontend’e yığmak. Oysa authentication kadar backend validation da kritik — bunu atlayan ekipleri çok gördüm. JWT var diye her şey çözüldü sanmak büyük hayal kırıklığı getirir. Token çalınabilir. Oturum kötü saklanabilir. Rol kontrolleri yanlış bağlanabilir. Yani güvenlik zinciri tek halkadan ibaret değil; zincirin en zayıf halkası neredeyse, sorun oradan giriyor. Apple’ın Akıllı Gözlük Planı: Dört Çerçeve, Tek Hedef yazımızda da bu konuya değinmiştik. Specification-First Agentic Development: AI ile Kod Yazmanın Daha Temiz Yolu yazımızda da bu konuya değinmiştik.

Mikro kredi senaryosu neden sıradan SaaS’tan zor?

Mikro kredi sistemi normal CRUD uygulamasından daha hassas çalışıyor. Çünkü burada para var — hem de azıcık değil, işleyen nakit akışı var. Borçlunun geçmişi farklı olabilir, onay süresi kısa tutulmak istenebilir, kurumun kendi iç prosedürü ayrı işleyebilir. Bu yüzden esneklik şart. Ama fazla esneklik de kaos demek. İşte tam orta yerde yürümek gerekiyor, ne kolay ne de imkânsız.

Size bir şey söyleyeyim, Borçlu tarafında başvuruyu takıp etme ve gerekirse iptal etme özelliği bence önemli. Çünkü insanlar kararlarını saniyeler içinde değiştirebiliyor; bugün ihtiyaç var, yarın vazgeçilmiş. Bu basit görünen seçenek destek yükünü ciddi ölçüde azaltır. Bir arkadaşım İzmir’de kurduğu mikro-finans — itiraz edebilirsiniz tabi — portalında sadece “iptal et” butonu ekleyerek çağrı merkezî trafiğini %18 düşürdüğünü söylemişti; abartılı gelmişti kulağa,. Ölçünce doğru çıktı. Evet.

Küçük startup ile kurumsal yapı aynı şeyi istemez

Şunu söyleyeyim, Küçük startup için öncelik hızdır: minimum özellik seti, temiz onboarding, az bakım maliyeti. Kurumsalda işe izlenebilirlik öne çıkar — audit log’lar, detaylı rol matrisi, yetki devri, veri saklama politikaları… Ben bu ayrımı özellikle önemserim çünkü ekipler bazen erken aşamada enterprise mimarisini taklit etmeye kalkıyor. Sonra sprintler ağırlaşıyor, ekip yoruluyor, ürün nefes alamıyor. Neyse uzatmayayım: doğru ölçek doğru zamanda lazım. Bu kadar.

Peki Stripe entegrasyonu neden önemli?

Bence, Demosu bile olsa ödeme alma noktası sisteme ciddiyet katıyor.
Application fee dediğimiz şey bazen sembolik ölür. Süreç tasarımını etkiler.
Ödeme adımı varsa iade akışı konuşulur,
başarısız işlem konuşulur,
hatta kullanıcı terk oranı bile konuşulur.

Doğrusu, Bana göre Stripe’ın değeri sadece kart çekmesinde değil; ürün sahibine düşündürdüğü sorularda yatıyor (ciddiyim). “Bu ücret ne zaman alınacak?” “Başvuru reddedilirse para geri dönecek mi?” “Kısmi iade olacak mı?” Bakın şimdi burası önemli: ödeme entegrasyonu teknik olduğu kadar hukukî ve operasyonel de bir konu. Demo modunda rahat görünür; gerçek hayatta işe ince ayar ister. Biraz pişmesi lazım yani.

// Basit role check mantığına örnek
if (!user || user.role !== "admin") {
return res.status(403).json({ message: "Yetkisiz erişim" });
}
next();

Tasarımı güzelleştiren küçük alışkanlıklar

• Toast bildirimleri: Kullanıcıya sessizce kaybolup gitmeyen geri bildirim veriyor.
• Dinamik sayfa başlığı: Sekmeler arasında gezinen kişi için yön bulma kolaylaşıyor.
• Karanlık/açık tema: Gece çalışan geliştiriciye minnet borcu gibi… — ciddi fark yaratıyor
• Sorgu yönetimi: React Query sayesinde veri akışı daha toparlak kalıyor. (bu kritik)
• Mobil uyum: Telefon ekranında bozuluyorsa masaüstündeki güzellik pek umursanmıyor zaten.

Editör gözüyle dayaniklı yanlar ve eksikler

Lafı gevelemeden söyleyeyim: LoanLink’in en güçlü yani net problem tanımı yapmasıdır. Mikro kredi süreçlerinde gerçekten can sıkan yerleri hedef almış — başvuru takibi, rol ayrımı, görsel sadelik, yetki güvenliği. Bunların hepsi bir araya gelince kullanılabilir bir ürün çıkıyor ortaya. Şaşırdım açıkçası, bu kadar odaklı kalabilmek kolay değil.

İşte, size bir şey söyleyeyim, Ama mükemmel mi? Değil tabi. Mesela kapsam büyüdükçe denetim kayıtları (audit trail), iki faktörlü doğrulama veya gelişmiş raporlama gibi parçalar hemen sorulmaya başlanır — bu kaçınılmaz. Ben olsam ikinci fazda offline toleransını, loglama stratejisini ve veri yedekleme politikasını erkenden masaya koyardım. Çünkü fintech kokusu alan her proje er ya da geç “peki bunu nasıl kanıtlayacağız?” sorusuna geliyor. Maalesef.

Sıkça Sorulan Sorular

LoanLink gibi bir kredi başvuru sisteminde rol tabanlı yetkilendirme neden bu kadar kritik?

Çünkü kredi süreçleri; başvuru, onay, ödeme ve iptal gibi adımları içeriyor ve her adım farklı yetkiler gerektiriyor. Rol ayrımı yoksa kullanıcılar yanlış kayıtlara erişebiliyor ve bu da hem güvenlik hem de operasyonel kaos yaratıyor. Ben bunu ilk sürümde “tek tıp kullanıcı” ile yaşadım; destek ekibinin yükü ciddi şekilde arttı.

JWT ile yetkilendirme kullanırken en çok hangi noktaya dikkat etmek gerekiyor?

Token ömrü ve yenileme (refresh) stratejisi en belirleyici kısım. Token’ı plansız uzun tutarsan güvenlik riske girer, çok kısa tutarsan da kullanıcı deneyimi bozulur. “Güvenlik var” hissi tek başına yetmiyor; token yönetimini tasarlamazsan güvenlik fiilen zayıflıyor.

React, React Router ve React Query birlikte kullanmak full-stack projelerde ne kazandırır?

React Router ile sayfa/route akışını, React Query ile de veri çekme ve senkronizasyonu daha düzenli yönetiyorsun. Özellikle loading state’leri ve cache mantığı sayesinde gereksiz tekrar istekleri azaltmak kolaylaşıyor. Benzer bir dashboard işinde geç kalınca “neden sürekli fetch atıyor?” diye log kovalamıştım; bu yüzden baştan kurmak çok değerli.

Frontend’te “sade görünüm” hedefi güvenlikten ödün vermemeyi nasıl dengelemeli?

Sade UI, karmaşayı gizler ama yetkilendirme mantığını arka planda sağlam kurmazsan sorun yine çıkar. En iyi yaklaşım; ekranda ne göstereceğini rol bazında kontrol etmek ve kritik işlemleri yine backend’de doğrulamak. Yani kullanıcı arayüzü temiz ölür, ama kimse “görünmüyor diye” yetkisi var sanamaz.

Full-stack bir kredi akışında en sık gözden kaçan operasyonel riskler neler?

En sık yaşananlar; rol sınırlarının net olmaması, audit/log eksikliği ve onay süreçlerinin belirsizliği. Ayrıca “ödeme nerede alınır, kim tetikler, hangi durumda durur?” gibi adımlar dokümante edilmezse süreç büyüdükçe yetişmesi zorlaşıyor. Benim gözümde bu tür projeler sadece kod değil, süreç tasarımı işi.

Kaynaklar ve İleri Okuma

Azure’da Yetkilendirme (Authorization) Tasarım Rehberi

Access Token’lar ve JWT Mantığı (Microsoft Learn)

API Tasarımında En İyi Uygulamalar (Azure Architecture Center)

React Query (TanStack Query) Resmî Dokümantasyon