Web Uygulaması Nedir? Web Sitesinden Farkı ve Nasıl Geliştirilir

Web uygulaması, bilgisayara ya da telefona kurulmadan tarayıcı üzerinden kullanılan, kullanıcının oturum açıp veri girdiği ve bu verinin sunucuda iş kurallarına göre işlendiği yazılımdır. Türkçede “web tabanlı program” ya da “web tabanlı uygulama” da denir. Adres çubuğunda gördüğünüz şey bir web sitesininkiyle aynıdır; farkı, ekranın arkasında çalışan mantıktadır.

Tanımı tek cümleye indirmem gerekirse: ziyaretçi bir şeyi okuyup çıkıyorsa web sitesidir; kullanıcı bir iş yapıyor, yaptığı iş kaydediliyor ve başka biri o kayda göre hareket ediyorsa web uygulamasıdır. Bankanızın internet şubesi, kargo firmasının gönderi takip paneli, bayilerin sipariş geçtiği B2B portal, kliniklerin randevu sistemi ve satış ekibinin teklif hazırladığı sistem bu tanıma girer.

Aşağıdaki şema, bir web uygulamasında tek bir “Gönder” tıklamasının izlediği yolu gösteriyor. Bir web sitesindeki iletişim formu bu yolun yalnız ilk ve son adımını yaşar; uygulamada aradaki her adım ayrı bir sorumluluktur.

Gündelik hayattan web uygulaması örnekleri

• İnternet şubesiKullanan: Bireysel ve kurumsal banka müşterisiSisteme yazdığı: Havale talimatı, fatura ödemesi, limit değişikliği
• B2B sipariş portalıKullanan: Bayi ve satış temsilcisiSisteme yazdığı: Sipariş, iade talebi, cari ekstre sorgusu
• Randevu sistemiKullanan: Hasta veya danışan ile sekreteryaSisteme yazdığı: Randevu, iptal, hatırlatma tercihi
• Dahili onay paneliKullanan: Şirket çalışanları ve yöneticilerSisteme yazdığı: Satınalma talebi, onay, red gerekçesi
• Teklif yönetimiKullanan: Satış ekibi ve satış müdürüSisteme yazdığı: Teklif, iskonto onayı, siparişe dönüşüm
• Eğitim platformu (LMS)Kullanan: Öğrenci, eğitmen, kurum yöneticisiSisteme yazdığı: İlerleme, sınav cevabı, sertifika

Bir web uygulamasını kurulumlu masaüstü programından ayıran şey dağıtım biçimidir. Güncelleme sunucuda yapılır, herkes aynı anda yeni sürüme geçer, kullanıcının bilgisayarına bir şey kurmanız gerekmez. Bedeli de belli: uygulama internet bağlantısına ve sunucunun ayakta kalmasına bağımlıdır. Masaüstü tarafındaki seçenekleri masaüstü program hangi dille yapılır yazısında ayrıca ele aldık.

Farkı en kolay, bilginin hangi yöne aktığına bakarak görürsünüz. Web sitesinde bilgi şirketten ziyaretçiye akar: hizmetler, ürünler, iletişim bilgisi. Web uygulamasında akış iki yönlüdür; kullanıcı da sisteme veri yazar ve sistem bu veriye göre karar verir. Okuma ile yazma arasındaki bu denge mimariyi, test yükünü ve bütçeyi doğrudan belirler.

Teklif görüşmelerinde en sık duyduğum cümle şu: “Basit bir site istiyoruz, sadece bayiler giriş yapıp siparişlerini görecek.” Bu cümledeki “sadece” kelimesinin arkasında oturum yönetimi, parola sıfırlama, bayi bazlı veri ayrımı, ERP'den sipariş çekme ve bir yönetici paneli var. Yani istenen şey site değil, küçük ölçekli bir web uygulaması. Bunu baştan doğru adlandırmak, sonradan çıkan “bu kapsamda değildi” tartışmasını önler.

Gri alanlar: ikisinin arasında kalan projeler

• Gri alanE-ticaret sitesiVitrin tarafı bir sitedir ve SEO ister; sepet, ödeme, stok ve sipariş takibi ise uygulamadır. Hazır bir altyapı (Shopify, WooCommerce, OpenCart gibi) çoğu zaman uygulama kısmını sizin yerinize çözer. Özel geliştirme, hazır altyapının iş kurallarınıza yetmediği yerde anlam kazanır.
• Gri alanÜyelikli içerik sitesiYazılar herkese açık, bir kısmı üyelere. Okuma ağırlıklı olduğu için çoğu zaman bir CMS ve üyelik eklentisi yeter. Ücretli abonelik, kurumsal lisans veya içerik bazlı yetki girdiğinde uygulamaya yaklaşır.
• Gri alanKurumsal site + müşteri paneliTanıtım sitesi ve giriş arkasındaki panel ayrı düşünülmeli. İkisini aynı CMS içinde çözmeye çalışmak genellikle panelin sınırlarına erken çarpmak demektir.

Aşağıdaki sekiz soru, keşif toplantılarımızda ilk yarım saatte sorduğumuz soruların kısaltılmış hâli. Yanıtladıkça sihirbaz projenizi altı sınıftan birine yerleştirir, hangi mimari katmanların devreye girdiğini ve sayfaların nasıl render edilmesi gerektiğini gösterir. Hesap tamamen tarayıcınızda yapılır; hiçbir yanıt kaydedilmez.

“Web uygulaması” şemsiye bir terim. Altında kullanıcısı, gelir modeli ve teknik riski birbirinden çok farklı projeler var. Türü doğru adlandırmak, hangi özelliklerin ilk sürüme girmesi gerektiğini de belirler.

• AMüşteri / bayi portalıŞirket dışındaki kullanıcılar: müşteri, bayi, tedarikçi
  • Oturum ve parola sıfırlama
  • Firma bazlı veri ayrımı
  • Sipariş, ekstre, belge indirme
  • ERP veya muhasebe entegrasyonu
  Örnek senaryo: Bayiler stok ve fiyatı görüp sipariş geçer; sipariş ERP'ye düşer, durum değiştikçe bayiye bildirim gider.E-ticaret platformu için web yazılım →
• BDahili araçŞirket çalışanları
  • Rol bazlı ekranlar
  • Onay akışı
  • Raporlama ve dışa aktarma
  • Zamanlanmış görevler
  Örnek senaryo: Satınalma talebi açılır, tutar eşiğine göre bir ya da iki yöneticiye gider, onaylanınca muhasebe görür. Excel ve e-posta trafiği biter.Dahili araç ve otomasyon →
• CSaaS ürünüÜrünü abonelikle kullanan birden çok şirket
  • Kiracı (tenant) ayrımı
  • Plan, kota, deneme süresi
  • Abonelik tahsilatı ve fatura
  • Kiracı içi kullanıcı yönetimi
  Örnek senaryo: Bir randevu ürünü yüzlerce kliniğe satılır; her klinik yalnız kendi hastalarını görür, plan yükseltince yeni özellik açılır.SaaS girişimleri için web yazılım →
• DEğitim / içerik platformuÖğrenciler, eğitmenler, kurum yöneticileri
  • İçeriğe erişim yetkisi
  • İlerleme takibi ve sınav
  • Sertifika üretimi
  • Ödeme veya kurumsal lisans
  Örnek senaryo: Kurum çalışanlarına eğitim atanır; tamamlanan modüller rapora, başarılı olanlara sertifika düşer.Eğitim platformu ve LMS →

PWA (Progressive Web App) ayrı bir tür değil, bir web uygulamasına eklenen yetenek katmanıdır: ana ekrana eklenebilen simge, service worker ile çevrimdışı önbellek, desteklenen platformlarda bildirim. Mağazaya yüklemeden telefonda “uygulama gibi” çalışan bir şey istiyorsanız iyi bir ara yol. Donanıma derin erişim, mağaza görünürlüğü veya ağır çevrimdışı senaryo gerekiyorsa native ya da cross-platform mobil uygulama daha doğru olur. Bu karşılaştırmayı mobil uygulama geliştirme süreci yazısında ayrıntılı ele aldık; burada tekrar etmeyeceğim.

Bir uygulamayı restorana benzetiyorum: müşterinin gördüğü salon arayüzdür, ama işi mutfak yapar. Ekranda bir “Kaydet” düğmesi görürsünüz; o düğmenin arkasında en az beş ayrı katman sırayla çalışır. Hangi katmanın ne iş yaptığını bilmek, teklif dosyasındaki kalemleri okumayı da kolaylaştırır.

Şemadaki istek akışı tipik bir örnek. Tarayıcı isteği gönderir; CDN statik dosyaları kendi üzerinden verir; uygulama sunucusu oturumu doğrular; API iş kuralını çalıştırır; veri PostgreSQL'e yazılır. Sık okunan veriler Redis gibi bir önbellekten gelir. E-posta gönderme, PDF üretme ya da ERP'ye aktarım gibi uzun işler kuyruğa bırakılır ve kullanıcı beklemez.

Katman katman: ne yapar, yoksa ne bozulur?

• Arayüz (frontend)Kullanıcının gördüğü ekranlar, formlar, tablolar. Çoğunlukla React veya Vue gibi bir kütüphaneyle yazılır.Yoksa: Kullanıcı işini yapamaz; kötü kurgulanmış bir arayüz en sağlam arka ucu da kullanılmaz hâle getirir.
• API ve iş kuralları (backend)İskonto sınırı, stok kontrolü, onay eşiği gibi kurallar burada çalışır. Arayüz ne gösterirse göstersin, son sözü sunucu söyler.Yoksa: Kurallar arayüze gömülür; tarayıcıdan isteği elle değiştiren biri kuralı atlatır.
• VeritabanıKayıtlar ve aralarındaki ilişkiler. İş uygulamalarında genellikle PostgreSQL, MySQL veya SQL Server gibi ilişkisel bir veritabanı.Yoksa: Veri tutarsızlaşır: aynı müşteri iki kez açılır, silinen sipariş raporda görünmeye devam eder.
• Kimlik doğrulamaKullanıcının kim olduğunu doğrular: parola, iki adımlı doğrulama, kurumsal hesapla giriş (SSO).Yoksa: Hesap ele geçirme riski artar; parola sıfırlama gibi sıradan akışlar destek yüküne dönüşür.
• Rol ve yetki (RBAC)Doğrulanan kullanıcının neyi görüp neyi yapabileceği. Rol tabanlı erişim kontrolü (RBAC) en yaygın model.Yoksa: Bayi A, adresteki numarayı değiştirip bayi B'nin siparişini görür. OWASP listesinin bir numaralı riski tam olarak bu.
• Dosya depolamaFatura PDF'i, sözleşme, ürün görseli. Uygulama sunucusunun diski yerine nesne depolamada tutulur.Yoksa: Sunucu değişince dosyalar kaybolur, yedekleme karmaşıklaşır, ölçekleme zorlaşır.
• Kuyruk ve arka plan işleriUzun süren veya tekrar denenmesi gereken işler: e-posta, PDF, ERP senkronu, toplu içe aktarma.Yoksa: Kullanıcı ekran başında bekler, istek zaman aşımına düşer; başarısız entegrasyon sessizce kaybolur.
• ÖnbellekSık okunan ama nadir değişen veriler (kur, kategori listesi) ve hız sınırı sayaçları. Genellikle Redis.Yoksa: Veritabanı her istekte aynı sorguyu çalıştırır; yoğun saatte ilk yavaşlayan yer burası olur.
• İzleme ve logHata kaydı, performans ölçümü ve kim neyi ne zaman yaptı bilgisini tutan denetim kaydı (audit log).Yoksa: “Dün akşam sipariş düşmedi” şikâyetine verecek bir cevabınız olmaz.

Arayüz ile arka uç arasındaki sözleşmenin adı API. Mobil uygulama, ERP veya bir iş ortağı da aynı sisteme bağlanacaksa API'yi baştan dokümante edilmiş bir ürün gibi tasarlamak gerekir. Konunun temelini API nedir, API entegrasyonu nasıl yapılır yazısında anlattık; kurumsal ölçekte tasarım ve geliştirme için API geliştirme sayfamıza bakabilirsiniz.

Render, sayfanın HTML'inin nerede ve ne zaman üretildiği sorusudur. Üç temel yanıt var. SSG (Static Site Generation): sayfa yayından önce, derleme sırasında bir kez üretilir ve CDN'den dağıtılır. SSR (Server-Side Rendering): sayfa her istekte sunucuda, o anki veriyle üretilir. CSR (Client-Side Rendering): sunucu boş bir kabuk gönderir, sayfayı tarayıcı JavaScript ile kurar.

Dördüncüsü bu üçünün arasında durur: ISR (Incremental Static Regeneration). Sayfa statik üretilir, ama belirlediğiniz aralıkla ya da içerik değiştiğinde arka planda yeniden üretilir. Binlerce ürün sayfası olan bir katalog için çoğu zaman en dengeli seçenek budur. Next.js gibi çerçeveler bu stratejileri aynı uygulama içinde sayfa sayfa karıştırmanıza izin verir.

Pratik kural basit: Google'dan trafik bekleyen, herkese açık sayfalar sunucuda üretilmeli (SSG, ISR veya SSR). Giriş arkasındaki panel, rapor ve form ekranları SEO'ya ihtiyaç duymaz; orada asıl ölçüt etkileşim hızıdır ve istemci ağırlıklı yapı gayet uygundur. Sık gördüğüm hata, tamamı CSR ile yazılmış bir uygulamanın pazarlama sayfalarını da aynı kabuğa koymak. Arama motoru ilk anda boş bir sayfa görür, ilk açılış da yavaşlar.

Next.js'in App Router yapısında varsayılan bileşen türü Server Component: bileşen sunucuda çalışır, veriye doğrudan erişir ve tarayıcıya yalnız sonucunu gönderir. Düğme, form, filtre gibi etkileşimli parçalar "use client" ile işaretlenir ve yalnız onların JavaScript'i tarayıcıya iner. Okuduğunuz sayfanın HTML'i de sunucuda önceden üretiliyor; sihirbaz ve seçici, JavaScript tarayıcıya inip hazır HTML'e bağlandığında canlanıyor. Bu bağlanma adımına hydration deniyor.

“Hangi dil daha iyi?” sorusunun dürüst cevabı: projeye göre. Bugün yaygın kullanılan çerçevelerin hepsi bir iş uygulamasını taşıyacak olgunlukta. Benchmark tablolarındaki milisaniye farkları, günde birkaç bin işlem gören bir sipariş portalında nadiren belirleyici olur. Belirleyici olan dört soru var: ekibiniz ne biliyor, uygulama nerede barındırılacak, iki yıl sonra kodun bakımını kim yapacak ve hangi kütüphane ekosistemine ihtiyacınız var.

Bizim varsayılan yığınımız Next.js, React ve TypeScript üzerine kurulu; arka uçta Node.js, veri için PostgreSQL ve Prisma, önbellek ve kuyruk için Redis, dağıtım için Docker ve GitHub Actions. Bu tercihin nedeni, tek dille (TypeScript) arayüzden API'ye kadar tip güvenliği sağlamak ve SEO isteyen sayfalarla giriş arkası ekranları aynı çerçevede çözebilmek. Varsayılan olması her projeye uyduğu anlamına gelmiyor; tablonun altındaki iki kutu tam da bu istisnalar için.

WordPress ya da no-code yeter mi? Tek rol, birkaç form ve basit bir liste yetiyorsa hazır bir araç ilk sürüm için mantıklıdır; fikri ucuza test edersiniz. Karmaşık yetki, kendine özgü iş kuralı veya birden çok entegrasyon girdiğinde bu araçların sınırına hızla ulaşılır ve taşıma maliyeti doğar. Excel'le yürüyen bir süreci nereye taşıyacağınıza karar veriyorsanız Excel yerine ne kullanılır yazısı bu ayrımı ayrıntılı ele alıyor.

Yabancı kaynaklı rehberlerin atladığı kısım burası. Türkiye'de bir iş uygulaması neredeyse her zaman bir sanal POS'a, bir e-Fatura entegratörüne, bir ERP'ye ya da kargo firmasına bağlanır. Bu bağlantıların her biri takvime belirsizlik ekler: karşı tarafın test ortamı, dokümantasyon kalitesi, sözleşme ve başvuru süreçleri sizin kontrolünüzde değildir.

• Sanal POS ve ödeme kuruluşlarıiyzico, PayTR gibi ödeme kuruluşları ya da doğrudan banka sanal POS'u; 3D Secure, taksit, iade, abonelik.Risk: Üye işyeri başvurusu ve canlı ortam onayı geliştirmeden bağımsız ilerler; erken başlatılmazsa yayını bekletir.İpucu: Ödeme sonucunu yalnız tarayıcı yönlendirmesine güvenerek işlemeyin. Sağlayıcının sunucudan sunucuya bildirimini (callback/webhook) doğrulayıp siparişi onu esas alarak kesinleştirin.
• e-Fatura ve e-ArşivÖzel entegratör üzerinden UBL-TR formatında e-Fatura ve e-Arşiv fatura, mükellef sorgulama.Risk: Kesilen fatura sıradan bir kayıt gibi silinemez; iptal ve iade senaryoları muhasebeyle birlikte tasarlanmalı.İpucu: Faturayı tek bir sistem kessin. Hem ERP hem uygulama fatura kesebiliyorsa çift belge riski doğar.
• ERP (Logo, Mikro ve diğerleri)Cari, stok, fiyat, sipariş ve irsaliye alışverişi; doğrudan veritabanı, REST servisi veya bir ara katman ile.Risk: Alan eşleştirme ve kod tutarsızlıkları (birim, ödeme planı, depo) en çok zaman alan iş; canlı veriyle denemeden süre vermek zordur.İpucu: Senkronu kuyrukta çalıştırın, her çalışmayı kaydedin ve aktarım sonrası bir mutabakat raporu üretin.
• Kargo firmalarıGönderi oluşturma, etiket ve barkod, takip numarası, durum güncellemesi.Risk: Her firmanın API'si ve durum kodları farklı; birden çok firma kullanılacaksa ortak bir ara katman gerekir.İpucu: Durum güncellemelerini destekleniyorsa webhook ile alın; dakikada bir sorgu atmak hem yavaş hem kotaya takılır.
• SMS, e-posta ve İYSDoğrulama kodu, bildirim ve kampanya mesajları; ticari elektronik ileti onaylarının İleti Yönetim Sistemi (İYS) ile yönetimi.Risk: Bilgilendirme mesajı ile ticari ileti aynı şey değildir. Bireysel alıcıya ticari ileti için önceden onay ve İYS kaydı gerekir. Esnaf ve tacirlere ön onay aranmaz, ama gönderimden önce İYS'de ret kaydı olup olmadığına bakılır.İpucu: Onayı kanal, tarih ve kaynakla birlikte saklayın; ret talebini hem İYS'de hem kendi sisteminizde işleyin.
• Kimlik doğrulama ve e-imzaKurumsal hesapla giriş (SSO), TCKN doğrulama, e-imza veya mobil imza ile belge onayı.Risk: TCKN'nin algoritmaya uyması, kişinin gerçekten o kişi olduğunu göstermez. Resmî kimlik sorgusu Kimlik Paylaşım Sistemi (KPS) gibi yetki ve başvuru isteyen kanallardan yapılır; eski kütüphanelerin kullandığı herkese açık servise güvenerek plan yapmayın.İpucu: Keşifte netleştirin: hangi servis, hangi yasal dayanak, hangi veri saklanacak. Gerekmiyorsa TCKN toplamayın.

Logo tarafındaki e-ticaret ve B2B senaryolarını Logo ERP entegrasyonu rehberinde ayrıntılı anlattık; kurulum ve özelleştirme için Logo ERP çözüm ortaklığı sayfamıza bakabilirsiniz. e-Fatura'ya geçiş yükümlülüğünü merak ediyorsanız e-Fatura zorunluluğu yazısı kimlerin geçmesi gerektiğini anlatıyor.

Web uygulaması geliştirme süreci, kodun yazıldığı sprintlerden çok, öncesinde verilen kararlarla başarılı ya da başarısız olur. Bizim projelerde en çok zaman kaybettiren şey kod hatası olmuyor; keşifte yanlış anlaşılmış bir iş kuralı oluyor. “İskonto onayı satış müdürüne gider” cümlesi, müdür izindeyken ne olacağı sorulmadan koda dökülürse sprint ortasında geri döner. Aşağıdaki akış bizim kullandığımız sıra; adımların adı ekipten ekibe değişse de mantığı aynıdır.

1. 1
   Keşif ve analiz1 haftaİşi yürüten kişilerle süreç haritalanır, roller ve ana akışlar çıkarılır, mevcut sistemler ve entegrasyonlar listelenir.Çıktı: Kapsam dokümanı, rol listesi, entegrasyon envanteriSık hata: Yalnız yöneticiyle konuşup işi fiilen yapan kişiyi dinlememek.
2. 2
   Kullanıcı hikâyeleri ve veri modeliKeşifle birlikte“Bayi olarak geçmiş siparişlerimi görmek istiyorum” biçiminde hikâyeler yazılır, her birine kabul ölçütü eklenir; varlıklar ve ilişkileri çizilir.Çıktı: Hikâye listesi, kabul ölçütleri, ilk veri modeliSık hata: Veri modelini ekran tasarımından türetmek. Ekran değişir, veri kalır.
3. 3
   UX ve prototip2–3 haftaWireframe, arayüz tasarımı ve tıklanabilir prototip; mümkünse gerçek kullanıcılarla erken test.Çıktı: Figma prototipi, tasarım sistemiSık hata: Prototipi yalnız onay toplantısında görmek, gerçek kullanıcıya hiç denetmemek.
4. 4
   Mimari ve altyapıİlk sprintKod deposu, ortamlar (geliştirme, test, canlı), CI/CD hattı, kimlik doğrulama ve yetki iskeleti.Çıktı: Uçtan uca çalışan boş iskelet, otomatik dağıtımSık hata: Yetki ve loglamayı “sonra ekleriz” diye bırakmak.
5. 5
   Sprintler1–2 haftalık döngülerHer sprintte bir dilim uçtan uca çalışır hâle gelir ve demo edilir; geri bildirim bir sonraki sprinte girer.Çıktı: Her sprint sonunda test ortamında çalışan sürümSık hata: Haftalarca demo görmeden ilerlemek.
6. 6
   Test ve güvenlikSürekli; yayın öncesi yoğunBirim, entegrasyon ve uçtan uca testler; rol bazlı yetki testleri; yük ve güvenlik taraması.Çıktı: Test raporu, kapatılmış bulgu listesiSık hata: Yalnız mutlu yolu test etmek; hatalı ödeme, zaman aşımı, yetkisiz istek senaryolarını atlamak.
7. 7
   Yayın ve devir1 haftaCanlıya alım, veri taşıma, eğitim, dokümantasyon; ilk günlerde yakın izleme.Çıktı: Canlı sistem, kaynak kod, dokümantasyonSık hata: Eski sistemden veri taşımayı son haftaya bırakmak.
8. 8
   Bakım ve gelişimSürekliGüvenlik güncellemeleri, bağımlılık yükseltmeleri, izleme, yeni özellikler.Çıktı: Bakım planı, sürüm notlarıSık hata: Bakımı bütçelememek. Bir uygulama yayına alındığı gün bitmez.

Web yazılım geliştirme sayfamızda örnek olarak verdiğimiz akış 12 hafta: 1 hafta keşif, 2 hafta tasarım, 7 hafta geliştirme, 1 hafta test, 1 hafta yayın. Orta ölçekli bir uygulama için gerçekçi bir örnek. Tek akışlı bir dahili araç daha kısa, çok entegrasyonlu bir portal daha uzun sürer. Arayüz ve araştırma tarafında destek arıyorsanız UI/UX tasarım hizmetimize, sürecin tasarım adımlarını merak ediyorsanız UI/UX nedir yazısına göz atabilirsiniz.

Bütçe ayrı bir yazının konusu. Hangi kalemlerin maliyeti büyüttüğünü özel yazılım fiyatları ve web uygulaması maliyeti yazısında bir hesaplayıcıyla anlatıyoruz.

Web uygulaması güvenliğinde ortak başvuru noktası OWASP Top 10 listesi: web uygulamalarında en sık görülen ve en çok zarar veren risk kategorilerinin sıralaması. Listenin 2025 sürümünde birinci sırada yine erişim kontrolü hataları (Broken Access Control) var. Kod incelemelerinde gördüğüm tablo da buna benziyor: pahalıya patlayan açıklar nadiren egzotik bir saldırı tekniğinden çıkar. Çoğu, tek bir endpoint'te (API'nin tek bir adresinde) “bu kullanıcı bu kaydı görmeli mi?” sorusunun unutulmasıdır.

Bu hatanın en bilinen biçimi IDOR (Insecure Direct Object Reference). Oturum açmış bir kullanıcı adres çubuğundaki sipariş numarasını bir artırıyor ve başka bir firmanın siparişini görüyor. O sayfayı menüde gizlemiş olmanız bir şey değiştirmez. Kontrol arayüzde değil, veriyi döndüren sorguda yapılmalı:

// HATALI: yalnız "oturum açık mı?" kontrol ediliyor
app.get("/api/siparisler/:id", requireLogin, async (req, res) => {
  const siparis = await db.siparis.findUnique({ where: { id: req.params.id } });
  res.json(siparis); // başka firmanın siparişi de döner
});

// DOĞRU: kayıt, oturumdaki firmayla birlikte sorgulanıyor
app.get("/api/siparisler/:id", requireLogin, async (req, res) => {
  const siparis = await db.siparis.findFirst({
    where: { id: req.params.id, firmaId: req.user.firmaId },
  });
  if (!siparis) return res.status(404).end(); // varlığını da sızdırma
  res.json(siparis);
});

KVKK açısından 6698 sayılı Kanun, kişisel veri işleyen her uygulamaya iki temel yük getirir: ilgili kişiyi aydınlatmak ve verinin güvenliği için uygun teknik ve idari tedbirleri almak. Teknik taraf uygulamanın mimarisinde karşılık bulur: erişim yetkilendirmesi, loglama, şifreleme, yedekleme, saklama süreleri ve silme ya da anonimleştirme akışları. Tedbirlerin BT tarafındaki karşılıklarını KVKK teknik ve idari tedbirler listesi yazısında madde madde ele aldık. Hukuki değerlendirme içinse mutlaka bir hukukçuyla çalışın.

Kod yazılırken alınan önlemler bağımsız bir gözle test edilmeden yeterli sayılmaz. Yayın öncesinde ve büyük sürümlerden sonra sızma testi yaptırmak, özellikle ödeme veya sağlık verisi işleyen uygulamalarda en sağlıklı yol. Sürecin nasıl işlediğini sızma testi rehberinde anlattık; hizmet için güvenlik ve sızma testi sayfamıza bakabilirsiniz.

Bir web sitesini paylaşımlı hostinge koyup uzun süre unutabilirsiniz; bir web uygulamasını genellikle hayır. Uygulama sürekli çalışan bir süreç (Node.js, PHP-FPM, .NET), bir veritabanı, çoğu zaman bir kuyruk işçisi ve önbellek ister. Üç yaygın seçenek var: altyapıyı sağlayıcıya bırakan PaaS platformları, kontrolün sizde olduğu VPS veya bulut sunucular ve büyük, sabit yükler için dedicated sunucular. Farklarını web hosting, VPS, bulut ve dedicated farkı yazısında bir hesaplayıcıyla anlattık.

Kişisel veri işleyen uygulamalarda verinin hangi ülkede tutulduğu da bir karar kalemi; KVKK'da yurt dışına aktarım ayrı şartlara bağlı. Türkiye'deki veri merkezlerinde barındırma seçenekleri için bulut sunucu kiralama hizmetimize göz atabilirsiniz.

Uygulama nerede barındırılırsa barındırılsın, yayına alma işi elle yapılmamalı. Kod depoya gönderildiğinde testler otomatik çalışır, uygulama bir Docker imajına paketlenir, önce test (staging) ortamına, onaylanınca canlıya çıkar. Bu hat (CI/CD) kurulduğunda yeni sürüm çıkarmak sıradan bir işe dönüşür; geri dönmek de öyle. Sürüm çıkarmanın korkutucu olduğu ekiplerde sürümler seyrekleşir, her sürüm daha büyük ve daha riskli hâle gelir.

İki ürünümüz, bu yazıda anlattığım kararların birbirine zıt iki örneği. İkisi de web uygulaması; ama kullanıcıları, kurulum yeri ve gelir modeli farklı olduğu için mimarileri de farklı.

Aradaki farkın özeti şu: TYS tek bir kurumun kendi sunucusunda çalışıyor; kurulumu ve güncellemesi kolay tek bir uygulama olması bu bağlamda avantaj. Tuğra AI ise herkese açık, abonelikle satılan bir ürün; arayüz ile API'yi ayırmak, anahtarları tamamen sunucuda tutmak ve ileride başka istemciler eklemek için doğal bir zemin sağlıyor. “Hangisi doğru?” diye sorarsanız cevabım: ikisi de, kendi bağlamında.

Teklif istemeden önce aşağıdaki altı sorunun cevabını yazılı hâle getirirseniz, aldığınız teklifler birbiriyle karşılaştırılabilir olur ve keşif görüşmesi doğrudan işin özüne girer. Sihirbazdaki yanıtlarınız aşağıdaki şablona otomatik işlenir; kopyalayıp kendi notlarınızla tamamlayın.

1. 1Kimler kullanacak ve her biri ne yapacak?Rol sayısı yetki modelini ve test yükünü belirler.Örnek: Bayi sipariş verir ve ekstresini görür; temsilci yalnız kendi bayilerini görür; yönetici hepsini görür ve fiyat onaylar.
2. 2Tek bir ana akış hangisi?İlk sürüm bu akışın uçtan uca çalışmasına göre planlanır.Örnek: Bayinin sipariş vermesi ve siparişin ERP'ye düşmesi.
3. 3Hangi mevcut sistemlerle konuşacak?Karşı tarafın test ortamı, dokümantasyonu ve başvuru süreci sizin elinizde değil.Örnek: Logo Tiger (cari, stok, sipariş), iyzico, e-Fatura entegratörü.
4. 4Kim neyi görmemeli?Veri ayrımı sonradan eklenirse sorgular baştan yazılır.Örnek: Bayi başka bayinin fiyatını ve siparişini görmemeli; temsilci maliyeti görmemeli.
5. 5Hangi yasal yükümlülükler var?KVKK, e-Fatura, İYS ve sektörel düzenlemeler mimariyi etkiler.Örnek: Bireysel müşteri verisi işleniyor; ticari SMS gönderilecek; fatura uygulamadan kesilecek.
6. 6Başarıyı neyle ölçeceğiz?Ölçüt olmadan “bitti mi?” sorusu tartışmaya döner.Örnek: Siparişlerin ERP'ye elle girilmemesi, sipariş başına telefon trafiğinin azalması.

WEB UYGULAMASI PROJE ÖZETİ (taslak)

Ön teşhis: henüz belirlenmedi
Göreli karmaşıklık: …
Giriş yapanlar: … · Roller: …
Veri yazma: … · Ödeme: …
Entegrasyon: … · SEO: …
Mobil/çevrimdışı: … · Çok kiracılık: …
Beklenen katmanlar: …

1. Kimler kullanacak ve her biri ne yapacak?
   Cevabımız: 
   (Örnek: Bayi sipariş verir ve ekstresini görür; temsilci yalnız kendi bayilerini görür; yönetici hepsini görür ve fiyat onaylar.)
2. Tek bir ana akış hangisi?
   Cevabımız: 
   (Örnek: Bayinin sipariş vermesi ve siparişin ERP'ye düşmesi.)
3. Hangi mevcut sistemlerle konuşacak?
   Cevabımız: 
   (Örnek: Logo Tiger (cari, stok, sipariş), iyzico, e-Fatura entegratörü.)
4. Kim neyi görmemeli?
   Cevabımız: 
   (Örnek: Bayi başka bayinin fiyatını ve siparişini görmemeli; temsilci maliyeti görmemeli.)
5. Hangi yasal yükümlülükler var?
   Cevabımız: 
   (Örnek: Bireysel müşteri verisi işleniyor; ticari SMS gönderilecek; fatura uygulamadan kesilecek.)
6. Başarıyı neyle ölçeceğiz?
   Cevabımız: 
   (Örnek: Siparişlerin ERP'ye elle girilmemesi, sipariş başına telefon trafiğinin azalması.)

Bu cevaplar netleştiyse sıradaki adım bir keşif görüşmesi. Teklif formunu doldururken şablonu da ekleyebilirsiniz; ekibimiz kapsamı bu cevaplar üzerinden okur.