Masaüstü Program Yaptırmak: 2026 Fiyatları ve Maliyet Kalemleri

Teklif görüşmelerinde en sık duyduğum cümle şu: “Basit bir program, birkaç ekran, ne tutar?” Dürüst cevap “o birkaç ekranın ne yaptığına bağlı” oluyor. Depoda barkod okutup etiket basan bir stok takip programı yaptırmak ile şubeler arası stok düşen bir kasa programı yaptırmak, ikisi de “birkaç ekran” diye anlatılır. Arada beş-altı kat bütçe farkı çıkabilir.

Yine de elinizde bir başlangıç noktası olsun diye masaüstü projeleri üç kademede düşünmek işe yarıyor. Tablodaki TL sütunu, adam-gün aralığını örnek bir gün ücretiyle (7.500 TL, KDV hariç) çarpıyor. Gün ücreti ekibin kıdemine, şehre ve şirketin maliyet yapısına göre geniş bir aralıkta değişir; planlayıcıda bu değeri kendiniz girebiliyorsunuz.

Adam-gün, bir kişinin bir iş gününde ürettiği emektir. 40 adam-gün, iki kişilik bir ekip için toplantı, kod inceleme ve müşteri onayı bekleme payıyla yaklaşık beş haftalık iş demek.

Örnek aralıklar; KDV hariç. Kapsam netleştikçe (prototip, ekran listesi, cihaz envanteri) aralık daralır.

Bu kademeleri pazarlık tablosu gibi değil, sağlık kontrolü gibi kullanın. Çok ekranlı bir iş uygulaması için gelen teklif ilk kademenin bile altındaysa iki ihtimal var: ya kapsamın bir kısmı teklifte yok ya da firma ilk sürümü zararına yapıp parayı bakımdan çıkarmayı planlıyor. Hangisi olduğunu birkaç soruyla anlarsınız; soruları 10. bölümde sıraladım.

Demo ekranlardan yapılır, müşteri de ekranları görür. Faturanın önemli bir kısmı ise su altında kalır: işletim sistemi testleri, cihaz testleri, kurulum paketi, imza, güncelleme kanalı. Web projesinde bunların çoğu sunucuda bir kez çözülür. Masaüstünde her kullanıcının bilgisayarı ayrı bir ortamdır; muhasebedeki Windows 11 dizüstü ile depodaki yedi yıllık kasa aynı programı farklı davranışlarla çalıştırır.

Aşağıdaki sekiz kalem planlayıcının da kullandığı kırılım. Her birinin yanına fiyatı yukarı iten tipik isteği ve bedeli makul tutan durumu yazdım. Bu soruları teklif toplamadan önce kendiniz cevaplarsanız, üç firmadan gelen üç rakam aynı işin fiyatı olur.

1. 1Ekran ve iş kuralı karmaşıklığıFiyatı yukarı iter“Fiyat müşteriye, miktara ve kampanyaya göre değişsin; onay gereksin.”Makul tutarListe, form, arama ve Excel'e aktarma ağırlıklı ekranlar.
2. 2Platform sayısıFiyatı yukarı iter“Windows'ta da Mac'te de çalışsın, Linux kiosklarımız da var.”Makul tutarTek işletim sistemi, şirketin kontrolündeki standart bilgisayarlar.
3. 3Donanım entegrasyonuFiyatı yukarı iter“Teraziden ağırlığı alsın, etiket yazıcıya ZPL göndersin, PLC'den sayaç okusun.”Makul tutarKlavye gibi davranan barkod okuyucu ve Windows sürücülü standart yazıcı.
4. 4İnternetsiz çalışma ve senkronFiyatı yukarı iter“İnternet gidince satış sürsün, iki şube aynı stoğu düşebilsin.”Makul tutarProgram her zaman yerel ağdaki sunucuya bağlı çalışıyor.
5. 5ERP ve muhasebe entegrasyonuFiyatı yukarı iter“Siparişi Logo'ya fatura olarak yazsın, cari bakiyeyi anlık göstersin.”Makul tutarGünde bir kez dosya ile aktarım ya da yalnız okuma.
6. 6Rol, yetki ve raporlamaFiyatı yukarı iter“Şube müdürü yalnız kendi şubesini görsün; 20 rapor PDF ve Excel olarak çıksın.”Makul tutarTek kullanıcı tipi, birkaç sabit liste raporu.
7. 7Lisanslama ve aktivasyonFiyatı yukarı iter“Programı satacağız; deneme süresi, cihaz bazlı lisans, çevrimdışı doğrulama.”Makul tutarProgram yalnız şirket içinde kullanılacak.
8. 8Paketleme, imza ve güncellemeFiyatı yukarı iter“300 kasaya sessiz güncelleme gitsin, hatalı sürüm geri alınabilsin.”Makul tutarBirkaç bilgisayar, BT ekibinin elle kurduğu MSI paketi.

Kapsamınızı aşağıdaki girdilerle tarif edin. Planlayıcı her kalemi adam-gün aralığına çevirir, proje yönetimi ve test payını ekler, kapsamın ne kadar net olduğuna göre üst sınıra belirsizlik payı koyar. Sağdaki panel ve sonuç kartı girdiler değiştikçe güncellenir.

Ekran sayısı, bütçe konuşmasının en kolay sayısıdır ve en yanıltıcı olanıdır. Bir “müşteri listesi” ekranı ile bir “sipariş girişi” ekranı aynı sayılır, ama ikincisinin arkasında stok kontrolü, fiyat listesi, iskonto sırası, kur çevrimi, kredi limiti ve belki bir onay adımı vardır. Benim tahmin tablolarımda ekranı üç tipe ayırıyorum: basit (liste, form, arama), orta (hesaplama ve doğrulama yapan), karmaşık (birden fazla tabloya yazan, kurala ve duruma bağlı akışı olan).

Planlayıcıda emeğin yaklaşık üçte ikisini ekranın görünmeyen kısmına, yani iş kurallarına ayırdım (örnek oran). Kuralları belirsiz bir ekranın bedeli iki kez ödenir: bir kez yazılırken, bir kez de canlıya çıktıktan sonra “aslında böyle olmayacaktı” denildiğinde. İş kuralı yoğunluğunun ekran sayısından ayrı bir girdi olmasının nedeni bu.

Aynı ekran, üç ayrı bedel: “Ürün kartı”

Örnek aralıklar; tasarım ve test emeği dahil, proje yönetimi hariç.

Ekran listesini çıkarmanın en ucuz yolu, programı kullanacak kişinin bugün ne yaptığını adım adım yazmaktır. “Sabah depoya geliyorum, gelen irsaliyeleri sisteme giriyorum” cümlesi, bir ekran listesinden daha fazla bilgi taşır. Bu cümlelerden tıklanabilir bir prototip çıkarmak (UI/UX tasarım çalışmasının işi tam olarak bu) çoğu projede tahmin aralığını yarıya indirir, çünkü belirsizlik payı küçülür.

Electron, Tauri ve Avalonia gibi çatılarla tek kod tabanından birden fazla işletim sistemine çıkılabiliyor; iş kurallarının büyük kısmı gerçekten bir kez yazılıyor. Ama her ek platform kendi paket biçimini, imza sürecini, test makinesini ve “bu neden yalnız Mac'te oluyor?” hatalarını da beraberinde getiriyor.

Pratikte ikinci platformun yükü koda değil, teste ve dağıtıma biner. Dosya yolları, yazıcı sürücüleri, ekran ölçekleme, klavye kısayolları ve izin pencereleri farklıdır. Seri port adları bile değişir: Windows'ta COM3, Linux'ta /dev/ttyUSB0, macOS'ta /dev/tty.usbserial-…. macOS'a ayrıca notarization adımı eklenir; her sürüm, kullanıcıya gitmeden önce zararlı yazılım taraması için Apple'ın sunucularına gönderilip onaylatılır.

Planlayıcı bu yüzden her ek işletim sistemi için arayüz, iş kuralı ve donanım emeğinin %15–25'i kadar test ve düzeltme payı ekliyor. Oran örnektir. Donanım ağırlıklı projeler üst sınıra, saf veri girişi yapan uygulamalar alt sınıra yakın çıkar.

Hangi teknolojiyle yazılacağı da bu çarpanı etkiler: yalnız Windows hedefleyen bir WPF uygulamasında macOS diye bir kalem hiç yoktur, ama yarın Mac gerekirse yeniden yazmak gerekir. Bu seçimi gerekçeleriyle Masaüstü program hangi dille yapılır? Electron, Tauri ve .NET yazısında sihirbazla anlattık; burada yalnız maliyete etkisini konuşuyorum.

Bütçe dar olduğunda önerim hep aynı: ilk sürümü kullanıcıların çoğunun olduğu tek platformda çıkarın, ama kodu çoklu platforma kapı kapatmayan bir çatıyla yazın. İkinci platformu ilk sürüm sahada iki-üç ay çalıştıktan sonra eklemek hem riski hem de tahmin hatasını küçültür. Bizim karşılaştığımız KOBİ projelerinde o tek platform çoğunlukla Windows oluyor; Mac genellikle yönetimde ya da tasarım ekibinde kalıyor.

Masaüstü programı web uygulamasından ayıran en somut şey, bilgisayara bağlı cihazlarla konuşması. Her cihaz modeli ayrı bir küçük projedir. Üreticinin protokol dokümanı bulunur, sürücü üzerinden mi yoksa doğrudan porta mı yazılacağına karar verilir, ğ, ş ve İ harflerinin fişte doğru çıkması sağlanır. Sonra asıl iş gelir: kablo çekildiğinde, kâğıt bittiğinde ya da terazi titrek değer gönderdiğinde programın ne yapacağı.

Bu emeğin önemli bir kısmı gerçek cihazın başında geçer. Simülatörle yazılmış bir terazi entegrasyonu, sahadaki terazi farklı bir baud hızıyla (seri portun saniyedeki veri hızı) ya da farklı bir veri çerçevesiyle gelince ilk gün takılır. Teklifte “test cihazını kim sağlıyor?” sorusunun cevabı yazılı olmalı. Biz ya cihazı ödünç alıyoruz ya da müşteriyle birlikte uzaktan bağlanıp deniyoruz; hangisi olursa olsun takvimde ayrı bir satırdır.

Örnek aralıklar, ilk model için adam-gün; aynı tipin ikinci modeli yaklaşık yarısı kadar sürer. Her model için ayrıca 1–1,5 gün gerçek cihaz testi eklenir.

ERP ve muhasebe entegrasyonu: yöntem bedeli belirler

ERP tarafında maliyeti belirleyen şey, verinin hangi yoldan ve hangi yönde akacağıdır. Masaüstü programın Logo veya Mikro'dan yalnız stok ve cari okuması ile oraya fatura ya da sipariş yazması arasında ciddi fark vardır. Yazma işi, ERP'nin kendi iş kurallarına (stok hareketi, cari hareket, KDV, muhasebe bağlantısı) uymak zorundadır ve bunun güvenli yolu ERP'nin resmî entegrasyon katmanlarıdır. Logo tarafında bu katmanları ve doğrudan SQL yazmanın neden sorun çıkardığını Logo ERP entegrasyonu rehberinde ayrıntılı anlattık.

• 8–15 adam-günResmî entegrasyon katmanıLogo Objects veya REST servisleri gibi ürünün kendi katmanı. ERP kurallarını korur, sürüm yükseltmelerinde daha az kırılır.
• 5–10 adam-günAra tablo veya salt okunur görünümMasaüstü program ERP veritabanındaki bir görünümden okur, kendi tablosuna yazar; aktarımı ERP tarafındaki bir iş yapar.
• 2–5 adam-günDosya ile aktarımGünlük Excel/XML dışa ve içe aktarma. Ucuzdur, ama anlık değildir ve hatalar ertesi gün fark edilir.
• ÖnermiyoruzDoğrudan veritabanına yazmaHızlı görünür; ERP'nin iş kurallarını atlar, bakiye ve stok tutarsızlığı aylar sonra ortaya çıkar.

Örnek aralıklar, tek yönlü bir veri tipi (ör. sipariş → fatura) için. Yabancı ajans rehberlerinde entegrasyon başına 40–120 saat gibi rakamlar dolaşıyor; bunlar dış kaynak tahminleridir ve Türkiye'deki ERP sürümlerine göre kalibre edilmemiştir. Logo tarafındaki lisans ve modül kararları için Logo ERP çözüm ortaklığı ekibimizle, özel bir servis katmanı gerekiyorsa API geliştirme tarafıyla birlikte çalışıyoruz.

“İnternet gidince de çalışsın” cümlesi bütçeyi en çok oynatan cümlelerden biri. Program her zaman yerel ağdaki bir sunucuya bağlıysa senkron (verilerin iki taraf arasında eşitlenmesi) diye bir dert yoktur. Kasa, saha tableti ya da uzak bir şube internetsiz çalışacaksa her işlem önce yerel bir veritabanına (genellikle SQLite) yazılır, bağlantı gelince merkeze gönderilir.

Asıl soru burada başlıyor: aynı kaydı iki yer birden değiştirdiyse hangisi geçerli?

Tek yönlü senkron görece basittir. Satışlar yerel kuyruğa yazılır, bağlantı gelince sırayla gönderilir, merkez yalnız kabul eder. Çift yönlüde ise fiyat değişikliği merkezden kasaya, satış kasadan merkeze akar ve stok iki tarafta birden düşer. Çakışma kuralı (son yazan mı kazanır, merkez mi, yoksa bir insan mı karar verir) her veri tipi için ayrı yazılır, ayrı test edilir. Planlayıcıda çift yönlü senkronun tek yönlüye göre iki-üç kat emek göstermesi bundan.

1. 1.Yokek emek yokProgram yerel ağdaki sunucuya bağlı çalışır; bağlantı koparsa kullanıcı uyarı görür ve bekler.
2. 2.Tek yönlü kuyruk6–10 adam-günİşlemler yerelde kuyruğa yazılır, sırayla gönderilir. Her işleme kasada bir kez üretilen benzersiz bir anahtar verilir; bağlantı yarıda kopup aynı satış yeniden gönderilse bile merkez onu ikinci kez işlemez.
3. 3.Çift yönlü, çakışma çözümlü15–28 adam-günVeri tipine göre çakışma kuralı, sürüm numarası, çakışma ekranı, kısmi senkron ve uzun süre bağlanmayan cihaz senaryosu.

Geliştirme teklifi tek seferlik bir rakamdır; program ise her yıl küçük ama kaçınılmaz giderler üretir. Bunların çoğu yazılım firmasının değil, programın sahibinin adına alınması gereken kalemlerdir. Tekliflerde ya hiç görünmezler ya da dipnotta kalırlar.

Kod imzalama sertifikası, kurulum dosyasının sizden geldiğini ve sonradan değiştirilmediğini kanıtlar. Haziran 2023'ten bu yana herkese açık güvenilir kod imzalama sertifikalarının özel anahtarı dışarı aktarılamıyor; sertifikalı bir USB token'da, HSM denen donanım güvenlik modülünde ya da sağlayıcının bulut imzalama hizmetinde durmak zorunda. Yani maliyetin iki parçası var: sertifikanın kendisi ve anahtarın saklandığı yer.

Somut rakam vermek gerekirse, SSL.com'un Ekim 2026 liste fiyatları (USD, vergiler hariç) şöyle: 1 yıllık OV sertifika 129, 1 yıllık EV sertifika 349, isteğe bağlı YubiKey donanım anahtarı 379. Çok yıllık alımda yıllık fiyat düşüyor; OV için 5 yıllık alımda yıllık bedel 100 USD'nin altına iniyor. Başka sağlayıcıların fiyatları farklı, kur da TL karşılığını her ay değiştiriyor.

OV ile EV arasındaki fark, sağlayıcının şirketinizi ne kadar derin doğruladığıdır. Eskiden EV sertifika SmartScreen (Windows'un indirilen dosyaları itibara göre denetleyen filtresi) uyarısını baştan kaldırırdı. Microsoft'un SmartScreen belgesi bunun artık geçerli olmadığını açıkça yazıyor: OV de EV de yeni bir dosyada, yeterli indirme geçmişi oluşana kadar uyarı alabilir. Bu yüzden çoğu iş uygulaması için OV yeterli. EV'yi yalnız bir ihale şartnamesi ya da kurumsal satın alma istiyorsa düşünün. Kurum doğrulamasının mantığını web tarafı için SSL sertifikası türleri yazısında anlattık.

Sık sorulan bir alternatif Microsoft'un Artifact Signing (eski adıyla Trusted Signing) hizmeti: aylık abonelikle çalışıyor, token gerektirmiyor. Ancak Ekim 2026 itibarıyla herkese açık güvenilir (Public Trust) sertifikalar yalnız ABD, Kanada, AB, Birleşik Krallık, Avustralya, Yeni Zelanda, Japonya, Güney Kore, Singapur, İsviçre, Norveç ve İsrail'deki kuruluşlara veriliyor; Türkiye listede yok. Türkiye'de kurulu bir şirket için bugünkü gerçekçi seçenek, ticari bir sağlayıcıdan token ya da bulut imzalama.

Güncelleme sunucusu için büyük bir altyapı gerekmiyor. Kurulum dosyalarını ve hangi sürümün güncel olduğunu söyleyen küçük bir manifest dosyasını tutan bir bulut sunucu çoğu proje için yeter. Sertifika sağlayıcısını teklif aşamasında birlikte seçiyoruz; şirketin diğer yazılım lisanslarına da toplu bakmak isterseniz lisans satış sayfası işinize yarar.

Yıllık Sabit Gider Takvimi

Programın yayına gireceği ayı ve seçimlerinizi girin; takvim ilk 12 ayın gider dağılımını, yenileme tarihlerini ve seçtiğiniz teknolojiye göre zorunlu bakım olaylarını gösterir. Geliştirme bedelini planlayıcıdan tek tıkla aktarabilirsiniz.

Yazılım bakım ücreti için piyasada en çok dolaşan rakam, geliştirme bedelinin yıllık %15–25'i. Bu aralık yabancı kaynaklardan gelen bir tahmin ve başlangıç için fena değil. Ama bakımın gerçek maliyeti iki şeye bağlı: programın kendisinin ne kadar değiştiği ve çevresindeki dünyanın ne kadar hızlı değiştiği. Masaüstünde ikincisi daha belirleyici, çünkü programınız siz hiçbir şeye dokunmasanız da eskir.

Somut örnek bu yazının yayın tarihine çok yakın: .NET 8 ve .NET 9'un desteği 10 Kasım 2026'da bitiyor. .NET 10, Kasım 2025'te uzun süreli destek (LTS) sürümü olarak yayımlandı ve 14 Kasım 2028'e kadar güvenlik güncellemesi alacak.

.NET 8 ile yazılmış bir WPF uygulaması bu tarihten sonra da açılır, çalışır; yalnız yeni güvenlik yaması almaz. Geçiş çoğu projede birkaç günlük iştir, bağımlı kütüphaneler eskiyse haftalara uzar. Bakım bütçesi ayrılmamışsa bu iş masanıza “yeni proje” olarak gelir.

Electron'da ritim daha hızlı: sekiz haftada bir yeni ana sürüm çıkıyor ve aynı anda yalnız son üç ana sürüm destekleniyor. Güvenlik desteğinde kalmak için kabaca altı ayda bir sürüm yükseltmesi demek bu. Tauri ve Rust tarafında zorunlu bir takvim yok, ama bu rahatlık yanıltmasın. Günlük işim Rust; Tauri projelerinde cargo audit taramasını her derlemede çalıştırmayı, Cargo.lock dosyasındaki bağımlılıkları güncellemeyi de ayda bir planlı iş olarak bakım havuzuna yazmayı öneriyorum. Bir yıl dokunulmamış bir Rust projesini tek seferde güncellemek, on iki küçük güncellemeden daha pahalıya gelir.

Masaüstünde zorunlu bakım kalemleri

• ↻Çatı ve çalışma zamanı yükseltmesi.NET LTS geçişi, Electron ana sürümü, Rust araç zinciri.
• ↻İşletim sistemi değişiklikleriYeni Windows ve macOS sürümlerinde izin, ölçekleme ve sürücü farkları; Windows 11'de Smart App Control açık makinelerde imzasız dosyanın hiç çalışmaması.
• ↻Sertifika ve hesap yenilemeleriKod imzalama, Apple üyeliği; süresi geçen sertifikayla yeni sürüm yayımlanamaz.
• ↻Mevzuat ve entegrasyon değişiklikleriERP sürüm yükseltmesi, e-Fatura/e-Arşiv entegrasyonunda format değişiklikleri.
• ↻Sahadan gelen hatalarİlk üç ay yoğun; kullanıcı programı gerçekten kullandıkça çıkar.

Biz bakımı yüzdeyle değil, aylık saat havuzu ile konuşmayı öneriyoruz. Örneğin ayda 8–16 saat; kullanılmayan saatlerin bir kısmı sonraki aya devreder, yeni özellikler ayrıca fiyatlanır. Böylece bakım ile geliştirme birbirine karışmaz ve “küçük bir şey ekleyelim” istekleri havuzu sessizce bitirmez.

Takvimdeki bakım yüzdesi girdisi yine de kaba bir bütçe görmek için orada. SLA (yazılı hizmet seviyesi taahhüdü), yanıt süresi ve destek sözleşmesinin genel maddeleri için yazılım firması seçerken nelere bakmalı yazısına bakabilirsiniz; burada yalnız masaüstüne özgü kalemleri sayıyorum.

Fiyatlandırma modeli, kaynak kod sahipliği, sözleşme maddeleri her yazılım projesinde konuşulur. Masaüstünde bunlara ek olarak, teklifte açıkça yazılmadığında sonradan tartışma çıkaran altı satır var. İki teklifi yan yana koyduğunuzda önce bu satırların ikisinde de olup olmadığına bakın. Olmayan satır ya sonradan ayrıca faturalanır ya da hiç yapılmaz.

1. 1Kod imzalama sertifikası kimin adına?Sertifika yazılım firmasının adına alınırsa, Windows'ta yayıncı olarak firma görünür ve ayrıldığınızda sertifika onda kalır.Teklifte örnek ifade“Sertifika müşterinin tüzel kişiliği adına alınır; doğrulama sürecini firma yürütür, bedeli müşteriye aittir.”
2. 2İmza anahtarı ve güncelleme sunucusu kimde?Güncelleme kanalının anahtarı kimdeyse programınıza kod gönderebilen odur.Teklifte örnek ifade“Güncelleme sunucusu müşterinin hesabında kurulur; erişim bilgileri ve token teslim tutanağıyla verilir.”
3. 3Hangi işletim sistemi sürümleri ve cihazlarla test edilecek?“Windows'ta çalışır” yeterli değil. Windows 10'un genel desteği bitti ama kasalarda ve üretim bilgisayarlarında hâlâ yaygın; sahadaki eski terminal test listesinde yoksa ilk gün testi siz yaparsınız.Teklifte örnek ifade“Windows 11 ve sahadaki Windows 10 22H2 terminallerde; ekteki 4 yazıcı ve 2 barkod okuyucu modeliyle gerçek cihaz testi yapılır.”
4. 4Eski sistemden veri göçü kapsamda mı?Göç çoğu zaman en az konuşulan ve en çok uzayan iştir.Teklifte örnek ifade“Mevcut Excel listeleri ve eski programın müşteri/stok tabloları bir kez aktarılır; aktarılamayan kayıtlar raporlanır.”
5. 5Kurulum ve sahada devreye alma dahil mi?20 şubeye kurulum, bir uzaktan bağlantı oturumu değildir.Teklifte örnek ifade“İlk 3 lokasyonda yerinde, diğerlerinde uzaktan kurulum; kurulum kılavuzu ve sessiz kurulum parametreleri teslim edilir.”
6. 6Build betikleri ve CI pipeline teslim ediliyor mu?Kaynak kod tek başına yetmez; imzalı paketi yeniden üretemiyorsanız başka bir firmaya geçemezsiniz.Teklifte örnek ifade“Kaynak kod, CI tanımları ve paketleme betikleri müşterinin deposuna teslim edilir; imzalı paket müşteri ortamında yeniden üretilerek kabul yapılır.”

Firmanın kendisini değerlendirme ölçütleri (referans, ekip, süreç, kırmızı bayraklar) için yazılım firması seçimi rehberine, proje yarıda kaldıysa ne yapılacağına proje kurtarma rehberine bakabilirsiniz.

Bütçe tutmuyorsa elinizde iki kol var: kapsamı küçültmek ya da kaliteden kısmak. İkincisi neredeyse her zaman daha pahalıya patlar, çünkü kestiğiniz şey birkaç ay sonra sahada hata olarak geri döner. Aşağıdakiler kapsamı küçültüp ürünü bozmayan yollar.

Daha temel bir soru da var: bu iş için gerçekten özel bir masaüstü program mı gerekiyor? Süreciniz standartsa piyasadaki hazır bir stok ya da ön muhasebe paketi, ya da tarayıcıdan çalışan bir uygulama daha ucuza gelebilir. Cihaz bağlantısı, internetsiz çalışma ya da kasadaki hız gibi masaüstüne özgü bir gerekçe yoksa önce bu seçenekleri eleyin.

Hazır mı özel mi kararını ve Excel'den çıkışı Excel yerine ne kullanılır yazısında, tarayıcıdan çalışan bir uygulamanın bütçesini web uygulaması maliyeti rehberinde ele aldık. Hâlâ kararsızsanız kod yazılmadan önce yapılan bir teknik danışmanlık görüşmesi, yanlış yola girmekten çok daha ucuzdur.

Program şirket içinde kullanılacaksa lisanslama diye bir kalem yoktur. Ama yazdırdığınız programı başkalarına satacaksanız, ürünün içine “kim, kaç cihazda, ne zamana kadar kullanabilir” sorusunu cevaplayan bir katman eklemeniz gerekir. Planlayıcıda bu katman 8–14 adam-gün olarak görünüyor (örnek); içinde şunlar var:

• ⚿İmzalı lisans anahtarıAnahtar sizin özel anahtarınızla imzalanır, program yalnız açık anahtarla doğrular; anahtar üretme algoritması program içinde durmaz.
• ⚿Cihaz bağlamaMakine parmak izi; donanım değişikliğinde kullanıcıyı kilitlemeyen bir tolerans kuralı.
• ⚿Çevrimdışı doğrulamaSahadaki bilgisayar internete çıkmasa da lisans kontrol edilebilmeli.
• ⚿Deneme süresi ve saat korumasıSistem saatini geri alarak süreyi uzatmayı engelleyen kontrol.
• ⚿Aktivasyon ve iptalİsteğe bağlı çevrimiçi aktivasyon sunucusu, cihaz taşıma ve lisans iptali ekranı.

Bu yapıyı kendi ürünümüzde de kullanıyoruz. Müşteri sunucusuna (on-prem) kurulan web tabanlı ürünümüz TYS'nin lisans katmanı şöyle tanımlı:

“Ed25519 imzalı lisans anahtarı çevrimdışı doğrulanır; makine parmak izi ve saat geri alma koruması vardır, çevrimiçi aktivasyon isteğe bağlıdır.”

TYS ürün sayfası · Güvenlik

TYS bir masaüstü programı değil; ama lisans doğrulamasının mantığı masaüstü ürünle birebir aynıdır. Fark, masaüstünde bu kontrolün her kullanıcının bilgisayarında çalışması ve bu yüzden tersine mühendisliğe karşı daha dikkatli tasarlanması gerektiğidir. Hiçbir istemci tarafı koruma kırılmaz değildir; amaç, dürüst müşterinin canını sıkmadan kopyalamayı zahmetli hâle getirmek.

Ürün şirketleri için lisans, güncelleme ve dağıtım altyapısını birlikte kurduğumuz yaklaşımı masaüstü ürün şirketleri sayfasında, daha küçük ölçekteki iç araçları ise KOBİ ofis araçları için masaüstü yazılım sayfasında anlattık.