Özel Web Yazılım Çözümleri

Fiyatın tek bir rakam olmamasının nedeni basit: bir stok takip modülü ile çok şubeli, ERP'ye bağlı bir B2B portal aynı iş değildir. Teklifte modül listesi, entegrasyonlar, kullanıcı rolleri ve teslim takvimi kalem kalem yazılır; böylece ne için ne ödediğinizi görürsünüz ve teklifler arasında sağlıklı karşılaştırma yapabilirsiniz.

Teklif istemeden önce elinizde süreç tarifi, örnek ekran görüntüsü veya bugün kullandığınız Excel dosyaları varsa paylaşın; kapsam ne kadar netse teklif o kadar isabetli olur. Yazılı teklifi bir iş günü içinde gönderiyoruz.

Teklifte şu satırların ayrı ayrı görünmesini isteyin: keşif ve analiz, UX/UI tasarımı, modül bazlı geliştirme, entegrasyonlar, test ve devreye alma, dokümantasyon ve eğitim, dahil bakım süresi ve tahmini aylık bulut gideri. Her satırın karşılığını görmek teklifleri aynı kapsam üzerinden karşılaştırmanızı sağlar; eksik satır sonradan ek maliyet olarak geri döner.

• Başlangıç: tek modüllü web uygulaması, yönetim paneli, temel API
• Profesyonel: çok modül, rol bazlı yetki, ERP/CRM entegrasyonu, raporlama
• Kurumsal: SaaS/multi-tenant mimari, mikroservis, DevOps, SLA destek
• Her pakette kaynak kod teslimi ve dokümantasyon

En çok maliyet üreten kalem genellikle entegrasyonlardır. Karşı sistemin API'si dokümante ve güncel ise iş hızlı ilerler; eski bir ERP sürümüne dosya aktarımıyla bağlanmak ise ek analiz ve test gerektirir. Rapor ve dashboard ekranları da sayıya göre maliyeti büyütür, çünkü her rapor ayrı bir veri sorgusu ve tasarım demektir.

Piyasa verisi şunu gösteriyor: kapsam netleşmeden verilen tahminler gerçek maliyeti yüzde 20–35 aşıyor; GDPR uyumu bütçeye yüzde 10–15, SOC2 uyumu yüzde 15–25 ekliyor (2026 piyasa aralığı). Bu yüzden teklifi tahmin üzerine değil, kapsam belgesinin üzerine kuruyoruz.

• Modül, ekran ve iş akışı sayısı
• Kullanıcı rolleri, yetki matrisi ve beklenen yük
• ERP, CRM, e-fatura, ödeme ve kargo entegrasyonları
• Uyumluluk: KVKK, GDPR, loglama ve veri saklama kuralları
• Hazır arayüz bileşenleri mi, sıfırdan UX/UI tasarımı mı

Sabit fiyatta kapsam belgesi sözleşmenin eki olur; belge dışındaki her istek değişiklik talebi olarak ayrıca fiyatlanır. Avantajı bütçenin ilk günden belli olmasıdır. Dezavantajı, henüz görmediğiniz ekranlar için bugünden karar vermek zorunda kalmanızdır; bu yüzden sabit fiyat ancak kapsam gerçekten netse işe yarar.

Sprint bazlı modelde iki ila dört haftalık döngülerle çalışılır; her sprint sonunda çalışan bir demo görür, sıradaki öncelikleri siz belirlersiniz. Piyasa pratiğinde fatura sprint başına kesilir; ödeme planının teklifte yazılı olmasını isteyin. İstediğiniz noktada durabilir ya da yön değiştirebilirsiniz. Ürün geliştiren şirketler çoğunlukla bu modeli tercih eder.

• Sabit fiyat: net kapsam, kısa süre, değişiklik talebi ayrı fiyatlanır
• Sprint bazlı: esnek öncelik, sprint sonu demo, ödeme planı teklifte yazılı
• Karma model: keşif ve tasarım sabit fiyat, geliştirme sprint bazlı

Toplam sahip olma maliyetine lisans veya abonelik, kullanıcı başına ücret artışları, entegrasyon için ödenen ek modüller, bakım ve ekibin harcadığı zaman girer. Hazır paketin yetmediği yerde yapılan Excel ve manuel işler de gizli maliyettir; bunu çoğu şirket hesaba katmaz.

Özel yazılımda ilk yatırım yüksek, sonraki yıllarda yalnızca bakım ve sunucu gideri vardır. Yazılım sizin olduğu için kullanıcı sayısı arttıkça ek lisans ödemezsiniz. Süreçleriniz sektör standardından farklıysa ve rekabet avantajınız bu süreçlerdeyse özel yazılım daha hızlı geri döner.

• Hazır paket: düşük başlangıç, kullanıcı başına artan abonelik
• Özel yazılım: yüksek başlangıç, sonrası bakım ve sunucu
• Eşik: 50–200 kullanıcı ve standart dışı süreçler (piyasa aralığı)

Bakım kalemini bütçeye baştan yazın. Tarayıcılar, işletim sistemleri ve bağlı olduğunuz üçüncü parti API'ler her yıl değişir; güncellenmeyen yazılım bir noktada çalışmaz ya da güvenlik açığı verir. Bakım anlaşması bu değişiklikleri sizin yerinize takip eder.

Sunucu maliyeti kullanıcı sayısı, veri hacmi ve trafikle ölçeklenir; küçük bir iç araç ile binlerce eş zamanlı kullanıcılı bir platform aynı altyapıda çalışmaz. Teklif aşamasında tahmini aylık bulut giderinin ayrı bir satır olarak yazılmasını isteyin, böylece yayından sonra sürpriz olmaz.

• Güvenlik yamaları ve bağımlılık güncellemeleri
• Performans izleme ve hata takibi
• Düzenli yedekleme ve geri dönüş testi
• Küçük yeni özellikler ve iyileştirmeler

MVP yaklaşımında 3–5 çekirdek özellik seçilir, geri kalanı bilinçli olarak ertelenir. Bu, bütçeyi korur ve hangi özelliğe gerçekten ihtiyaç olduğunu varsayımla değil kullanımla öğrenmenizi sağlar. İlk kullanıcı geri bildirimi çoğu zaman öncelik listesini değiştirir; bunu her şeyi baştan yaparak değil, küçük bir ilk sürümle öğrenmek daha ucuzdur.

Büyüme yolunun teklifte yazılmasını isteyin: ikinci aşamada hangi modüllerin geleceği, veritabanı şemasının buna nasıl hazırlandığı ve rol bazlı yetkilendirmeye geçişin nasıl olacağı. Böylece MVP çöpe gitmez, ürünün ilk sürümü olur ve ikinci aşama ilk günden planlı ilerler.

• 3–5 çekirdek özellik, gerisi ikinci aşamaya
• 4–8 haftada yayın, gerçek kullanımdan öğrenme
• Aynı kod tabanı ve veritabanı üzerinde büyüme
• Kaynak kod ve dokümantasyon ilk aşamada teslim edilir

Piyasa verileri daha geniş bir bant çiziyor: basit bir iç araç 3–5 ay, müşteriye açık bir platform 6–9 ay sürebiliyor (2026 piyasa aralığı). Aradaki fark çoğunlukla kapsam tanımından gelir; ilk sürümü çekirdek özelliklere indirgeyen projeler daha kısa sürede yayına çıkar, geri kalan modüller ikinci aşamada gelir.

Takvimi uzatan tipik nedenler: entegre edilecek ERP'nin API erişiminin geç gelmesi, test verisinin hazır olmaması ve karar vericinin demolara katılmaması. Bunları projenin başında çözerseniz süre tahmini büyük ölçüde tutar. Demo ritmi iki haftada bir olduğunda geri bildirim birikmez.

Projenin ilk haftaları keşif ve kapsam belgesine gider: mevcut iş akışı, veri kaynakları ve entegrasyon envanteri çıkarılır, öncelikli ekranlar listelenir, her modülün kabul kriteri yazılır. Bu haftalarda kod yazılmaz; ama takvimin tutup tutmayacağı büyük ölçüde burada belli olur, çünkü eksik tanımlanan her modül sprint ortasında geri döner ve süreyi uzatır.

• Tek modüllü web uygulaması: 4–8 hafta
• Çok modüllü kurumsal sistem: 2–4 ay
• SaaS / multi-tenant platform: 4–8 ay
• Keşif ve analiz: piyasa pratiğinde 1–3 hafta

Keşifte mevcut iş akışınızı, kullandığınız programları ve Excel dosyalarını birlikte inceleriz; çıktısı kapsam belgesidir. Tasarım aşamasında ekranlar kodlanmadan önce onayınıza sunulur; akışı kod yazılmadan düzeltmek, yazıldıktan sonra düzeltmekten çok daha ucuzdur.

Geliştirme sprintlerinde her özellik test edilerek teslim edilir; kabul kriterleri kapsam belgesinde yazdığı için 'bitti' tanımı tartışma konusu olmaz. Devreye almada veri aktarımı, kullanıcı eğitimi ve dokümantasyon teslimi yapılır; ardından pakete göre 3 ay ile 1 yıl süren bakım dönemi başlar.

• 1. Keşif ve ihtiyaç analizi (ücretsiz)
• 2. Kapsam belgesi, teklif ve sözleşme
• 3. UX/UI tasarımı ve teknik mimari
• 4. Sprint bazlı geliştirme, demo ve geri bildirim
• 5. Test, kabul ve devreye alma
• 6. Dokümantasyon, eğitim ve bakım

Keşifte sorduğumuz sorular şunlardır: hangi iş akışı bugün en çok zaman kaybettiriyor, veri şu an nerede tutuluyor, hangi sistemlerle konuşulması gerekiyor, kaç kişi hangi yetkiyle kullanacak, başarı nasıl ölçülecek. Cevaplar kapsam belgesinin iskeletini oluşturur ve teklifin kalemlerini belirler.

Kurumsal projelerde daha derin bir analiz fazı gerekebilir: süreç haritalama, veri modeli ve entegrasyon envanteri. Bu fazın ayrı bir iş kalemi olup olmadığını teklifte açıkça sorun. Analizi yapan ekibin geliştirmeyi de yapması, bilginin ekipler arasında kaybolmamasını sağlar; aradaki devir maliyeti ve yanlış anlama riski ortadan kalkar.

• Keşif görüşmesi ve hedeflerin netleşmesi
• Mevcut sistem ve veri envanteri
• Kapsam önerisi ve yazılı teklif (bir iş günü içinde)
• Teknik ekiple ön mimari ve entegrasyon değerlendirmesi

Kapsam belgesi 'raporlama modülü' gibi başlıklardan değil, 'satış müdürü bayi bazında aylık ciro raporunu Excel olarak indirir' gibi doğrulanabilir cümlelerden oluşmalıdır. Belirsiz başlıklar, projenin ortasında iki tarafın farklı şey beklediğinin ortaya çıkmasına yol açar; en pahalı tartışmalar buradan doğar.

Değişiklik talebi süreci yeni fikirleri yasaklamaz; her yeni isteğin süre ve maliyet etkisini görünür kılar. Siz talebi görür, öncelik verir ya da ikinci aşamaya ertelersiniz. Sprint bazlı çalışmada bu konuşma doğal olarak bir sonraki sprint planlamasında yapılır.

• Kabul kriterli kapsam belgesi, sözleşmenin eki
• Değişiklik talebi: etki analizi, onay, sonra geliştirme
• İki haftada bir demo ve geri bildirim
• Tek bir karar verici ve yazılı onaylar

Karar verici, süreçleri bilen ve yetkisi olan biri olmalı; her ekranı yönetim kuruluna sormak zorunda kalan bir muhatap projeyi haftalarca bekletir. Demo toplantıları kısa tutulur ama düzenli olmalıdır; iki hafta birikmiş geri bildirim, iki haftalık yeniden çalışma demektir.

Teknik tarafta ERP veya muhasebe programınızın API anahtarı, örnek veri seti ve varsa mevcut sistemin dokümantasyonu gerekir. Kabul testinde yazılımı gerçek kullanıcılarınız gerçek senaryolarla denemelidir; geliştirici testleri kullanıcıların alışkanlıklarını ve istisnai durumları yakalayamaz; canlıda çıkan sürprizlerin çoğu bu adımda önlenir.

• Yetkili karar verici ve yazılı onay
• Sprint demolarına katılım, hızlı geri bildirim
• API erişimleri, örnek veri ve mevcut dokümanlar
• Gerçek kullanıcılarla kabul testi

Örnekle: kurumsal siteniz hizmetlerinizi anlatır ve form toplar; bayi portalınız ise bayinin fiyat listesini görüp sipariş girdiği, muhasebenin cari bakiyeyi takip ettiği bir yazılımdır. İkisi ayrı projelerdir, farklı uzmanlıklar ve farklı bütçelerle yapılır; biri diğerinin yerini tutmaz.

Masaüstü programların çoğu zamanla web tabanlıya taşınıyor; sebep uzaktan erişim, mobil cihaz desteği ve bakım kolaylığı. Web yazılımı isterseniz PWA olarak telefona da eklenir; mobil uygulama hissi verir, ayrı bir mağaza süreci gerektirmez ve aynı kod tabanıyla çalışır.

• Web sitesi: tanıtım, içerik, iletişim formu
• Web yazılımı: giriş, veri, iş akışı, rapor
• Masaüstü program: kurulum, cihaza bağlı, zor güncelleme
• PWA: web yazılımının telefona eklenen, mağazasız sürümü

TypeScript, kodun hatalarını çalıştırmadan önce yakalar; büyük projelerde bakım maliyetini düşüren temel tercihtir. PostgreSQL karmaşık raporlama ve ilişkisel veri için güçlüdür; MySQL ise mevcut altyapınız buna dayanıyorsa tercih edilir. Docker, uygulamayı geliştirme ortamından sunucuya aynı biçimde taşır; kurulum farklarından doğan hatalar ortadan kalkar.

Teknoloji seçiminde moda değil, projenin ömrü belirleyicidir. Beş yıl sonra güncellenebilecek, geliştiricisi bulunabilecek ve dokümantasyonu güçlü araçları tercih ediyoruz. Mevcut sistemleriniz PHP veya .NET ise entegrasyon API üzerinden kurulur; mevcut teknolojinizi değiştirmenizi gerektirmez ve iki sistem birlikte çalışır.

• Arayüz: React, Next.js, TypeScript
• Sunucu: Node.js, REST API
• Veri: PostgreSQL, MySQL
• Altyapı: Docker, bulut, CI/CD
• Kalite: TypeScript tip denetimi, otomatik test, kod incelemesi

İlk adım envanterdir: hangi veri hangi yöne akacak (cari, stok, sipariş, fatura), ne sıklıkla (anlık, saatlik, gece) ve hata olursa kim görecek. Bu üç soru netleşmeden yapılan entegrasyon canlıda sorun çıkarır; çift kayıt ve stok uyuşmazlığı en sık görülen sonuçtur.

Muhasebe programlarının çoğunda API kullanımı ayrı bir lisansa bağlıdır; bu lisansı program satıcınızdan almanız gerekebilir. Eski sürümlerde API olmadığında veritabanı okuma ya da zamanlanmış dosya aktarımı kullanılır; daha yavaş ama güvenilir çalışır. E-fatura entegrasyonu entegratör firmanızın web servisi üzerinden yapılır.

Entegrasyonun kabulü test ortamında yapılır: örnek cari, stok ve sipariş kayıtları iki yönde aktarılır, kayıt sayıları ve tutarlar karşılaştırılır, bağlantı koptuğunda ne olacağı denenir. Canlıya geçişin ilk günlerinde iki sistem yan yana izlenir; uyuşmazlık raporunun ve hata bildiriminin kimin önüne düşeceği baştan belirlenir.

• ERP/muhasebe: Logo, Netsis, Mikro ve benzerleri
• E-fatura ve e-arşiv entegratör servisleri
• Ödeme: iyzico, PayTR ve banka sanal POS
• Kargo ve pazaryeri API'leri

Tipik modüller: bayi bazlı fiyat ve iskonto, stok görünürlüğü, sipariş ve onay akışı, cari ekstre ve ödeme, kampanya duyuruları, bayi performans raporları. Hangi modülle başlanacağı bugün en çok zaman kaybettiren işe göre seçilir; sipariş ve cari ekstre genellikle ilk aşamanın çekirdeğidir.

Portalın değeri ERP entegrasyonuyla ortaya çıkar: stok ve fiyat ERP'den gelir, sipariş ERP'ye düşer, böylece çift veri girişi olmaz. Bu tür sistemler Profesyonel paket kapsamında, rol bazlı yetkilendirme ve raporlama ile birlikte geliştirilir; süre çoğunlukla 2–4 ay bandındadır ve ilk sürüm sipariş akışıyla açılır.

• Bayi bazlı fiyat, iskonto ve kampanya
• Stok görünürlüğü ve sipariş onay akışı
• Cari ekstre, ödeme ve mutabakat
• ERP ile çift yönlü senkron

Multi-tenant, tek bir yazılımın birçok müşteri firmaya ayrı veri alanlarıyla hizmet vermesidir; SaaS'ın maliyet avantajı buradan gelir. Tasarımda tenant izolasyonu, plan bazlı özellik kısıtı ve kullanım ölçümü baştan kurulmalıdır; bunları sonradan eklemek, ürünü yeniden yazmaya yakın bir maliyet çıkarır.

İş modeli tarafında abonelik planları, deneme süresi, fatura ve KDV akışı, iptal ve veri taşıma kuralları ürünün parçasıdır. Ödeme için iyzico veya PayTR gibi sağlayıcılarla tekrarlayan ödeme kurulur. Ürün yurt dışına açılacaksa çoklu para birimi ve GDPR uyumu kapsam belgesine en başta girer.

Yol haritası MVP ile başlar: ilk sürümde tek bir plan, temel abonelik akışı ve 3–5 çekirdek özellik bulunur; çoklu plan, API erişimi ve gelişmiş raporlama ödeme yapan ilk müşterilerin geri bildirimiyle sıraya girer. Böylece 4–8 aylık takvimin tamamını beklemeden gerçek müşterilerle test eder, kalan bütçeyi varsayıma değil talebe göre harcarsınız.

• Tenant izolasyonu ve plan bazlı özellikler
• Abonelik, tekrarlayan ödeme, faturalama
• CI/CD, izleme ve otomatik ölçeklendirme
• Kullanım analitiği ve yönetim paneli

Planlamada önemli olan, API'nin baştan mobil kullanım düşünülerek tasarlanmasıdır: kimlik doğrulama, sayfalama, çevrimdışı senaryolar ve push bildirim altyapısı sonradan eklenince sunucu tarafında yeniden iş çıkarır. Mobil ihtimali varsa keşif görüşmesinde söyleyin; mimari ona göre kurulur.

Her iş için mobil uygulama gerekmez; saha ekipleri, bayiler ve müşterilere açık hizmetler için anlamlıdır. Ofiste kullanılan bir yönetim paneli için mobil uyumlu web arayüzü ya da PWA çoğunlukla yeterlidir ve mağaza süreci gerektirmez; mağaza yayını yalnızca gerçekten gerekiyorsa planlanır.

• Tek API, web ve mobil istemciler
• Push, çevrimdışı ve kimlik doğrulama baştan planlanır
• Mobil gerekmeyen yerde PWA alternatifi

Uygulama katmanında en yaygın açıklar yetki kontrolü eksikliği, enjeksiyon ve zayıf oturum yönetimidir; bunlar kod incelemesi ve otomatik testlerle yakalanır. Parolalar geri döndürülemez biçimde saklanır, hassas alanlar şifrelenir, tüm trafik HTTPS üzerinden gider ve her istek yetki kontrolünden geçer.

Altyapıda güvenlik duvarı, erişimi kısıtlanmış veritabanı, düzenli yedekleme ve geri dönüş testi bulunur; yedek sıklığını ve saklama süresini teklifte yazılı olarak isteyin. Önemli işlemler loglanır; kim, ne zaman, neyi değiştirdi sorusu cevaplanabilir. Kurumsal projelerde bağımsız sızma testi raporu talep edebilirsiniz; bunun kapsamını ve tekrar sıklığını teklifte netleştirin.

• Rol bazlı yetki, iki aşamalı doğrulama seçeneği
• HTTPS, şifreli depolama, güvenli parola saklama
• Kod incelemesi, güvenlik denetimi, sızma testi
• Düzenli yedek, loglama, güncelleme takvimi
• Hassas işlemler için onay zinciri ve işlem geçmişi

Uygulamada bu şu demek: her tabloda hangi alanın kişisel veri olduğu işaretlenir, saklama süresi dolan kayıtlar otomatik silinir ya da anonimleştirilir, kullanıcı talebiyle veri dökümü alınabilir. Pazarlama izinleri ayrı tutulur, rıza geçmişi tarih ve kaynağıyla saklanır.

Bulut seçimi hukuki bir karardır: KVKK yurt dışına veri aktarımını şarta bağlar, bu yüzden Türkiye lokasyonlu sunucular tercih edilir; GDPR kapsamındaki kullanıcılar için AB bölgesi gerekebilir. Uyum maliyeti 2026 piyasa aralığında GDPR için yüzde 10–15 ek bütçe demektir; hukuki metinleri avukatınızla, teknik tarafı yazılım ekibiyle yürütürsünüz.

Kabul aşamasında uyumluluk da test edilir: bir kullanıcının silme talebi uçtan uca denenir, erişim loglarının kimin neyi görüntülediğini gösterdiği doğrulanır, yetkisiz bir rolün kişisel veriye ulaşamadığı kontrol edilir. Bu testlerin kabul kriterleri arasında yazılmasını isteyin; uyumluluk bir belge olarak değil, çalışan fonksiyonlar olarak teslim edilmelidir.

• Veri envanteri ve amaç sınırlaması
• Aydınlatma, açık rıza ve rıza geçmişi
• Silme, düzeltme ve veri dökümü fonksiyonları
• Erişim logu, yetki ayrımı, veri lokasyonu

Bulutta kaynaklar kullanım kadar faturalanır, yedekleme ve donanım bakımı sağlayıcıya aittir, trafik artışında dakikalar içinde büyüyebilirsiniz. Kendi sunucunuz ise sabit yatırım, bakım personeli ve kesinti riski demektir; veri lokasyonu zorunluluğu ya da mevcut bir altyapı varsa anlamlı olabilir; karar teklif aşamasında maliyet karşılaştırmasıyla verilir.

Ölçeklemeyi gerçekten test etmenin yolu yük testidir: hedeflenen eş zamanlı kullanıcı sayısının birkaç katıyla deneme yapılır, darboğaz görülen sorgular ve servisler düzeltilir. Docker ile paketlenen uygulama farklı bulutlar arasında taşınabilir; tek bir bulut sağlayıcısına bağımlı kalmazsınız.

• Durumsuz API ve yatay ölçekleme
• Veritabanı indeksi, önbellek, iş kuyruğu
• Yük testi ve izleme panoları
• Docker ile taşınabilir altyapı

Devreye alma öncesi kabul testi yapılır: kapsam belgesindeki kabul kriterleri tek tek işaretlenir, açık maddeler kapanmadan canlıya geçilmez. Mevcut sistemden veri aktarımı varsa önce test ortamında denenir, sonra planlı bir kesinti penceresinde gerçek veri taşınır, kayıt sayıları ve bakiyeler karşılaştırılarak doğrulanır.

Dokümantasyon iki türdür: geliştirici dokümanı (mimari, kurulum, API) ve kullanıcı kılavuzu. Eğitim rol bazlı ve uygulamalı verilir; yöneticinin gördüğü ekranla depo personelinin gördüğü ekran farklıdır. Teslim sonrası bakım dönemi pakete göre 3 ay ile 1 yıl arasında dahildir.

• Kabul testi ve kapsam onayı
• Veri aktarımı ve canlıya geçiş planı
• Kaynak kod, dokümantasyon, hesap devirleri
• Rol bazlı kullanıcı eğitimi

SLA, müdahale ve çözüm sürelerinin yazılı taahhüdüdür: kritik bir kesintiye kaç saat içinde müdahale edileceği, küçük hataların hangi sürede kapatılacağı ve bu sürelere uyulmazsa ne olacağı. Kurumsal projelerde bu süreler sözleşmeye yazılır; işletmeniz yazılım olmadan duruyorsa SLA'nın kapsamını teklifte mutlaka sorun.

Bakım anlaşması ile garanti farklıdır: teslim edilen kapsamdaki hatalar dahil bakım döneminde ücretsiz düzeltilir; yeni özellik istekleri ise aylık bakım anlaşmasının kapsamına göre ya da ayrı teklifle yapılır; bu ayrımın sözleşmede yazılı olmasını isteyin. Piyasa pratiğinde yıllık bakım bütçesi yapım maliyetinin yüzde 15–25'i civarındadır; bütçeyi buna göre planlayın.

• Destek saatleri: Pazartesi–Cumartesi 09:00–19:00
• Dahil bakım: 3 ay (Başlangıç), 1 yıl (Profesyonel)
• Kurumsal: SLA kapsamında destek
• Sonrası: aylık bakım anlaşması
• Kapsam: güvenlik, izleme, yedek, yeni özellik

Denetimde şunlara bakılır: teknoloji güncel mi, güvenlik açığı var mı, kaynak kod ve lisans sizde mi, veritabanı yapısı yeni ihtiyaçları taşıyor mu. Dokümantasyonu olmayan ve geliştiricisine ulaşılamayan yazılımlarda genellikle yeniden yazma daha az riskli çıkar; eski kodu çözmeye harcanan zaman yeni kodu yazmaktan uzun sürebilir.

Geçiş kesintisiz planlanır: yeni sistem eski verinin kopyasıyla test edilir, kullanıcılar paralel çalıştırmayla alışır, sonra planlı bir günde tam geçiş yapılır. Eski sistemdeki raporlar ve alışkanlıklar yeni tasarımda korunur; kullanıcı direncini azaltmanın yolu budur ve geçiş sonrası destek yoğunluğunu düşürür.

• Kod, veritabanı ve güvenlik denetimi
• Refactor, kademeli taşıma veya yeniden yazma kararı
• Veri aktarımı ve paralel çalışma dönemi
• Kullanıcı eğitimi ve planlı geçiş

Üç şeyi ayırın: size özel yazılan kod, açık kaynak kütüphaneler ve ajansın önceki projelerden getirdiği altyapı bileşenleri. Size özel kod devredilir; açık kaynak kütüphaneler kendi lisanslarıyla kullanılır; ortak altyapı bileşenleri için sözleşmede süresiz ve bedelsiz kullanım hakkı tanımlanmalıdır.

Kendi ekibinizle devam etmek için gerekenler teslimde elinizde olmalı: güncel kaynak kod, kurulum ve mimari dokümanı, veritabanı şeması, üçüncü parti hesapların sizin adınıza olması. Bunlar varsa geliştirici değişikliği bir risk değil, olağan bir devir işlemidir; yeni ekip dokümantasyondan başlayarak kodu devralır.

• Mülkiyet: tüm haklar ödemeyle birlikte müşteriye geçer
• Teslim: kaynak kod, dokümantasyon, veritabanı şeması
• Açık kaynak lisansları ayrıca listelenir
• Hesaplar ve sunucular müşteri adına açılmalı
• Devir: yeni ekibe teslim için güncel doküman ve erişimler

Kapsam belgesi sözleşmenin eki olmalıdır; sözleşme yalnızca 'web yazılımı yapılacaktır' diyorsa koruma sağlamaz. Ödeme planı kilometre taşlarına bağlanmalı: başlangıç, tasarım onayı, sprint teslimleri, kabul. Böylece ödediğiniz her kalemin karşılığını görmüş olursunuz.

Gizlilik maddesi iş verilerinizi ve süreç bilginizi korur; KVKK gereği veri işleyen sıfatıyla yazılım firmasının yükümlülükleri yazılır. Garanti süresi teslimden sonra hataların ücretsiz düzeltileceği dönemdir; bakım anlaşmasından ayrı tanımlanır. Fesih maddesi, yarım kalan projede kodun ve verinin size nasıl devredileceğini belirler.

• Kapsam belgesi ve kabul kriterleri
• Takvim, kilometre taşı ve ödeme planı
• Değişiklik talebi süreci
• Kaynak kod, fikri mülkiyet, lisanslar
• Gizlilik, KVKK ve veri işleme
• Garanti, bakım, SLA, fesih ve devir

Başlangıç noktası tekrarlayan, metin ağırlıklı ve kural yazması zor işlerdir: sipariş e-postalarını sisteme girmek, teklif taslağı hazırlamak, müşteri yorumlarını özetlemek, destek taleplerini doğru birime yönlendirmek. Bu işlerde model bir ekip arkadaşı gibi çalışır; son onay insanda kalır.

Teknik tarafta veri gizliliği ilk sorudur: hangi veri hangi sağlayıcıya gidiyor, KVKK kapsamında bu mümkün mü, gerekiyorsa veriyi anonimleştirme ya da yerel model seçeneği var mı. Maliyet kullanım bazlıdır; pilotla başlayıp ölçmek, tüm sürece birden yaymaktan daha sağlıklıdır; pilotun sonucu ölçülebilir olmalıdır.

• Destek chatbotu: kendi bilgi tabanınızdan cevap
• Belge ve e-postadan yapılandırılmış veri çıkarma
• Sınıflandırma, önceliklendirme, özetleme
• Raporlama ve doğal dille sorgulama
• Pilot: tek süreç, ölçülebilir hedef, insan onayı

Kazanım en çok tekrar eden kodda, test yazımında ve dokümantasyonda görülür. Buna karşılık iş kuralını yanlış anlamış bir yazılımı hızlı yazmak zaman kazandırmaz; keşif ve kapsam belgesi yapay zeka çağında daha da önemli hale geldi, çünkü üretim hızlanınca yanlış yönde ilerlemek de hızlanıyor.

Yapay zeka ile üretilmiş kodu teslim alırken iki şeyi sorun: kod incelemesinden geçti mi ve test kapsamı var mı. Hızlı üretilen ama kimsenin okumadığı kod, bakım döneminde pahalıya patlar. Gizlilik politikası da sözleşmede yazmalıdır: kodunuz ve veriniz hangi araçlara, hangi koşullarla gidiyor.

• Hızlanan: kod yazımı, birim testi yazımı, dokümantasyon
• Değişmeyen: analiz, entegrasyon, kabul testi, devreye alma
• Kontrol: kod incelemesi, test kapsamı, gizlilik politikası

Fiyatı tek kriter yapmayın: aynı projeye 2026 piyasasında birbirinden çok farklı teklifler gelebiliyor, çünkü her firma kapsamı farklı okuyor. Teklifleri karşılaştırmadan önce hepsine aynı kapsam belgesini verin; o zaman farkın nereden geldiğini görürsünüz.

Görüşmede sorulacak sorular: bu projeyi kim geliştirecek, sprint demosu ne sıklıkla yapılıyor, kod hangi depoda tutulacak, iş bitince destek saatleri ne, önceki müşterilerle konuşabilir miyim. Net cevap alamadığınız madde, ileride sorun çıkacak maddedir. Aldığınız cevapların yazılı teklife de yansımasını isteyin; sözleşmede yazmayan sözlü vaat ileride elinizde bir şey bırakmaz.

• Canlı referans ve benzer sektör deneyimi
• Yazılı kapsam, kabul kriteri, takvim
• Kaynak kod devri ve dokümantasyon
• Tanımlı destek saatleri ve bakım modeli
• Analiz, tasarım ve geliştirmenin aynı ekipte olması

Özel CRM, standart CRM'in teklif, sözleşme ve servis akışınıza uymadığı, ekibin sistemi kullanmayı bıraktığı durumlarda anlamlıdır. Özel ERP ise büyük iştir; çoğu zaman doğru yol mevcut ERP'yi korumak, üstüne bayi portalı, üretim takibi ya da saha satış gibi özel modüller eklemektir.

Karar için üç soru sorun: bu süreç bize para kazandıran bir fark mı, hazır paketi uyarlamak için ne kadar ek modül ve danışmanlık ödeyeceğiz, 3–5 yıllık toplam maliyet hangi tarafta düşük. Cevaplar netse seçim de nettir; netleşmiyorsa keşif görüşmesinde birlikte bakarız.

• Hazır paket: standart süreç, mevzuat işleri, küçük ekip
• Özel yazılım: size özgü süreç, entegrasyon yoğun işler, ölçek
• Karma: mevcut ERP + özel modüller (portal, üretim, saha)