Özel yazılım geliştirme: işinize göre yazılım, kaynak kodu sizde.

Özel yazılım geliştirme nedir, hazır yazılımdan farkı ne?

Özel yazılım geliştirme, bir şirketin kendi iş kurallarına, kullanıcı rollerine ve mevcut sistemlerine göre tasarlanan yazılımı sıfırdan üretme işidir. Bizim odağımız web tabanlı yazılımdır: tarayıcıdan çalışan, kurulum gerektirmeyen ve her cihazdan açılan müşteri portalı, yönetim paneli, SaaS ürünü, iç araç ya da API. Hazır yazılımda siz ürüne uyarsınız; özel yazılımda ise yazılım sizin sürecinize uyar.

Dürüst olalım: her ihtiyaç özel yazılım gerektirmez. Muhasebe, e-posta pazarlaması ya da basit bir müşteri listesi için hazır bir SaaS ürünü çoğu zaman daha ucuz ve daha hızlıdır. Özel yazılım şu durumlarda anlam kazanır:

• Farkınız sürecinizdeyse: kendi fiyatlama mantığınız, onay akışınız ya da bayi yapınız hazır ürüne sığmıyorsa.
• Sistemler kopuksa: ekibiniz ERP, CRM ve e-ticaret verisini her gün elle taşıyorsa.
• Lisans maliyeti büyüyorsa: kullanıcı başı abonelik ekiple birlikte katlanıyorsa.
• Ürünü siz satacaksanız: yazılımın kendisi abonelikle satacağınız bir SaaS ürünüyse.

Buna karşılık özel yazılımın da bir bedeli var: ilk yatırım daha yüksektir ve ürünün yol haritası artık sizin sorumluluğunuzdadır. Bu nedenle kararı sezgiyle değil, birkaç yıllık toplam maliyet karşılaştırmasıyla vermenizi öneririz. Örneğin ekibiniz büyüdükçe kullanıcı başı lisans bedeli de büyür; özel yazılımda bu kalem yoktur, yerine barındırma ve bakım gelir.

Sınırı da baştan çizelim. Şirketinizi tanıtan kurumsal site web tasarım, iOS ve Android uygulaması ise mobil uygulama geliştirme hizmetimizin konusudur. Hazır altyapı ile özel kodlama arasındaki farkı web siteleri özelinde WordPress mi özel kodlama mı yazımızda anlattık.

Hangi işler özel yazılım gerektirir?

Özel yazılım en çok, birden fazla kişinin aynı veriye farklı yetkilerle dokunduğu işlerde değer üretir. Geliştirdiğimiz başlıca yazılım türleri şunlardır:

• Müşteri ve bayi portalı: sipariş, teklif, belge ve destek talebini tek ekranda toplayan, her kullanıcıya yalnız kendi verisini gösteren portal.
• Yönetim paneli ve iç araçlar: ekibinizin iş emrini, stok hareketini ya da onay akışını yürüttüğü panel.
• SaaS ürünü: abonelikle satacağınız, her müşteriye ayrı bir alan açan çok kiracılı yazılım.
• API ve entegrasyon katmanı: sistemlerinizi birbirine bağlayan, iş ortaklarınıza kontrollü veri açan servis.
• Eski sistem modernizasyonu: bakımı zorlaşmış bir yazılımı modül modül yenileme.

Sektöre göre örnekler resmi netleştirir. Lojistikte sevkiyat ve teslimat takibi, üretimde iş emri ve kalite kaydı, hizmet firmalarında teklif ve sözleşme onayı, eğitim kurumlarında kayıt ve ders planlaması tipik ihtiyaçlardır. Kurumsal yazılım geliştirme projelerinde ise bağımsız bir uygulamadan çok, mevcut sistemleri tek akışta birleştiren bir katman ihtiyacı öne çıkar. Özellikle birden çok şubesi, bayisi ya da iş ortağı olan şirketlerde portal, e-posta ve telefonla yürüyen soru trafiğini tek bir ekrana taşır. Ayrıca her işlem kayda girdiği için kimin neyi ne zaman değiştirdiği sorusu cevapsız kalmaz.

Bir çevrim içi mağaza kuracaksanız ürün ve sepet kurgusu e-ticaret danışmanlığı kapsamındadır. Bayi siparişi ya da firmaya özel fiyat listesi gibi mağazaya sığmayan kurallar ise özel yazılım işidir. Bu yazılımların sunucu tarafında neler olduğunu merak ediyorsanız backend nedir yazımız iyi bir başlangıçtır.

Keşif aşaması ve MVP: ilk sürüm nasıl sınırlanır?

Yazılım projelerinde en pahalı hata, neyin geliştirileceği netleşmeden kod yazmaya başlamaktır. Bu yüzden her projeye ücretli bir keşif aşamasıyla başlarız. Keşifte paydaşlarla atölye yapar, mevcut süreci haritalar, veri modelini ve mimariyi tasarlarız. Ardından ana akışları tıklanabilir bir prototiple sınar, kapsam belgesini ve sabit fiyatlı geliştirme teklifini hazırlarız. Keşfin sonunda elinize dört çıktı geçer: süreç haritası, veri modeli ve mimari özeti, tıklanabilir prototip ve kabul kriterli kapsam belgesi. Böylece geliştirme tekliflerini de aynı kapsam üzerinden karşılaştırabilirsiniz.

Keşfin ayrı fiyatlanmasının nedeni basittir: ücretsiz bir keşif ya yüzeysel kalır ya da maliyeti sessizce teklifin içine girer. Geliştirmeye bizimle devam ederseniz keşif bedelini geliştirme bedelinden düşeriz. Devam etmezseniz kapsam belgesi ve prototip yine sizde kalır; bu belgelerle başka bir ekipten de teklif alabilirsiniz. Elinizde bir ihtiyaç listesi varsa süreç hızlanır; nasıl hazırlayacağınızı brief hazırlama yazımızda anlattık.

MVP, yani en küçük uygulanabilir ürün, fikri gerçek kullanıcıyla sınayan ilk sürümdür. MVP yazılımda olmazsa olmaz işlevleri ilk sürüme, iyi olur dediklerinizi sonraki sürümlere yazarız. Örneğin bir bayi portalında sipariş, stok görme ve fatura indirme ilk sürüme girer; kampanya motoru ve gelişmiş raporlar ikinci aşamaya kalır. Geliştirmeyi iki haftalık sprintlerle yürütür, her sprint sonunda test ortamında çalışan bir sürüm gösteririz. Bu çalışma biçimini Agile ve Scrum yazımızda ayrıntılı anlattık.

ERP entegrasyonu nedir, mevcut sistemlerinize nasıl bağlanırız?

ERP entegrasyonu; ERP, CRM, muhasebe, e-fatura, ödeme ve kargo gibi sistemlerin veriyi insan eli değmeden ve kurallı biçimde alıp vermesidir. Doğru kurulduğunda ekibiniz siparişi bir kez girer; stok, fatura ve müşteri kaydı kendiliğinden güncel kalır. Yanlış kurulduğunda ise sessizce kaybolan kayıtlar ve çift faturalar ortaya çıkar. Bu yüzden entegrasyonu bir ara görev değil, ayrı bir katman olarak tasarlarız:

• Önce inceleme: sistemin sunduğu yolu çıkarırız: API, web servis, webhook ya da dosya aktarımı. Logo, Mikro ya da Netsis gibi yaygın ERP ve muhasebe yazılımlarında bu yol, kullandığınız ürüne ve sürüme göre değişir.
• Kuyruk ve yeniden deneme: karşı sistem yanıt vermezse yazılım isteği sıraya alır ve belirli aralıklarla yeniden dener.
• Tekrar koruması: aynı sipariş iki kez gelse bile tek kayıt oluşur; teknik adıyla idempotency.
• Kayıt ve uyarı: her veri alışverişini loglar, hata olduğunda ilgili kişiye bildirim göndeririz.

Ancak her sistem aynı olgunlukta değildir. Bazı eski sürümler yalnız planlı dosya aktarımına izin verir; bu durumda anlık eşitleme yerine belirli saatlerde çalışan bir akış kurarız. Kısacası entegrasyonun sınırlarını keşifte açıkça yazarız, sürprizi canlıya bırakmayız.

Fatura tarafında e-Fatura ve e-Arşiv için çalıştığınız özel entegratörün API'sini, ödeme için ödeme kuruluşunun resmi entegrasyonunu kullanırız. Mevcut sitenizin ya da portalınızın hangi altyapıyla çalıştığını görmek için site altyapı tespiti aracımızı deneyebilirsiniz. Web sitesi, CRM ve ERP bağlantılarının örneklerini kurumsal entegrasyonlar yazımızda topladık.

Kaynak kod, depo ve fikri haklar kimde kalır?

Kısa cevap: sizde. Ancak bunu sözlü bir söz değil, sözleşme ve hesap yapısı sağlar. Türkiye'de Fikir ve Sanat Eserleri Kanunu (FSEK) m.2, bilgisayar programlarını ve hazırlık tasarımlarını ilim ve edebiyat eseri olarak tanımlar. Aynı kanunun 52. maddesi ise mali haklara dair sözleşmelerin yazılı olmasını ve konusu olan hakların ayrı ayrı gösterilmesini şart koşar. Yani sözleşmedeki genel bir devir cümlesi yetmeyebilir.

Uygulamada şu düzeni kurarız:

• Depo ilk günden sizin: kod deposunu, bulut hesabını ve alan adını kendi şirketiniz adına açarsınız; ekibimize rol ile erişim verirsiniz.
• Haklar yazılı ve tek tek: size özel yazdığımız kodun işleme, çoğaltma, yayma ve umuma iletim gibi mali haklarını sözleşmeyle size devrederiz.
• Açık kaynak listesi: kullandığımız açık kaynak kütüphaneler kendi lisanslarıyla kalır; teslimde lisans listesini veririz.
• Şifre yok: hesaplarınızın şifresini istemeyiz; erişimi kişiye özel hesaplar ve iki adımlı doğrulamayla yönetiriz.

Ayrıca teslimde yalnız kodu değil; veritabanı şemasını, kurulum adımlarını ve ortam değişkenlerinin listesini de alırsınız. Böylece devir kâğıt üzerinde kalmaz.

Hukuki danışmanlık vermediğimizi de açıkça belirtelim. Sözleşme metnini kendi hukuk danışmanınızla netleştirmenizi öneririz; biz devrettiğimiz bileşenlerin teknik listesini hazırlarız. Bu düzen sayesinde yazılımı yarın başka bir ekiple sürdürmek isterseniz tek engel, yeni ekibin kodu okuma süresi olur. Kanun metnine mevzuat.gov.tr üzerinden ulaşabilirsiniz.

Güvenliği hangi standarda göre kuruyoruz?

Güvenliği yayından önceki son haftaya bırakmayız; onu bir gereksinim olarak kapsam belgesine yazarız. Referansımız OWASP'tır. OWASP Top 10:2025 listesinin ilk sırasında bozuk erişim kontrolü (Broken Access Control) yer alır; yanlış yapılandırma, yazılım tedarik zinciri hataları ve enjeksiyon da listededir. Uygulama güvenliği doğrulama standardı ASVS'nin güncel kararlı sürümü ise 5.0.0'dır. Hedef ASVS seviyesini projenin riskine göre kapsam belgesine yazarız.

Pratikte her projede şu kontrolleri uygularız:

• Yetki sunucuda: her istekte kullanıcının o veriyi görme hakkını sunucu tarafında denetleriz; yalnız arayüzde gizlemek yetmez.
• Gizli anahtar yönetimi: API anahtarlarını ve parolaları koddan ayrı, ortam bazlı ve erişimi sınırlı tutarız.
• Bağımlılık taraması: kütüphanelerdeki bilinen açıkları yayından önce ve bakım boyunca tararız.
• Kayıt ve uyarı: kritik işlemleri denetim izine yazar, şüpheli girişlerde uyarı üretiriz.
• Yedek ve geri dönüş: düzenli yedek alır, geri yükleme adımını gerçekten deneriz.

Üstelik güvenlik yalnız koddan ibaret değildir: sunucu yapılandırması, yedeklerin şifrelenmesi ve projeden ayrılan kişilerin erişimlerinin kapatılması da aynı listenin parçasıdır. Güvenlik garantisi veren bir ekibe temkinle yaklaşın; hiçbir yazılım sıfır riskli değildir. Kişisel ya da finansal veri işleyen projelerde ayrıca bağımsız bir sızma testi öneririz. Canlı sistemin sertifikasını SSL sorgulama aracıyla kontrol edebilir, yönetici hesapları için güçlü parolaları şifre oluşturucu ile üretebilirsiniz. En yaygın açıkların örnekli anlatımı OWASP Top 10 yazımızda.

KVKK, GDPR ve erişilebilirlik yazılıma nasıl yansır?

Kişisel veri işleyen her yazılım, hukuki bir sorumluluğu da taşır. KVKK m.12, veri sorumlusunu hukuka aykırı işlemeyi ve erişimi önleyecek teknik ve idari tedbirleri almakla yükümlü tutar. Biz bu tedbirlerin teknik tarafını tasarımın ilk gününe koyarız: yalnız gereken veriyi toplar, rol bazlı erişim kurar, kişisel veriye kimin ne zaman eriştiğini kayda alırız. Saklama süresi dolan veriyi silen kuralları da baştan yazarız.

Barındırma yeri de önemlidir. Bu arada verinin nerede tutulacağına keşifte birlikte karar veririz; örneğin verinin yurt içinde kalmasını istiyorsanız yurt içi bir veri merkezi seçer, yurt dışı servisleri buna göre sınırlarız. Veri yurt dışındaki bir buluta ya da API'ye gidiyorsa KVKK m.9 devreye girer; 7499 sayılı Kanunla gelen değişiklikten sonra standart sözleşme yolunda sözleşmeyi imzadan itibaren beş iş günü içinde Kurum'a bildirmek gerekir.

AB'deki kişilere hizmet veriyorsanız GDPR da uygulanabilir. Canlı sistemi biz barındırıyor ya da bakımını yapıyorsak, GDPR m.28'deki gibi veri işleyen sıfatıyla yazılı bir veri işleme sözleşmesi imzalarız. Genel çerçeve için KVKK ve GDPR uyumu yazımıza bakabilirsiniz.

Erişilebilirliği ise birçok ekip unutur. AB Erişilebilirlik Yasası (Direktif 2019/882), 28 Haziran 2025'ten beri AB'deki tüketicilere sunulan belirli hizmetleri kapsar: e-ticaret, tüketici bankacılığı, e-kitap, elektronik haberleşme ve yolcu taşımacılığının dijital öğeleri. Hizmet sunan mikro işletmeler muaftır. Tüketiciye bu hizmetlerden birini sunuyorsanız erişilebilirlik sizin için zorunlu olabilir. İç araçlarda zorunlu olmasa bile W3C'nin WCAG 2.2 AA düzeyini iyi uygulama olarak hedefleriz. Renk kontrastını renk kontrast kontrolü aracıyla ölçebilir, temel ilkeleri web erişilebilirliği yazımızda okuyabilirsiniz.

Özel yazılım geliştirmede sabit fiyat mı, adam/gün mü?

Özel yazılım fiyatlarını iki temel model belirler: sabit fiyat ve zaman ile malzeme, yani adam/gün. İkisinin de doğru olduğu durumlar var:

• Sabit fiyat: kapsam belgesi netse en öngörülebilir modeldir. Bedel, takvim ve teslimler yazılıdır; riski büyük ölçüde geliştirici taşır. Bu yüzden sabit fiyatı keşiften sonra veririz, önce değil.
• Zaman ve malzeme: ürünün yönü henüz netleşmemişse daha esnektir. Sprint bazlı çalışır, harcanan emeği şeffaf raporlar ve bütçeye bir üst sınır koyarız.

Hangi modeli seçerseniz seçin, kapsam değişikliği projelerin doğal bir parçasıdır. Önemli olan değişikliğin nasıl yönetildiğidir. Yeni bir talep geldiğinde etkisini süre ve bedel olarak yazılı fiyatlar, onayınız olmadan işe başlamayız. Ödemeyi de aşamalara böleriz; her aşamanın sonunda çalışan bir sürüm ve sizin onayınız olur. Özetle, belirsiz bir ürüne sabit fiyat istemek riski gizler; net bir kapsama adam/gün uygulamak ise bütçeyi gereksiz yere açık bırakır.

Bazı teklifler fiyatı sayfa ya da ekran sayısıyla hesaplar. Yazılımda bu yöntem yanıltıcıdır, çünkü maliyeti ekranlar değil, arkadaki iş kuralları ve entegrasyonlar belirler. Tek ekranlık bir onay akışı, on ekranlık bir listeleme modülünden daha fazla emek isteyebilir. Keşfin sabit fiyatını, MVP'nin başlangıç fiyatını ve Kurumsal tabanı bu sayfanın Fiyatlar bölümünde görebilirsiniz. Bedeli belirleyen faktörleri de yukarıda tek tek sıraladık.

Canlıya geçişten sonra bakım ve SLA nasıl işler?

Yazılım canlıya çıktığı gün bitmez. İşletim sistemleri, tarayıcılar, kütüphaneler ve bağlandığınız servislerin API'leri değişir; yeni güvenlik açıkları ortaya çıkar. Güncellenmeyen bir yazılım önce yavaşlar, sonra bozulur. Bu yüzden bakımı projenin ilk gününden bütçeye koymanızı öneririz. Bir yazılım bakım destek sözleşmesi genellikle dört işi kapsar:

• Hata düzeltme: kullanıcıların ya da izleme sisteminin bulduğu hataları öncelik sırasıyla kapatırız.
• Uyum güncellemeleri: dil, framework ve kütüphane sürümlerini güncel tutar, bağlı servislerin değişikliklerine uyum sağlarız.
• Güvenlik ve yedek: yamaları uygular, yedekleri ve geri yükleme adımını düzenli kontrol ederiz.
• İyileştirme: kullanım verisine göre küçük geliştirmeleri sürüm planına alırız.

SLA, yani hizmet seviyesi sözleşmesi, bu işi ölçülebilir hale getirir. İyi bir SLA; yanıt süresi ile çözüm hedefini ayırır, destek saatlerini, önem derecelerini ve kapsam dışı durumları yazılı tanımlar. Yanıt süresi, talebinize ilk dönüşün ne zaman geleceğini; çözüm hedefi ise sorunun ne zaman kapanacağını gösterir. Bu ikisini karıştıran bir sözleşme, kriz anında işe yaramaz. Böylece iki taraf da neyin acil olduğunu kriz anında değil, önceden konuşmuş olur. SLA seviyesini Kurumsal Yazılım Programı'nda sözleşmeyle birlikte belirleriz.

Canlı sistemi izlemek de bakımın parçasıdır. Sitenizin ayakta olup olmadığını site çöktü mü aracıyla anında kontrol edebilirsiniz. Yazılımınız e-posta gönderiyorsa alan adınızın SPF, DKIM ve DMARC kayıtlarını da düzenli denetlemenizi öneririz. Bakımı bizimle sürdürmek zorunda değilsiniz; devir gerekirse dokümantasyon ve erişim listesiyle yeni ekibe temiz bir teslim yaparız.

Özel yazılım geliştirme firması seçerken nelere bakmalısınız?

Teklifleri yalnız toplam bedelle karşılaştırmak yanıltıcıdır. Aynı rakam bir firmada keşif, test ve bakım dahil bir ürün, diğerinde yalnız ekran geliştirme anlamına gelebilir. Kurumsal yazılım firmaları arasında seçim yaparken şu soruları sormanızı öneririz:

• Kapsam: roller, iş kuralları ve kabul kriterleri yazılı mı?
• Sahiplik: kod deposu, bulut hesabı ve alan adı kimin adına?
• Haklar: sözleşme, devredilen mali hakları tek tek sayıyor mu?
• Güvenlik: hangi standarda göre test ediyorlar, hedef seviye ne?
• Değişiklik: yeni talepleri nasıl fiyatlıyor ve onayınıza sunuyorlar?
• Bakım: yayından sonra hata düzeltme ve güncelleme nasıl yürüyecek?
• Çıkış planı: başka bir ekibe geçmek isterseniz devir nasıl olacak?
• Muhatap: projeden kim sorumlu, ona nasıl ulaşacaksınız?

Ayrıca referans isteyin ve mümkünse benzer bir projenin canlı sistemini görün. Hatta küçük bir keşif işiyle başlamak, bir ekibin çalışma biçimini düşük riskle tanımanın en iyi yoludur.

Biz bu soruların cevabını sözleşmeye yazarız. İlk görüşmede ihtiyacınızı dinler, uygun yolu ve olası riskleri açıkça söyleriz; bir işin hazır ürünle daha iyi çözüleceğini düşünürsek bunu da söyleriz. Talha Aslan dijital pazarlama uzmanı, Google Partner ve Full Stack Developer olarak stratejiyi ve sonucun sorumluluğunu taşır. Ekibimiz SaaS platformları, CRM ve otomasyon sistemleri geliştirdi. Çalışmalarımızı referanslar sayfasında görebilir, projenizi konuşmak için bize yazabilirsiniz.