Özel yazılım ihtiyacı çoğu zaman tek bir soruyla belli olur: "Bu fiyatı kim değiştirdi?" Siparişler bir tabloda, onaylar e-postada, müşteri notları birinin telefonunda durduğunda bu sorunun cevabı yoktur. Bir uygulamaya geçmek işi hızlandırır; ama asıl kazanç, her işlemin kimin adına ve ne zaman yapıldığının artık kayıtlı olmasıdır.
Özel yazılım ne zaman doğru seçimdir?
Hazır bir ürün işinizi görüyorsa özel yazılım gereksiz bir maliyettir; analizde ilk baktığımız şey budur. Kabaca üç yol var:
| Yol | Uygun olduğu durum | Dikkat edilecek |
|---|---|---|
| Hazır ürün (abonelik) | Süreç sektörde standart; muhasebe, bordro, e-fatura gibi kuralları sık değişen alanlar | Verinin dışa aktarılabilmesi, API'nin varlığı, abonelik bittiğinde verinin ne olacağı |
| Hazır ürün ve uyarlama | Ana süreç standart, birkaç adım size özgü | Uyarlamanın ürün güncellemelerinde bozulması, eklenti tedarikçisine bağımlılık |
| Özel yazılım | Süreç işinizin farkını oluşturuyor, birden çok sistemi birleştirmek gerekiyor ya da verinin sizin denetiminizde kalması şart | Bakım sorumluluğu sizde; kodun, belgelerin ve hesapların devredilebilir olması gerekir |
Bizce en pahalı hata, hazır bir ürünün yapamadığı tek bir adım yüzünden bütün sistemi sıfırdan yazmaktır. Çoğu zaman doğru cevap, hazır ürünü korumak ve eksik adımı ona API ile bağlanan küçük bir uygulamayla çözmektir. Bağlantı tarafı backend, API ve entegrasyon sayfamızın konusu.
Hangi uygulamaları geliştiriyoruz?
Yönetim panelleri ve kurumsal iç uygulamalar
Kurumsal yazılım dediğimiz işlerin çoğu, bir ekibin gün boyu kullandığı bir yönetim panelidir: kayıt listeleri, filtreler, onay ekranları, toplu içe ve dışa aktarma. Zor olan ekranlar değil yetkilerdir. Rol ve yetki matrisini şartnamede tablo olarak yazar, her istekte sunucu tarafında kontrol ederiz; düğmeyi arayüzde gizlemek yetki kontrolü değildir. Silinen kayıt gerçekten silinmez, arşivlenir ve kimin arşivlediği denetim kaydına geçer.
CRM sistemleri
CRM'de ilk sorun neredeyse her zaman aynı firmanın üç farklı yazımla üç kez kaydedilmesidir. Vergi numarası, telefon ve e-posta alanlarını kayıt anında normalize eder, olası mükerrer kayıtları birleştirme ekranında gösteririz. Görüşme geçmişi, teklifler ve fırsat aşamaları müşteri kartında tek zaman çizelgesinde durur. İletişim izinlerinin hangi kanaldan, hangi metinle, hangi tarihte alındığını ayrı bir kayıt olarak tutarız: KVKK Aydınlatma Tebliği'ne göre aydınlatma ile açık rıza ayrı ayrı yapılır ve aydınlatmanın ispatı veri sorumlusuna düşer (m.5/1-e ve f). Metnin hangi sürümünün gösterildiği kaydedilmemişse bu ispat zorlaşır.
E-ticaret sistemleri
Perakende satış için hazır e-ticaret altyapıları çoğu zaman yeterlidir. Özel geliştirme; bayiye özel fiyat listesi, ERP'den anlık stok, sipariş başına onay akışı gibi B2B ihtiyaçlarda anlam kazanır. İki kuralımız var. Kart numarası sunucunuza hiç uğramaz; ödeme kuruluşunun barındırdığı ödeme sayfası ya da gömülü formu kullanılır. Bu, PCI DSS kapsamını daraltır ama ortadan kaldırmaz: ödeme formunu içeren sayfadaki betiklerin de korunması gerekir (PCI SSC açıklaması). İkinci kural: siparişin durumu açık bir durum makinesiyle yönetilir, ödeme kuruluşunun bildirimi (webhook) iki kez gelse de sipariş iki kez onaylanmaz, stok iki kez düşmez.
İş süreçleri otomasyonu
Satın alma talebi, izin onayı, sözleşme yenileme hatırlatması, teklif hazırlama: e-posta zincirinde yürüyen her süreç otomasyona adaydır. Önce bugünkü akışı istisnalarıyla birlikte çizeriz ("müdür izindeyse kim onaylar?"). Bozuk bir süreci otomatikleştirmek onu yalnızca hızlandırır. Otomasyonun yan ürünü de değerlidir: her onayın kimin tarafından, hangi saatte, belgenin hangi sürümü üzerinden verildiği kendiliğinden kayda geçer.
SaaS geliştirme
Aynı uygulamayı birden çok müşteriye abonelikle sunacaksanız temel soru, müşteri verilerinin birbirinden nasıl ayrılacağıdır. Her kayıtta bir kiracı kimliği (tenant_id) tutar, PostgreSQL kullanılıyorsa ayrımı satır düzeyi güvenlikle (row level security) veri tabanında da zorlarız. Tuzak ayrıntıdadır: PostgreSQL belgelerine göre tablo sahibi rol, FORCE ROW LEVEL SECURITY verilmedikçe bu kurallara normalde takılmaz; uygulama tablo sahibi rolle bağlanıyorsa ayrım kâğıt üzerinde kalır.
Platform kullanıcıların içeriğini barındıracaksa 5651 sayılı Kanun anlamında yer sağlayıcı sayılıp sayılmadığı sorusu doğar; bu nitelendirme avukatınıza aittir. Yer sağlayıcı, trafik bilgisini (m.2/1-j: IP adresi, kaynak ve hedef port bilgisi, hizmetin başlama ve bitiş zamanı gibi; "kaynak ve hedef" ibaresi 31.07.2026'da yürürlüğe giren 7590 sayılı Kanunla eklendi) saklamakla yükümlüdür. Kanun süreyi bir yıldan az ve iki yıldan fazla olmamak üzere yönetmeliğe bırakır (m.5/3); 2007 tarihli Usul ve Esaslar Hakkında Yönetmelik'te (m.7/1-c) ise altı ay yazar. Hangi sürenin uygulanacağını avukatınızla netleştirin, saklama ve silme işlerini ona göre kurarız.
Web uygulaması ve frontend geliştirme
Arayüzü tarayıcıda çalışan bir uygulama olarak yazarız; ama doğrulama kuralları her zaman sunucuda da çalışır. OWASP'ın log rehberine göre açılır liste gibi sonlu bir değer kümesine karşı sunucuda doğrulama hatası alınması, istemci kodunun kurcalandığına dair güçlü bir işarettir; bu hataları ayrıca kaydederiz. Erişilebilirlik ölçütü olarak WCAG 2.2'nin AA düzeyini öneririz: bütün işlemler klavyeyle yapılabilir, kontrast yeterlidir, form alanlarının ekran okuyucunun anlayacağı etiketleri vardır. Yönetim panelleri sahada çoğu zaman eski bir Android telefonda açılır; testleri o cihaz sınıfında da yaparız. Halka açık sayfalarda hız ve Core Web Vitals, kurumsal web sitesi sayfasının konusu.
Denetim kaydı (audit log) nasıl tasarlanır?
Denetim kaydı, uygulamadaki her önemli işlem için kimin, neyi, ne zaman, nereden ve hangi sonuçla yaptığını ayrı bir tabloda tutan, uygulama kullanıcılarının değiştiremediği kayıttır. Alanları OWASP Logging Cheat Sheet'teki "ne zaman, nerede, kim, ne" ayrımına göre kurarız:
| Alan | Örnek | Neden |
|---|---|---|
occurred_at | 2026-09-27T09:15:42.318Z | Olay anı; UTC, milisaniyeyle |
actor_id, actor_role | kullanıcı 1042, "muhasebe" | İşlem anındaki yetki; rol sonradan değişebilir |
source_ip, source_port | 203.0.113.25, 51734 | CGNAT arkasındaki kullanıcıları ayırmak için IP yetmez, kaynak port da gerekir (RFC 6302) |
request_id | 9f2c… | Aynı işlemin uygulama, API ve veri tabanı kayıtlarını birleştirmek için |
action, object | price.update, ürün 88 | Ne yapıldı, neye yapıldı |
before, after | {"price": 1250} → {"price": 990} | Değişikliğin kendisi; yalnızca son hâl yetmez |
result, reason | reddedildi, "yetki yok" | Başarısız denemeler de kayıttır |
app_version | commit a1b2c3d | Olay anında hangi kodun çalıştığı |
Parola, oturum kimliği, erişim anahtarı (token) ve kart bilgisi bu kayda yazılmaz; OWASP bunları doğrudan loglanmaması gerekenler arasında sayar. Kişisel veriyi gerektiği kadar tutar, gerisini maskeleriz.
Kaydın güvenilirliği için uygulamanın veri tabanı kullanıcısına bu tabloda yalnızca ekleme yetkisi verilir, güncelleme ve silme yetkisi verilmez. Her satır bir öncekinin özet değerini (hash) taşır; aradan silinen ya da değiştirilen bir satır zinciri bozar. Yüksek güven gereken sistemlerde kayıtlar düzenli aralıklarla tek seferlik yazılabilir (write-once) bir depolamaya kopyalanır; NIST SP 800-92 de bunu seçeneklerden biri olarak anar. Sınırı da yazalım: veri tabanının tamamına yetkili bir yönetici her şeyi değiştirebilir. Hash zinciri bunu engellemez, fark edilmesini sağlar. Bu kayıtların bir uyuşmazlıkta nasıl okunduğunu log kayıtlarının güvenilirliği yazısında anlattık.
Zaman damgaları: hangi saat, hangi dilim?
Bir kayıttaki saat, ancak hangi referansla yazıldığı biliniyorsa işe yarar. Uyguladığımız kurallar:
- Zamanlar veri tabanında UTC olarak, saat dilimi bilgisi taşıyan sütunlarda saklanır. Dışa aktarımda RFC 3339 biçimi kullanılır:
2026-09-27T09:15:42Zya da2026-09-27T12:15:42+03:00. - Ekranda Türkiye saati gösterilir; çeviri sabit "+3 saat" eklenerek değil,
Europe/Istanbulbölge adıyla yapılır. Türkiye 2016'dan beri sürekli UTC+3 kullanıyor, daha eski kayıtlarda kış aylarında fark UTC+2'ydi (IANA saat dilimi veri tabanı). Ayrıntısı zaman damgaları ve saat dilimi yazısında. - Kayıt zamanını tek bir kaynak yazar: ya veri tabanı ya uygulama sunucusu. İkisi karışınca aynı işlemin iki kaydı arasında açıklanamayan farklar çıkar.
- Bütün sunucular NTP ile senkron tutulur. RFC 5905'in varsaydığı 15 ppm frekans toleransıyla hesaplandığında, senkronize edilmeyen bir saat günde 1,3 saniyeye kadar kayabilir.
5070 sayılı Elektronik İmza Kanunu m.3/h'ye göre zaman damgası, bir verinin üretildiği, değiştirildiği, gönderildiği, alındığı veya kaydedildiği zamanı tespit etmek için elektronik sertifika hizmet sağlayıcısınca elektronik imzayla doğrulanan kayıttır. Bir created_at alanı bu tanıma girmez. Sözleşme onayı gibi, bir kaydın belirli bir anda var olduğunu üçüncü kişilere karşı göstermeniz gereken yerlerde bu hizmetin entegrasyonunu ayrıca planlarız. Unix zaman değerlerini okunur tarihe çevirmek için zaman damgası dönüştürücüyü kullanabilirsiniz.
Bir proje nasıl ilerler?
- Keşif. Süreci kullanan kişilerle konuşur, bugünkü akışı istisnalarıyla çizeriz. Çıktı: süreç haritası, rol listesi, veri envanteri.
- Kapsam ve kabul kriterleri. Gereksinimler numaralı ve ölçülebilir yazılır, her biri için kabul senaryosu hazırlanır. Ayrıntısı teknik şartname sayfamızda.
- Tıklanabilir prototip. Ana ekran akışları kod yazılmadan gösterilir. Yanlış anlaşılmış bir ekranı burada düzeltmek, kodu yazıldıktan sonra düzeltmekten çok daha ucuzdur.
- Aşamalı geliştirme. Kısa aralıklarla test ortamında çalışan sürüm; her aralığın sonunda hangi kabul senaryolarının geçtiği görülür.
- Veri taşıma provası. Eski tablolardan ve sistemlerden gelen veri, canlıya geçişten önce en az bir kez gerçek hacimle aktarılır.
- Kabul ve canlıya geçiş. Kabul senaryoları teslim edilen sürümde koşulur, sonuç tutanağa geçer.
Başlamak için neye ihtiyacımız var?
- Bugünkü süreci anlatan birkaç paragraf ya da elle çizilmiş bir akış; düzenli olması gerekmez.
- Kullandığınız form, teklif, fatura gibi örnek belgeler.
- Mevcut veriden anonimleştirilmiş bir örnek. Gerçek müşteri listesini ilk aşamada göndermeyin; yapıyı görmemiz yeterli.
- Kullanıcı rolleri ve kimin neyi onayladığı.
- Bağlanılacak sistemler (ERP, muhasebe, ödeme, kargo) ve varsa API belgeleri.
- Denediğiniz hazır ürünler ve onlarda neyin eksik kaldığı; takvim ve bütçe aralığı.
Teslimde neler alırsınız?
- Kaynak kod deposu, tüm geçmişiyle, sizin hesabınızda.
- Etiketlenmiş teslim sürümü ve paketin SHA-256 değeri; aynı değeri hash hesaplama aracıyla siz de doğrulayabilirsiniz.
- Kabul testi sonuçları ve tutanak.
- Kurulum, yedekleme ve geri yükleme belgesi; geri yükleme teslimden önce en az bir kez denenir.
- Veri modeli ve denetim kaydı alanlarının açıklaması.
- Üçüncü taraf bileşenlerin ve lisanslarının listesi (SBOM).
Sık gördüğümüz hatalar
- "Excel'deki her şey" kapsamı. Tablo yıllar içinde herkesin kendi sütununu eklediği bir belgedir; hangi sütunun hâlâ kullanıldığı sorulmadan taşınırsa eski karmaşa yeni sisteme geçer.
- Yetkilerin sona bırakılması. Rol ayrımı en sonda eklendiğinde her ekranda ayrı ayrı yamanır ve bir yerde mutlaka unutulur.
- Yönetim panelinin loglanmaması. "Nasılsa içeriden kullanılıyor" diye denetim kaydı tutulmayan panel, bir uyuşmazlıkta ya da veri ihlalinde ilk bakılan yerdir.