Yazılım Yayına Alındıktan Sonra Hangi Masraflar Devam Eder? Görünmeyen Maliyetler Rehberi

Kısa cevap

Yazılımın geliştirme ücretini ödemek, yazılım maliyetinin bittiği anlamına gelmez. Canlı sistemlerde hosting/cloud, database, storage, data transfer, backup, monitoring, e-posta/SMS, üçüncü taraf API’ler, yapay zekâ kullanımı, domain, mobil mağaza üyelikleri, bakım, güvenlik güncellemeleri ve yeni geliştirmeler devam eden maliyet oluşturabilir. Bu maliyetlerin tamamı her projede bulunmaz. Bazıları aylık sabittir, bazıları kullanıcı veya işlem arttıkça yükselir, bazıları ise yalnızca bakım veya büyük güncellemeler sırasında oluşur. Bu nedenle özel yazılım yatırımını: Proje Bedeli olarak değil: İlk Geliştirme + Sistemi Çalıştırma + Sistemi Koruma + Sistemi Geliştirme = Toplam Sahip Olma Maliyeti olarak değerlendirmek daha doğrudur. AWS Well-Architected Framework de cloud maliyet optimizasyonunu tek seferlik bir çalışma değil, workload’un bütün yaşam döngüsü boyunca devam eden bir iyileştirme süreci olarak tanımlıyor. (AWS Dokümantasyonu) “Yazılımı yaptırdık. Bundan sonra neden ödeme yapıyoruz?” Çünkü yazılım: teslim edilen statik bir dosya değildir. Canlı uygulama sürekli olarak:

• kullanıcı isteklerini işler,
• veri saklar,
• dosya barındırır,
• e-posta gönderir,
• başka sistemlerle konuşur,
• yedek alır,
• log üretir,

güvenlik güncellemelerine ihtiyaç duyar. Yani geliştirme tamamlandığında: Development biterken: Operations başlar. Güncel GOV.UK Service Standard da canlı dijital hizmetlerin düzenli QA, monitoring, deployment ve problem müdahale planına ihtiyaç duyduğunu açıkça belirtiyor. (GOV.UK)

Yazılım maliyetlerini 4 gruba ayırmak daha doğru

En sık yapılan bütçe hatası yalnızca ilk satırı:

“Sunucu ne kadar?” diye düşünmektir. Gerçek toplam maliyet çok daha geniştir.

1. Hosting veya cloud maliyeti

En görünür devam eden maliyet budur. Uygulamanız:

• AWS,
• Azure,
• Google Cloud,
• Vercel,
• Render,

başka bir managed platform üzerinde çalışabilir. Maliyet modeli sağlayıcıya göre değişir. Ancak genel olarak aşağıdaki kaynaklar ücretlendirmeye etki edebilir: Compute + Requests + Execution + Database + Storage +

Network

Cloud faturası neden her ay aynı olmayabilir?

Çünkü birçok modern cloud hizmeti kullanım bazlı çalışır. Örneğin: 1.000 kullanıcı ile: 100.000 kullanıcı aynı:

• request,
• compute,
• database,

bandwidth tüketimini oluşturmaz. Vercel’in kendi usage rehberi de faturalandırılabilir kullanımın function invocations, data transfer, image transformations ve benzeri ürünler üzerinden proje bazında izlenebildiğini açıklıyor. (Vercel) Bu nedenle: “Hosting ayda X TL.” ifadesi yalnızca belirli bir kullanım seviyesi için geçerli olabilir.

Sabit sunucu mu, kullanım bazlı cloud mu?

Her ikisi de doğru olabilir. Sabit kaynak Örneğin: 4 CPU 8 GB RAM sunucu kiralanır. Maliyet daha öngörülebilir olabilir. Kullanım bazlı Tükettiğiniz kaynak ölçüsünde ödeme yapılır. Avantajı:

• düşük kullanımda daha ekonomik olabilmesi,

büyümenin daha kolay karşılanması. Dezavantajı:

• kötü tasarlanmış sistem,
• ani trafik,
• bot,

gereksiz compute faturayı yükseltebilir.

Cloud kullanmak otomatik olarak pahalı mı?

Hayır. Aynı şekilde: cloud her zaman ucuzdur da denemez. AWS maliyet optimizasyonunda kaynak seçimi, talep-kapasite dengesi, kullanım farkındalığı ve zaman içinde optimizasyonun birlikte ele alınmasını öneriyor. (AWS Dokümantasyonu)

Doğru soru:

Bu workload için hangi altyapı modeli en iyi fiyat/performans ve operasyon dengesini sağlıyor?

olmalıdır.

2. Database maliyeti

Çoğu iş uygulamasının merkezinde database bulunur. Örneğin: Users Customers Orders Operations Invoices Reports verileri database’de tutulabilir. Database maliyeti:

• kapasite,
• CPU,
• memory,
• storage,
• yüksek erişilebilirlik,
• read replica,

backup gibi ihtiyaçlara göre değişebilir.

Database büyüdükçe maliyet neden artar?

Sadece kayıt sayısından dolayı değil. Örneğin yüksek trafik: Daha fazla query ↓ Daha fazla compute gerektirebilir. Yüksek availability: Primary DB + Replica gerektirebilir. Uzun veri saklama: Storage ↑ Backup ↑ oluşturabilir. Bu nedenle database: “hosting ücretine dahil ufak detay” olarak görülmemelidir.

3. Dosya ve object storage

Sisteminizde:

• fotoğraf,
• PDF,
• teklif,
• fatura,
• video,
• sözleşme,

kullanıcı yüklemeleri bulunuyorsa bunlar da bir yerde saklanır. Örneğin: 10 GB dosya ile: 4 TB dosya aynı maliyeti oluşturmaz. Dosya sayısı kadar dosyanın nasıl kullanıldığı da önemli Maliyet yalnızca: depolanan GB olmayabilir. Ayrıca:

• okuma,
• yazma,
• request,

dosyayı kullanıcıya gönderme maliyetleri bulunabilir. Bu bizi sık gözden kaçan bir sonraki kaleme getiriyor.

4. Data transfer / bandwidth

Cloud’da en sık unutulan maliyetlerden biridir. Örneğin uygulamanız her kullanıcıya: 20 MB PDF gönderiyor. 100 kullanıcı: 2 GB veri transferi oluştururken kullanım büyüdüğünde miktar ciddi biçimde artabilir. AWS Well-Architected Framework, data transfer maliyetlerinin tasarım sırasında sık gözden kaçtığını ve transferin kaynak, hedef ve hacmine göre modellenmesi gerektiğini özellikle belirtiyor. (AWS Dokümantasyonu)

CDN neden yalnızca performans aracı değildir?

CDN ve caching:

• kullanıcıya daha hızlı içerik sunabilir,
• origin server yükünü azaltabilir,

bazı mimarilerde data-transfer maliyetinin optimize edilmesine yardımcı olabilir. AWS de data-transfer maliyetlerini azaltma yöntemleri arasında edge/CDN ve caching katmanlarını sayıyor. (AWS Dokümantasyonu)

5. Backup maliyeti

Backup:

“Database zaten cloud’da, sorun olmaz.” diye atlanmamalıdır. Canlı sistemlerde şunlar gerekebilir: Database Backup + File Backup + Retention + Restore Backup’ın kendisi de storage tüketir. AWS Backup örneğinde ücretlendirme; kullanılan hizmete göre storage, restore, data transfer ve bazı backup operasyonlarını içerebilir. (AWS Dokümantasyonu)

Backup miktarını ne belirler?

Örneğin: Daily backup × 30 gün ile: Daily backup × 7 yıl aynı değildir. Bu nedenle retention politikası belirlenmelidir. AWS Well-Architected da gereksiz veya orphaned verinin tutulmasının maliyet yarattığını ve lifecycle/retention politikalarıyla storage maliyetinin azaltılabileceğini belirtiyor. (AWS Dokümantasyonu)

“Backup alıyoruz” tek başına yeterli mi?

Hayır.

Asıl soru:

Geri yükleyebiliyor muyuz?

Backup stratejisinin:

• ne sıklıkta alındığı,
• ne kadar tutulduğu,
• nerede saklandığı,

restore prosedürü bilinmelidir.

6. Monitoring ve log maliyeti

Canlı uygulamanın ne yaptığını görebilmek için:

• application logs,
• error tracking,
• performance monitoring,
• uptime monitoring,

alerting kullanılabilir. GOV.UK da canlı dijital hizmetlerde monitoring’in kullanıcıyı etkileyen problemleri belirlemek, teknik sorunları erken görmek ve capacity planning yapmak için gerekli olduğunu belirtiyor. (GOV.UK) Monitoring’in kendisi de ücretli olabilir Örneğin çok fazla log: 1 milyon event ↓ 100 milyon event olduğunda:

• log ingestion,
• storage,
• retention,

query maliyeti büyüyebilir. Microsoft’un güncel Azure Monitor maliyet rehberi de log-data ingestion miktarının doğrudan izlenmesi ve maliyet optimizasyonunun bunun üzerinden yapılmasını açıklıyor. (Microsoft Learn)

En kötü çözüm logları tamamen kapatmak mı?

Çoğu production sistem için evet, risklidir. Çünkü sonra: “Müşteri ödeme yaptı ama neden işlem oluşmadı?” sorusunun cevabını bulamayabilirsiniz. Ama diğer uç: Her şeyi Sonsuza kadar Logla da maliyet ve gizlilik problemi yaratabilir. Daha sağlıklı yaklaşım: Doğru olayı, doğru detayda, doğru süre boyunca saklamak.

7. E-mail maliyeti

Uygulamanız:

• şifre sıfırlama,
• rezervasyon onayı,
• fatura,
• bildirim,

OTP e-postaları gönderiyorsa transactional e-mail servisi kullanılabilir. Kullanım genellikle: Gönderilen mail sayısı ile büyür. 10.000 işlem ile 5 milyon işlem aynı değildir. E-mail için yalnızca maliyet değil teslimat da önemli Kendi server’ınızdan e-mail göndermek teorik olarak mümkün olabilir. Ancak production sistemlerde:

• reputation,
• spam,
• bounce,

delivery tracking nedeniyle özel mail hizmetleri tercih edilebilir. Bu da devam eden servis kalemlerinden biridir.

8. SMS ve WhatsApp gibi iletişim servisleri

SMS, telefon doğrulama veya operasyon bildirimi kullanıyorsanız genellikle:

Mesaj sayısı × servis fiyatı maliyeti oluşur. Bu tür giderler kullanıcı sayısıyla doğrusal veya kullanım davranışına bağlı büyüyebilir. Örneğin: Her girişte SMS OTP ile: Yalnızca kritik işlemde SMS aynı maliyet yapısına sahip değildir.

9. Yapay zekâ API maliyeti

Uygulamanız:

• metin özeti,
• chatbot,
• belge analizi,
• görüntü analizi,
• konuşma,

AI agent kullanıyorsa yeni bir kullanım bazlı maliyet katmanı oluşabilir. AI maliyeti genellikle yalnızca: “AI özelliği var.” ile tahmin edilemez. Şunlara bağlı olabilir: İstek sayısı + Input miktarı + Output miktarı + Model + Araç kullanımı OpenAI API’nin güncel fiyatlandırması da model kullanımlarını büyük ölçüde token bazında; web search, file search, containers gibi bazı araçları ise ayrıca kullanım bazlı ücretlendiriyor. (OpenAI Platform) AI maliyetinin en sık yapılan hatası Şu hesap: “Bir istek çok ucuz, önemli değil.” olabilir. Ama: 0,01 birim maliyet × 10 milyon işlem artık önemsiz olmayabilir. Bu nedenle AI bulunan SaaS projelerinde: Cost per request Cost per user Cost per task ölçülmelidir. Model seçimi de business kararıdır Her işlem için en pahalı veya en güçlü modeli kullanmak gerekmeyebilir. Örneğin: Basit sınıflandırma ile: Karmaşık hukuki belge analizi aynı model seviyesini gerektirmeyebilir. AI ürününde maliyet optimizasyonu: yalnızca teknik değil, ürün tasarım kararıdır.

10. Harita, OCR, ödeme ve diğer API maliyetleri

Sisteminiz başka servislerden yararlanabilir:

• maps,
• OCR,
• e-signature,
• payment,
• address verification,
• finance API,
• shipping API,

weather/data API. Bunların her biri farklı fiyatlandırma kullanabilir: Request Transaction Document User Month gibi.

Bu nedenle teklif aşamasında sadece kullanılan servis adı değil:

Nasıl faturalandırılıyor?

sorusu da sorulmalıdır.

11. Ödeme sistemi komisyonları

E-ticaret veya SaaS satışı varsa ödeme sağlayıcısı:

işlem başına maliyet oluşturabilir. Mobil uygulamalarda dijital ürün satışı yapılması halinde mağaza kuralları ve service fee’ler de ayrıca devreye girebilir. Örneğin Google Play, Google Play billing veya ilgili alternatif billing modelleri üzerinden yapılan belirli ücretli uygulama, subscription ve in-app işlemlerinde hizmet ücretleri uygulandığını belgeliyor. (Google Destek) Bu oranlar ülke, program ve ticari modele göre değişebildiği için proje bütçesinde güncel koşullar ayrıca kontrol edilmelidir.

12. Apple Developer üyeliği

Mobil uygulamanız App Store’da dağıtılıyorsa Apple Developer Program üyeliği de devam eden maliyetlerden biridir. 23 Ağustos 2026 itibarıyla Apple Developer Program: 99 USD / üyelik yılı olarak listeleniyor; yerel para birimi ve bölgesel koşullar farklılaşabiliyor. (Apple Developer) Bu küçük bir kalem gibi görünse de: mobil uygulama mağazada olduğu sürece unutulmaması gereken yıllık operasyon gideridir.

Uygulama mağazada kaldıktan sonra teknik maliyet biter mi?

Hayır. Mobil uygulamalar ayrıca:

• yeni iOS/Android sürümleri,
• SDK değişiklikleri,
• store policy değişiklikleri,
• dependency update’leri,

cihaz uyumluluğu nedeniyle bakım isteyebilir. Dolayısıyla: App Store'a yükledik = Proje sonsuza kadar tamam değildir.

13. Domain yenileme

Domain genellikle yıllık yenilenir. Örneğin: company.com kullanıldığı sürece registrar’a bağlı yenileme maliyeti devam eder. Birden fazla: .com .com.tr marka domain’i kampanya domain’i tutuluyorsa bunlar da ayrı kalemler olabilir. Maliyet genelde altyapının yanında düşük kalır; fakat domain yenilenmesinin unutulmasının oluşturacağı operasyon riski maliyetinden çok daha büyüktür.

14. SSL sertifikası

Birçok modern platform ücretsiz veya managed TLS sertifikaları sağladığı için her projede ayrıca SSL ücreti oluşmaz. Ancak:

• belirli enterprise sertifika ihtiyaçları,
• özel PKI,

kurum içi sertifika yönetimi ayrı maliyet doğurabilir. Bu nedenle: “Her web sitesinin mutlaka yıllık ücretli SSL alması gerekir.” genellemesi doğru değildir.

15. Yazılım bakım maliyeti

En çok yanlış anlaşılan kalemlerden biridir. Bakım sadece: “Bug çıkarsa düzeltmek.” değildir. Aşağıdakileri içerebilir: Dependency Update Security Patch Runtime Update Framework Update API Compatibility Store Compatibility Bug Fix Performance Monitoring GOV.UK software dependency guidance da üçüncü taraf dependency’lerin sistemin güvenli ve çalışır durumda kalması için düzenli biçimde yönetilmesi ve güncellenmesi gerektiğini vurguluyor. (GOV.UK) “Çalışan sisteme neden güncelleme yapıyoruz?” Çünkü dış dünya değişir. Örneğin: Node sürümü Framework Browser iOS Android Third-party API Cloud service zamanla değişir. Sizin kodunuza hiç dokunulmasa bile bağımlı olduğunuz ortam değişmeye devam eder.

Güncellemezsek ne olur?

Hemen hiçbir şey olmayabilir. Asıl risk budur. Sistem: 1 yıl 2 yıl 3 yıl çalışabilir. Sonra bir gün:

• critical vulnerability,
• API kapanması,
• runtime support sonu,

mobile-store requirement nedeniyle büyük upgrade ihtiyacı oluşabilir. Düzenli küçük bakım yerine uzun süre ertelenmiş büyük migration daha pahalı hale gelebilir.

16. Güvenlik maliyeti

Güvenlik de tek seferlik bir proje değildir. İhtiyaca göre:

• vulnerability scanning,
• penetration testing,
• dependency monitoring,
• WAF,
• security logs,
• backup,

IAM review gibi çalışmalar gerekebilir. Canlı bir uygulamanın risk profili: launch günü donup kalmaz. Yeni açıklar ve saldırı yöntemleri ortaya çıkabilir. Bu nedenle güvenliğin geliştirme bütçesinden ayrı olarak operasyon bütçesinde de düşünülmesi gerekir.

17. Monitoring'e bakacak insan maliyeti

Monitoring aracına ödeme yapmak sistemin izlendiği anlamına gelmez. Örneğin alarm: Error rate: %35 dedi. Birinin:

• alarmı görmesi,
• analiz etmesi,

düzeltmesi gerekir. Bu yüzden software operations: Tool + Human Response kombinasyonudur. GOV.UK’un 2026 güncellenmiş reliable-service standardı da monitoring’in yanında tespit edilen problemlere müdahale için sürdürülebilir bir plan bulunmasını istiyor. (GOV.UK)

18. Teknik destek

Kullanıcılar bazen teknik destek gerektirir:

• hesabı açılmıyor,
• veri hatalı görünüyor,
• dosya yüklenmiyor,

işlem bulunamıyor. Bu destek:

• yazılım firması,
• iç IT ekibi,

customer success tarafından verilebilir. Her durumda insan zamanı maliyettir.

19. Yeni özellikler

Bakım ve yeni geliştirme birbirine karıştırılmamalıdır. Maintenance Mevcut fonksiyonun sağlıklı çalışmasını korumak. New Development Yeni business capability eklemek. Örneğin: Mevcut ödeme entegrasyonundaki bug → Maintenance Yeni banka entegrasyonu → New Development Bu ayrım teklif ve bakım sözleşmelerinde açık olmalıdır.

Yazılım canlıya çıktıktan sonra yeni özellik gerçekten gerekli mi?

Çoğu dijital ürün gelişmeye devam eder. Çünkü gerçek kullanıcı geldikten sonra:

• yeni ihtiyaçlar,
• kullanılmayan alanlar,
• UX sorunları,

yeni fırsatlar ortaya çıkar. GOV.UK Service Standard da dijital hizmetlerin hiçbir zaman gerçekten “bitmiş” olmadığını; kullanıcı, teknoloji ve ihtiyaç değiştikçe sürekli iyileştirme kapasitesinin korunmasını öneriyor. (GOV.UK)

20. Compliance ve hukuki maliyetler

Projenin türüne göre:

• KVKK/GDPR çalışmaları,
• sözleşmeler,
• lisans incelemeleri,
• security audit,
• sertifikasyon,

saklama politikaları gibi kalemler ortaya çıkabilir. Bunlar her projede bulunmaz. Ama:

• sağlık,
• finans,
• ödeme,
• kurumsal B2B,

hassas kişisel veri işleyen projelerde operasyon bütçesinin önemli parçası haline gelebilir.

21. Lisans maliyetleri

Sisteminizde ticari:

• UI library,
• charting,
• PDF engine,
• database,
• enterprise component,

security service kullanılmış olabilir. Bazı lisanslar: Tek seferlik bazıları: Yıllık bazıları: Kullanıcı başına olabilir. Bu yüzden proje tesliminde third-party license inventory bulunması değerlidir.

22. Development tool maliyetleri

Teknik ekip:

• Git hosting,
• CI/CD,
• error tracking,
• design tools,
• code security,

testing platformları kullanabilir. Bunlar her zaman müşteriye doğrudan fatura edilmeyebilir. Ancak dedicated team veya ürün ekibi bulunan şirketlerde gerçek yazılım operasyon maliyetinin parçasıdır.

23. Preview / staging ortamları

Production tek ortam değildir. Profesyonel projede: Development Staging Production bulunabilir. Staging de:

• compute,
• database,

storage tüketebilir. Bu nedenle: “Tek uygulamamız var.” olmasına rağmen üç ayrı teknik ortamınız olabilir.

Staging'i kapatmak maliyeti azaltır mı?

Evet. Ama her zaman mantıklı değildir. Staging: production’a çıkmadan önce sistemi doğrulama alanıdır. Canlı hizmetlerin production’a benzer ortamlarda test edilmesi güncel reliable-service rehberlerinde de öneriliyor. (GOV.UK) Maliyet azaltmak için kalite güvencesini tamamen kaldırmak yerine staging’in:

• düşük kapasitede,
• gerektiğinde çalışan,

daha küçük database olarak tasarlanması değerlendirilebilir.

24. Unutulmuş kaynaklar

Cloud faturalarında gerçek “görünmeyen maliyet” bazen aktif sistem değil:

Eski staging Unused database Old storage Old backups Abandoned project olabilir. AWS de yaşam döngüsü boyunca artık gerekmeyen resource ve workload’ların decommission edilmesini maliyet optimizasyonunun parçası olarak öneriyor. (AWS Dokümantasyonu) Vercel’in usage rehberi de terk edilmiş eski projelerin fark edilmeden kullanım üretmeye devam edebileceğine dikkat çekiyor. (Vercel)

25. Trafik artışının maliyeti

İyi haber:

Kullanıcı ↑ Kötü haber olmayabilir ama: Infrastructure Usage ↑ oluşturabilir. Özellikle SaaS’ta maliyet analizi bu yüzden: “Aylık cloud faturamız ne?” yerine: “Bir müşteriyi çalıştırmanın değişken maliyeti ne?” sorusuna dönmelidir. Unit Economics düşünün Örneğin: Cloud AI E-mail SMS Storage Payment toplam değişken maliyet: ayda 100.000 TL ve: 1.000 aktif müşteri varsa basitleştirilmiş olarak: 100 TL / aktif müşteri teknik operasyon maliyeti oluşur. Gerçek hesap daha detaylı olabilir. Ama bu yaklaşım pricing kararlarında çok değerlidir. AWS de workload maliyetlerinin usage ve business outcome metrikleriyle ilişkilendirilmesini cost-efficiency değerlendirmesinin parçası olarak öneriyor. (AWS Dokümantasyonu) Maliyetleri sabit ve değişken olarak ayırın Sabit / yarı sabit Örneğin:

• domain,
• bazı SaaS lisansları,
• minimum cloud planı,
• Apple Developer üyeliği,

aylık bakım anlaşması. Değişken

• AI token,
• SMS,
• e-mail,
• bandwidth,
• API request,
• storage,

payment commission. Bu ayrım büyüme planlamasını kolaylaştırır. Bir de periyodik maliyetler var Her ay çıkmaz. Örneğin: Major framework upgrade Penetration test Security audit App redesign Database migration 2–3 yılda bir ortaya çıkabilir. Bütçe modelinde bunları sıfır kabul etmek yerine: teknoloji yenileme rezervi gibi düşünmek mümkündür.

Örnek Aylık Yazılım Maliyet Tablosu

Bu tablo örnek modeldir; fiyat içermez. Maliyet

Tür

Kullanıma bağlı mı?

Application hosting

Aylık

✅ Database Aylık ✅ File storage Aylık ✅ Data transfer Aylık ✅ Backup Aylık ✅ Monitoring/logging Aylık ✅ E-mail Aylık ✅ SMS Aylık ✅ AI API Aylık ✅ Third-party API Aylık/Yıllık ✅ Domain Yıllık ❌ Apple Developer Yıllık ❌ Maintenance Aylık/Periyodik Değişir New development İhtiyaca göre ❌ Security audit Periyodik ❌ Küçük bir web sitesiyle SaaS platformunun devam eden maliyeti aynı değildir Kurumsal site Belki: Hosting Domain Bakım yeterlidir. SaaS Application compute Database Storage E-mail Monitoring Backup AI Support Security Development olabilir. Mobil SaaS Buna ek: App Store Play Console süreçleri Push Mobile maintenance eklenebilir. Bu nedenle: “Web sitesi aylık kaç TL’ye çalışır?” ile: “B2B SaaS aylık kaç TL’ye çalışır?” aynı soru değildir.

Yazılım maliyetinin en tehlikeli kısmı hangisi?

Çoğu zaman büyük olan değil:

ölçülmeyen maliyet. Örneğin: AI kullanımı %300 arttı ama kimse cost per task izlemiyor. Ya da: Storage her ay büyüyor ve eski dosyalar hiç silinmiyor. Ya da: Logs sonsuz tutuluyor. Bu yüzden cost monitoring production monitoring kadar önemlidir. AWS maliyet ve kullanım için budget, anomaly alert ve düzenli cost review süreçleri kurulmasını öneriyor. (AWS Dokümantasyonu) Microsoft Cost Management de budget, cost alert ve anomaly detection araçlarını aynı amaçla sunuyor. (Microsoft Learn)

Yazılım yayına çıkmadan önce mutlaka hazırlanması gereken maliyet tablosu

1. Hizmet

Ne kullanıyoruz?

2. Owner

Hesap kimin?

3. Fiyatlandırma modeli

Flat

Per user Per request Per GB Per token

Per transaction

4. Mevcut kullanım

Ne kadar tüketiyoruz?

5. Büyüme etkisi

Kullanıcı iki katına çıkarsa ne olur?

6. Limit

Hangi kullanımda plan değişiyor?

7. Alarm

Beklenmeyen maliyet artışında kim haberdar olacak?

Örnek

Servis Billing driver Owner Alarm Cloud Compute/request IT ✅ Database Compute/storage IT ✅ AI Token/tool call Product ✅ SMS Message Operations ✅ E-mail Message Marketing/IT ✅ Storage GB/request IT ✅ Bu model özellikle SaaS şirketlerinde maliyet sahipliğini görünür hale getirir.

Bütçe alarmı neden önemli?

Normal kullanım:

10.000 TL iken yanlış kod: sonsuz retry oluşturdu. Bir haftada kullanım: 50.000 TL seviyesine çıkabilir. Cost alert erken müdahale sağlar. AWS maliyet anomalilerinin ve usage threshold’larının izlenmesini resmi cost governance best practice’i olarak öneriyor. (AWS Dokümantasyonu)

Cloud faturası artınca hemen sunucuyu küçültmek doğru mu?

Her zaman değil. Önce cost driver bulunmalıdır. Örneğin sorun: Compute değil: Image transfer olabilir. Veya: Database değil: Log retention olabilir. Doğru sıralama: Measure ↓ Attribute ↓ Find Driver ↓ Optimize olmalıdır. Maliyet optimizasyonu performansı bozmak anlamına gelmemeli Örneğin: Backup kapat Monitoring kapat Staging kaldır ile fatura düşer. Ama risk yükselir. Cost optimization: en ucuz sistemi kurmak

• değil;

gereken business sonucu en verimli kaynak kullanımıyla üretmek olarak düşünülmelidir. AWS Well-Architected’ın cost optimization tanımı da business outcome ile maliyet arasında bu dengeyi kuruyor. (AWS Dokümantasyonu)

Teklifte “3 ay ücretsiz bakım” yazması ne anlama geliyor?

Mutlaka açıklanmalıdır. Örneğin: Dahil olabilir geliştirilen özellikte bug fix. Dahil olmayabilir

• yeni özellik,
• yeni API entegrasyonu,
• major framework migration,

üçüncü taraf servis ücretleri. Bu yüzden: “Bakım dahil.” tek başına yeterli açıklama değildir.

Bakım sözleşmesinde neler yazmalı?

Örneğin:

• hangi işler dahil,
• hangi işler hariç,
• response time,
• kritik hata tanımı,
• güncelleme kapsamı,
• monitoring,
• aylık geliştirme kapasitesi,

SLA varsa seviyesi. Bu ticari model firmadan firmaya değişir. “Bakım almazsak sistem çalışmaz mı?” Hayır. İyi yazılmış sistem bakım sözleşmesi bittiği anda kapanmamalıdır. Ancak bakım yapılmadıkça: Technical debt + Security debt + Compatibility debt zamanla birikebilir. Bu nedenle maintenance: “Sistemi açık tutma kirası”

• değil;

teknolojik eskimeyi ve operasyon riskini kontrollü yönetme çalışmasıdır.

TCO — Total Cost of Ownership nasıl hesaplanır?

Basit model:

TCO =

Initial Development + Infrastructure + Third-party Services + Operations + Maintenance + Security + Future Development + Migration / Upgrade Costs Örneğin 500.000 TL’ye geliştirilen bir sistem: “500.000 TL’lik yazılım” değildir. 3–5 yıllık kullanım dönemindeki bütün maliyetlerle değerlendirilmelidir.

3 yıllık bütçe neden tek yıllık bütçeden daha anlamlı?

Çünkü bazı maliyetler ilk yıl görünmez. Örneğin: Yıl 1 Development Launch Yıl 2 Scale More storage More API Yıl 3 Major upgrade Security work New integrations olabilir. Bu nedenle satın alma aşamasında yalnızca: ilk proje bedeli değil: 3 yıllık sahip olma maliyeti üzerinden teklif değerlendirmek daha sağlıklı olabilir.

Yazılım Yayına Çıkmadan Önce Finansal Kontrol Listesi

Altyapı

Hosting/cloud modeli belli. Database fiyatlandırması biliniyor. Storage maliyeti biliniyor. Data transfer modeli biliniyor. Backup retention belirli. Staging maliyeti hesaba katıldı. Servisler E-mail sağlayıcısı belli. SMS maliyeti biliniyor. AI maliyet modeli biliniyor. Third-party API’ler listelendi. Payment/service fee’leri biliniyor. Operasyon Monitoring var. Log retention belirli. Cost alerts tanımlı. Backup restore planı var. Security update sorumlusu belli. Ticari Domain renewals belli. Lisanslar listeli. Mobil mağaza maliyetleri belli. Bakım kapsamı belli. Yeni geliştirme fiyat modeli belli.

Aylık Cost Review Kontrol Listesi

Toplam cloud faturası

Geçen aya göre değişim

Compute Database Storage Data transfer Logs AI SMS/e-mail Kullanılmayan resource Unused staging/preview Cost anomaly Cost per customer Cost per transaction Bu incelemenin her şirkette aylık yapılması zorunlu değildir. Ancak hızlı büyüyen SaaS’ta aylık hatta daha sık cost monitoring değerli olabilir.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın yazılım yaşam döngüsü maliyet yaklaşımıdır. Bir yazılım teklifinde müşteriye sadece: “Proje bedeli 400.000 TL.” demek yeterli değildir. Şu tablo da görünür olmalıdır: İlk yatırım + Beklenen aylık altyapı + Kullanım bazlı servisler + Bakım modeli + Büyüme senaryosu Birinci prensip: İlk fiyat ile toplam maliyeti ayırın İki sistem: Sistem A Development: düşük Monthly operations: yüksek Sistem B Development: yüksek Monthly operations: düşük olabilir. Hangisinin ekonomik olduğu kullanım süresine göre değişebilir. İkinci prensip: Maliyetleri şirket hesabında görünür tutun Mümkün olduğunda: Cloud API Domain Store gibi hesapların şirket kontrolünde bulunması yalnızca sahiplik değil maliyet görünürlüğü de sağlar. Şirket: hangi servise ne ödediğini görebilmelidir. Üçüncü prensip: Kullanım bazlı özelliğin birim maliyetini bilin Özellikle:

• AI,
• SMS,
• storage,

transaction gibi servislerde. Örneğin: AI cost / generated report veya: Infrastructure cost / active company takip edilebilir. Bu SaaS pricing kararlarının gerçek veriye dayanmasını sağlar. Dördüncü prensip: Maliyeti azaltmak için güvenliği kesmeyin İlk optimizasyon: Backup kapat olmamalıdır. Önce: Unused resource Overprovisioning Bad query Uncached content Long retention Waste aranmalıdır. AWS maliyet optimizasyonu da talep-kapasite eşleşmesi, kullanılmayan kaynakların kaldırılması, data-retention politikaları ve düzenli workload incelemelerini öneriyor. (AWS Dokümantasyonu) Beşinci prensip: Maintenance bütçesini “olursa bakarız” olarak bırakmayın

Yazılımınız business-critical ise:

Kim güncelleyecek?

Kim alarmı görecek?

Kim security patch yapacak?

Kim API değişikliğini takip edecek?

launch öncesinde bilinmelidir. Çünkü production ownership belirsizse: sistem çalışıyor olabilir ama kimse gerçekten sistemden sorumlu değildir. Altıncı prensip: Cloud maliyetini business metriğine bağlayın Fatura: 30.000 TL tek başına yüksek veya düşük değildir. Eğer sistem: 10 şirket

• çalıştırıyorsa başka;

10.000 şirket çalıştırıyorsa başka değerlendirilir. Daha iyi metrik: Infrastructure Cost / Customer veya: Cost / Successful Transaction olabilir. Bu, teknoloji maliyetini business sonucu ile aynı tabloda görmenizi sağlar. Yedinci prensip: Yazılımın canlıya alınmasını yatırımın sonu değil ikinci fazı olarak görün Development: sistemi oluşturur. Operations: sistemin değer üretmeye devam etmesini sağlar. İyi bütçe bu iki dönemi baştan ayırır.

Sonuç

Yazılım yayına alındıktan sonra devam eden maliyet yalnızca:

hosting değildir. Gerçek denklem daha geniştir: Cloud + Database + Storage + Bandwidth + Backup + Monitoring + AI + E-mail / SMS + Third-party APIs + Mobile Store + Security + Maintenance + Future Development Bu kalemlerin bazıları aylık sabit, bazıları kullanım bazlı, bazıları ise periyodiktir. AWS ve Microsoft’un güncel cloud cost-management yaklaşımlarının ortak noktası da budur: maliyetin sürekli ölçülmesi, bütçelenmesi, kullanım kaynağına atanması ve zaman içinde optimize edilmesi gerekir. (AWS Dokümantasyonu) Bu nedenle özel yazılım yatırımı yaparken yalnızca: “Yazılımı yaptırmak kaç para?” diye sormayın. Şunları da sorun: “Bu sistemin aylık çalışma maliyeti ne?” “Kullanıcı sayımız 10 katına çıkarsa hangi maliyetler büyüyecek?” “Güvenlik ve bakım kimin sorumluluğunda?” “3 yıl boyunca toplam neye ödeme yapacağız?” Doğru planlanan bir yazılım projesinde bu giderler: görünmeyen maliyetler olmaktan çıkar. Başlangıçtan itibaren bilinen ve yönetilen ürün ekonomisinin bir parçası haline gelir.