Özel Yazılım Fiyatları: Kapsam, Entegrasyon ve Bakım Maliyeti Nasıl Oluşur?

Özel yazılım fiyatları, kaç ekran istediğinizden çok üç şeye göre oluşur: kapsamın içindeki iş kurallarının sayısı, yazılımın konuşacağı dış sistemler ve canlıya çıktıktan sonra sistemi kimin, hangi güvenceyle ayakta tutacağı. Sektörde bu yüzden geçerli bir liste fiyatı yoktur; dışarıdan aynı görünen iki iş arasında ciddi fark çıkabilir. Bir yöneticinin yapabileceği en işe yarar şey ortalama rakam aramak değil, bu üç kalemi yazılı hâle getirip birkaç firmadan aynı brif üzerinden teklif istemektir.

Elinizde şu an muhtemelen ya bir fikir ya da birbirini tutmayan birkaç teklif var. Aşağıda bir teklifin içinde gerçekte neyin fiyatlandığını, en çok nerede yanlış hesap yapıldığını ve masaya birbiriyle kıyaslanabilir teklifler getirecek brifi nasıl hazırlayacağınızı anlatıyoruz. Kendi sürecinizi yazıya dökmeye başlamadan önce kavramlara göz atmak isterseniz özel yazılımın ne olduğunu ve ne zaman gerektiğini anlatan yazımızla başlayabilirsiniz.

Bir yazılım teklifinde aslında neye para ödersiniz?

Fabrikada üretilen bir üründe maliyetin önemli bir kısmı hammaddedir. Yazılımda hammadde yoktur, satılan şey neredeyse tamamen insan emeği ve o emeğin içerdiği karar sayısıdır. Teklifin arkasındaki hesap kabaca şudur: bir ekip bu işi kaç günde bitirir, o ekibin günü firmaya kaça mal olur, öngörülemeyen şeyler için ne kadar pay bırakılmalıdır.

Üçüncü kısım, yani risk payı, en az konuşulan ama teklifler arasındaki farkı en çok açan kısımdır. Firma işi ne kadar az anlamışsa, ya kendini korumak için payı yüksek tutar ya da işi almak için payı yok sayar. İlk durumda pahalı bir teklif görürsünüz. İkincisinde ucuz bir teklif görür, farkı projenin ortasında "bu kapsamda yoktu" cümlesiyle ödersiniz. Yani brifiniz ne kadar netse firmanın fiyatladığı risk o kadar azalır. Yazılım satın alırken bütçenizi en ucuza etkileyebileceğiniz yer burasıdır, çünkü bu iş sizin elinizde ve kod yazılmadan önce yapılır.

Ekibin yapısı da hesabı değiştirir. Tek geliştiriciyle çalışan bir serbest uzman ile tasarımcı, test uzmanı ve proje yöneticisi bulunan bir ekip aynı işi farklı maliyetle yapar; bu fark her zaman kâr marjı değildir. Test edilmemiş kod, belgelenmemiş mimari ve tek kişiye bağlı bilgi o an fiyatlanmaz ama ileride ödenir. Karar verirken "kaç kişi bu işe bakacak ve o kişi ayrılırsa ne olacak?" sorusu, fiyat kadar önemlidir.

Kapsamın gerçek ölçüsü ekran sayısı değil, iş kuralıdır

Yöneticiler kapsamı genellikle gördükleriyle anlatır: bir sipariş ekranı, bir rapor, bir yönetici paneli. Oysa geliştirme süresini ekranlar değil, ekranın arkasındaki kurallar belirler. Kurgusal bir örnekle gidelim: bir toptancı, saha satış ekibinin tabletten sipariş girmesini istiyor. "Tek form, müşteri seç, ürün seç, kaydet" olarak anlatılan bu iş, birkaç soruyla bambaşka bir şeye dönüşür.

• Her bayinin fiyat listesi ayrı mı? Listeler dönemsel olarak değişiyor mu?
• Satış temsilcisi kaça kadar iskonto verebilir, üstü kimin onayına gider, onay veren izindeyse ne olur?
• Stok yetmiyorsa sipariş reddedilir mi, kısmi sevk edilir mi, kalan kısım nereye yazılır?
• Cari hesap limiti aşılmış bayiden sipariş alınabilir mi?
• İnternet yokken girilen sipariş sonradan nasıl eşitlenir?
• Temsilci yalnızca kendi bölgesini mi görür, bölge müdürü neleri görür?

Bu soruların hiçbiri ekran sayısını artırmaz, ama her biri geliştirme, test ve hata olasılığı ekler. Aşağıdaki görselde aynı formun kurallar eklendikçe nasıl büyüdüğünü temsili değerlerle gösterdik.

Burada pratik bir ders var: kapsamı küçültmenin yolu özellik silmekten önce kural sadeleştirmektir. "Bayi başına ayrı fiyat listesi" yerine "üç fiyat grubu" demek, bazen koca bir modülden daha fazla emek kurtarır. Teklif görüşmesinde iyi bir yazılım firmasının size "bu kural gerçekten gerekli mi, kaç kez yaşanıyor?" diye sorması iyi işarettir; her şeye "yaparız" demek ise çoğu kez işin henüz anlaşılmadığını gösterir.

Sık yapılan bir hata, tüm istisnaları ilk sürüme yüklemektir. Yılda iki kez yaşanan bir iade senaryosu için haftalarca geliştirme yapmak yerine, ilk sürümde o senaryoyu elle çözmek çoğu işletme için daha akılcıdır. Sistem kullanılmaya başlayınca hangi istisnanın gerçekten sık yaşandığını zaten göreceksiniz.

Entegrasyon: teklifin en zor tahmin edilen satırı

İki firma aynı ekranlar için benzer süre verir, ama entegrasyon satırında birbirinden uzaklaşır. Nedeni basit: ekranları firma kendisi kontrol eder, entegrasyonda ise karşıdaki sistemin belgesine, test ortamına ve destek ekibine bağlıdır. "Muhasebe programımıza bağlansın" cümlesi, dış gözle tek satırlık bir istektir. İçinde ise hangi sürüm, hangi lisans, tek yönlü mü çift yönlü mü, hata olursa hangi tarafın verisi doğru sayılacak gibi kararlar saklıdır. API entegrasyonunun nasıl çalıştığını bilmek bu soruları sormanızı kolaylaştırır.

Türkiye'deki işletmelerde en sık karşılaşılan bağlantılar muhasebe veya ERP programları, e-Fatura ve e-Arşiv için özel entegratörler, sanal POS sağlayıcıları, pazaryerleri, kargo firmaları ve WhatsApp Business API'dir. Bunların yetenekleri kullanılan sürüme ve sözleşmeye göre değişebilir, bu yüzden "X programıyla entegre olur" cümlesini tek başına yeterli görmeyin. Sizin kullandığınız sürümün ve lisansın dış bağlantıya izin verip vermediğini teklif öncesinde kendi tedarikçinize sorun.

e-Fatura ve e-Arşiv konusunda ayrıca dikkat gerekir. Yazılımın belgeyi doğrudan kesmesi mi, entegratör paneline veri göndermesi mi isteniyor, iptal ve iade süreçleri nasıl işleyecek? Bu belgelerin kurallarını yazılım firması belirlemez; mevzuat zaman içinde değişebileceği için mali müşavirinizle birlikte netleştirmek en sağlıklısıdır. Bir firmanın bu konuda "biz hallederiz" demek yerine hangi belge türlerini kapsadığını yazılı belirtmesini isteyin.

Entegrasyonun maliyeti yalnızca ilk yapımda da bitmez. Karşıdaki servis sürümünü değiştirir, alan adını kaldırır, kotasını düşürür; sizin yazılımınız bir gün hiçbir değişiklik yapmadan çalışmayı bırakabilir. Bu yüzden her entegrasyon, bakım tarafında da küçük ama kalıcı bir yük demektir. Teklife bakarken "bağlantı koparsa bunu kim, ne kadar sürede fark eder?" diye sorun. Yanıt "kullanıcı arar, bakarız" ise izleme kurgulanmamıştır.

Eski verinizin durumu faturayı nasıl değiştirir

Veri taşıma, tekliflerde çoğu zaman bir satıra sığdırılır ya da hiç yer almaz. Oysa beş yıllık Excel dosyaları, aynı müşterinin üç farklı yazımı, boş bırakılmış vergi numaraları ve anlamı yalnızca eski çalışanın bildiği kodlar, yeni sisteme olduğu gibi aktarılamaz. Kirli veriyi temiz bir sisteme taşırsanız, ekip ilk haftada "bu sistem yanlış gösteriyor" der ve eski dosyasına geri döner.

Teklif istemeden önce kendi verinize bakın. Kaç kayıt var, hangi dosyalarda, ne kadar güncel? Müşteri, ürün ve bakiye kayıtlarını ayrı ayrı düşünün; geçmiş hareketlerin tamamı mı taşınacak, yoksa açılış bakiyeleriyle başlanıp eski kayıtlar arşivde mi kalacak? İkinci yol genellikle çok daha az emek ister ve birçok işletme için yeterlidir. Temizliği kim yapacak sorusunu da açık bırakmayın. Firma mı yapar, sizin ekibiniz mi, kim hangi kaydın doğru olduğuna karar verir? Teklifte bu yazmıyorsa varsayımı siz değil, firma yapmış demektir.

Canlıya çıktığı gün başlayan masraflar

Birçok yönetici özel yazılımı binaya benzetir: yapılır, biter, kullanılır. Daha doğru benzetme araç filosudur. Çalıştığı sürece yakıt ister, servis ister, yasal yükümlülüğü değişir. İlk teklifteki toplam bu yüzden gerçek bütçenizi göstermez. Üç yıllık bir bakış açısıyla şu kalemleri ayrı ayrı sorun:

• Barındırma ve altyapı: sunucu veya bulut, veritabanı, yedekleme, alan adı, e-posta ve SMS gönderim servisleri.
• Üçüncü taraf lisanslar: entegratör, harita, ödeme, WhatsApp mesaj ücretleri gibi kullanım başına ücretlenen servisler.
• Güvenlik ve sürüm bakımı: kullanılan kütüphanelerin güncellenmesi, güvenlik yamaları, tarayıcı ve işletim sistemi değişiklikleri.
• İzleme ve destek: kim, hangi saatlerde, ne kadar sürede yanıt verir?
• Küçük geliştirmeler: kullanım başladıktan sonra gelen istekler. Bir kısmı kaçınılmazdır, çünkü süreçler değişir.

Bu yüzden düşük bakım bedeli her zaman iyi haber sayılmaz. Bakımı eksik fiyatlanan bir sistemde güncellemeler ertelenir ve birikmiş iş, ileride tek seferde büyük bir faturaya dönüşür. Sözleşmede bakımın neyi kapsadığını, küçük geliştirmenin nerede bitip yeni projenin nerede başladığını yazılı görmek isteyin. Yedekleme ve veri güvenliği tarafında da kimin sorumlu olduğu açık olmalıdır: yedek alınıyor mu, geri dönüş daha önce denendi mi?

Kişisel veri işleyen bir sistemse KVKK da hesaba girer. Rol bazlı yetki, erişim kayıtları, veri saklama ve silme süreçleri ile sunucu konumu baştan konuşulmazsa sonradan eklemek pahalıya gelebilir. Bulut altyapısının yurt dışında olması ayrı bir değerlendirme gerektirebilir. Hukuki yorum yazılım firmasının işi değildir, ama sistemin bu ihtiyaçları karşılayacak şekilde tasarlanması onun işidir. Bu konuyu hukuk danışmanınızla netleştirip çıkan gereksinimleri brife yazın.

Son kalem sahipliktir. Kaynak kodu, veritabanı erişimi, sunucu hesapları ve dokümantasyon kimde olacak? Fiyatı düşük görünen bazı modeller yazılımı size kiralar; ayrılmak istediğinizde elinizde taşınabilir bir şey kalmayabilir. Bu her durumda kötü değildir, ama bilerek seçilmelidir. Bu nedenle özel yazılım fiyatları ve kapsamı konuştuğumuz görüşmelerde kodun ve dokümantasyonun size ait olduğunu baştan belirtiyoruz.

Kur, KDV ve teklifin geçerlilik süresi

Türkiye'de yazılım teklifi okurken gözden kaçan bir başlık da para birimidir. Geliştirme emeği TL ile fiyatlansa bile bulut altyapısı, üçüncü taraf API'ler ve bazı lisanslar çoğu zaman döviz bazlıdır. Teklifte şu dört sorunun yanıtını arayın: Bedel hangi para biriminde? KDV dahil mi hariç mi? Teklif kaç gün geçerli? Çok aylık bir projede kalan taksitler kur veya enflasyona göre güncellenir mi, güncellenirse hangi formülle?

İki teklifi yan yana koyduğunuzda biri KDV hariç döviz, diğeri KDV dahil TL olabilir. Bu kadar basit bir fark bile "ucuz teklif" algısını tersine çevirir. Bakım sözleşmesinde de yıllık artışın neye göre yapılacağı yazılı olmalıdır; aksi hâlde ikinci yılın bedelini ikinci yıl öğrenirsiniz. Devlet destekleri ve teşvikler için de benzer bir temkin gerekir: programlar dönemsel olarak değişir, uygunluğu başvuru öncesinde ilgili kurumdan ve mali müşavirinizden teyit edin, bütçenizi desteğe güvenerek kurmayın.

Sabit bedel mi, emek bazlı mı, fazlı mı?

Aynı işe verilen teklif, sözleşme modeline göre farklı görünür. Sabit bedelde risk firmadadır ve bu risk fiyata eklenir; değişiklik talepleri ek teklif demektir. Emek bazlı modelde esneklik yüksektir, ancak bütçe kontrolü büyük ölçüde sizin üzerinizdedir, haftalık takip yapacak birine ihtiyaç duyarsınız. Fazlı modelde ise önce küçük bir parça yapılır, sonraki parça öğrenilenlerle fiyatlanır.

Seçim için kaba bir ölçü: kapsamı bir sayfada, belirsizlik bırakmadan anlatabiliyorsanız sabit bedel makuldür. Anlatırken "duruma göre", "sonra bakarız" gibi cümleler sık geçiyorsa sabit bedel size güvenlik hissi verir ama ek taleplerle dolu bir sürece dönüşebilir. Büyük ve belirsiz işlerde en sağlıklı başlangıç çoğu kez ayrı fiyatlanan bir keşif aşamasıdır. Çıktısı veri modeli, ekran akışları ve kapsam belgesi olur; firma değişse bile bu belge sizde kalmalıdır. Sözleşmeye bunu yazdırın.

Ödeme planı da modelden bağımsız önemlidir. Bedelin büyük kısmının başta alınması, projede pazarlık gücünüzü azaltır. Ödemeleri takvime değil, kabul edilen teslimlere bağlamak daha sağlıklıdır. Kabul kriterini de tanımlayın: "çalışıyor" kimin için, hangi senaryoda, hangi veriyle?

Özel yazılım istemeniz gerekmeyebilecek durumlar

Fiyat sorusundan önce gelen soru budur. Bazı işletmeler özel yazılım için teklif toplarken aslında hazır bir ürünle ya da yalnızca bir entegrasyonla çözülebilecek bir sorunla uğraşıyordur. İhtiyacınız piyasadaki ürünlerin akışına büyük oranda benziyorsa, sıfırdan yazdırmak parasını çıkarmayabilir. Bu tercih için iş süreçleri otomasyonu rehberimizde daha küçük ölçekli yolları da anlatıyoruz.

Kendi tarafımızdan da açık konuşalım. Perakende veya depo tarafında stok ve satış takibi arıyorsanız Welda Stock, klinik ve hasta yönetimi arıyorsanız Welda CRM sıfırdan yazdırmaktan önce bakmaya değer; ikisini de kendimiz geliştirip canlıda işletiyoruz ve CRM'i 7 gün ücretsiz deneyebilirsiniz. Süreciniz bunlara ya da piyasadaki başka bir ürüne uyuyorsa, özel yazılım için bütçe ayırmak erken olabilir.

Özel yazılım şu durumlarda daha anlamlıdır: rekabet avantajınız bir iş kuralındaysa, kullanıcı sayısı arttıkça hazır ürün lisansları kalıcı bir yük olmaya başlıyorsa, birden çok sistem arasında elle veri taşıyan bir ekip varsa veya süreciniz yıllardır oturmuş ama hiçbir ürüne sığmıyorsa. Süreç henüz netleşmediyse ya da tek kişinin alışkanlığına dayanıyorsa, önce bir tabloyla veya hazır araçla birkaç ay denemek daha ucuza öğretir. Oturmamış bir süreci koda dökmek, kargaşayı kalıcı hâle getirmek demektir.

Karşılaştırılabilir teklif getiren brif nasıl yazılır?

Çoğu teklif kötü niyetle değil, eksik bilgiyle farklılaşır. Her firma boşlukları kendi varsayımıyla doldurur, sonra siz elma ile armudu kıyaslarsınız. İyi bir brif teknik belge olmak zorunda değildir; işi yapan kişinin ağzından, iş diliyle yazılmış birkaç sayfa çoğu firma için kısa ama kalabalık bir sunumdan daha değerlidir.

En çok atlanan bölüm "bugünkü maliyet"tir. Sorunu sayılarla anlatın: bu iş kimin kaç saatini alıyor, ayda kaç hata çıkıyor, o hataların sonucu ne? Bu rakamlar size özeldir ve yatırımın anlamlı olup olmadığını firmadan önce size gösterir. Örnek bir hesap: dört kişi günde birer saat aynı veriyi iki sisteme giriyorsa, bu ayda yaklaşık seksen saat eder. Bu saatin size maliyetini kendi rakamlarınızla hesaplayın, sonra teklifle karşılaştırın. Yazılım her sorunu ortadan kaldırmaz, ama bu hesap hangi bütçenin mantıklı olduğuna dair kaba bir tavan verir.

İkinci ipucu: iş akışlarını mutlu senaryoyla bırakmayın. "Sipariş girilir, onaylanır, sevk edilir" cümlesinden sonra mutlaka "ama" diye başlayan satırlar ekleyin. Ama stok yoksa, ama müşteri vazgeçerse, ama onaylayan yoksa. Bu satırları yazmak için masa başında değil, işi yapan kişinin yanında oturun; yöneticinin anlattığı süreç ile çalışanın uyguladığı süreç çoğu şirkette aynı değildir. İki anlatım arasındaki fark çoğu zaman fiyat farkının da kaynağıdır, çünkü firma brifte görmediği işi fiyatlayamaz.

Üçüncü ipucu: "olmazsa olmaz" ile "sonra olabilir" listesini ayırın. Firmalardan her iki liste için ayrı kırılım isteyin. Böylece bütçeniz sınırlıysa neyi erteleyebileceğinizi tahminle değil, görerek seçersiniz. Bütçe aralığınızı paylaşmak da düşündüğünüz kadar riskli değildir; firmanın size uygun bir kapsam önermesini sağlar. Paylaşmak istemiyorsanız en azından işin önceliğini ve hedef tarihini yazın.

Teklifler geldiğinde onları yan yana okumak

Teklifleri toplam rakama göre sıralamak en kolay ve en yanıltıcı yöntemdir. Bunun yerine bir tablo açın ve her teklif için aşağıdaki satırları doldurun. Boş kalan satır, en az rakamlı satırlar kadar bilgi verir.

Tablo dolduktan sonra firmalarla konuşurken şu soruları sorun: Bu işe kim bakacak, onlarla doğrudan görüşebilir miyiz? Daha önce benzer bir entegrasyon yaptınız mı, görebilir miyiz? İlk sürümü ne zaman elimizde görürüz? Bu projede sizi en çok ne endişelendiriyor? Sonuncusu özellikle değerlidir. Bir firmanın riskleri kendiliğinden sayabilmesi, işi düşündüğünü gösterir. "Hiçbir sorun görmüyoruz" yanıtı ise tek başına güven vermemelidir. Ayrıca çalışan bir uygulamayı gösterebilen firmayı, yalnızca sunum gösteren firmadan ayırın; mevcut referansı varsa kullanıcısıyla konuşmayı talep edin.

Bir de zaman maliyetini hesaba katın. Yazılım firması kod yazar, ama kuralları siz bilirsiniz. Projede sizin tarafınızdan haftada birkaç saat ayırabilecek, karar verme yetkisi olan bir kişi yoksa en iyi firma bile yavaşlar ve gecikme bir noktada faturaya yansır. Bu kişiyi teklif aşamasında belirleyin.

Welda'dan teklif almak nasıl işler

Özel yazılım tarafında web uygulamaları, iç araçlar, CRM kurulumları, WhatsApp Business API akışları, sistem ve API entegrasyonları ile panolar geliştiriyoruz. Sabit bir fiyat listemiz yok; önce süreçlerinizi ve darboğazlarınızı inceliyor, çözülecek problemi ve başarı ölçütünü netleştiriyoruz. Ardından veri modelini, entegrasyon noktalarını ve arayüz akışlarını kod yazılmadan onayınıza sunuyor, geliştirmeyi sürümler hâlinde teslim ediyoruz. Kaynak kodu, telif ve dokümantasyon size kalıyor; lansman sonrası izleme, güncelleme ve geliştirme için mutabık kalınan hizmet seviyelerinde bakım-destek sunuyoruz.

Her iş bize uygun olmayabilir. Odağımız web tabanlı uygulamalar ve entegrasyonlar; mağazalarda yayınlanacak yerel bir mobil uygulama sizin için şartsa veya sektörünüzde özel bir sertifikasyon gerekiyorsa bunu ilk görüşmede konuşalım, kapsamın bize uymadığını baştan söylemek ikimiz için de daha iyidir. Brifiniz hazırsa ya da yarım kaldıysa özel yazılım fiyatları için ücretsiz görüşme talep edebilirsiniz. Fiyat, kapsam netleştikçe bu görüşmede ve devamındaki teklifte netleşir.

Sık sorulan sorular

Özel yazılım fiyatları neden firmalar arasında bu kadar farklı?

Çünkü firmalar çoğu kez aynı şeyi fiyatlamıyor. Kapsam varsayımları, ekip yapısı, test ve dokümantasyon düzeyi ile risk payı farklıdır. Aynı brifi verip aynı kırılım tablosunu istediğinizde farkın gerçek nedeni görünür hâle gelir.

Bütçemi söylemeden teklif almalı mıyım?

Söylemek zorunda değilsiniz, ama yaklaşık bir aralık paylaşmak firmanın doğru kapsamı önermesine yardımcı olur. Paylaşmıyorsanız öncelikleri ve "olmazsa olmaz" listesini mutlaka yazın, teklifte iki liste için ayrı kırılım isteyin.

Bakım yaptırmazsam ne olur?

Yazılım bir süre çalışmaya devam eder, ama güvenlik yamaları, kütüphane güncellemeleri ve dış servislerdeki değişiklikler birikir. Sorun çıktığında müdahale daha büyük olur. Kendi ekibinizde bu işi üstlenecek biri yoksa bakımı bütçeye baştan ekleyin.

İlk sürümü küçük tutmak gerçekten ucuza gelir mi?

Genellikle evet, çünkü kullanılmayacak özelliklere emek harcamazsınız ve kararları gerçek kullanıma göre verirsiniz. Ancak veri modeli ve yetki yapısı gibi temel kararları büyümeyi düşünerek almak gerekir; aksi hâlde sonradan yeniden yazma maliyeti doğabilir.

Yazılım firmasını değiştirirsem kodum işe yarar mı?

Kaynak kodu, dokümantasyon ve hesap erişimleri sizdeyse başka bir ekip devralabilir; ama yine de kodu anlamak için bir inceleme süresi gerekir. Bu yüzden sahiplik kadar okunabilir dokümantasyonu da sözleşmeye yazın.

Welda ilk görüşmede fiyat söyler mi?

Kapsam konuşulmadan rakam vermek ikimizi de yanıltır. Ücretsiz görüşmede ihtiyacı, entegrasyonları ve bakım beklentisini netleştiriyor, sonrasında projeye özel kapsam ve teklif hazırlıyoruz. Bize get@welda.app adresinden de ulaşabilirsiniz.