Hazır yazılım mı özel yazılım mı sorusunun cevabı, ihtiyacınızın ne kadarını hazır ürünün gerçekten karşıladığına bağlıdır. İş süreçlerinizi önem derecesine göre puanladığınızda hazır ürün yüzde 80 ve üzerini karşılıyor, kritik bir eksik de kalmıyorsa satın alın. Oran yüzde 60 ile 80 arasındaysa ve eksikler birkaç noktada toplanıyorsa hazır bir çekirdek alıp yalnızca o noktaları yaptırın. Oran yüzde 60'ın altındaysa ve açık, sizi rakiplerinizden ayıran süreçte duruyorsa özel yazılım yaptırmak mantıklı hale gelir.
Bu eşikler bir araştırma sonucu değil, kararı somutlaştırmak için önerdiğimiz çalışma kuralıdır. Asıl değerli olan oranın kendisinden çok, onu hesaplarken yaptığınız iştir: hangi işin gerçekten size özgü olduğunu, hangisini yalnızca alışkanlıkla öyle yaptığınızı görürsünüz. Baştan söyleyelim, tarafsız değiliz. Welda hem hazır ürün işletiyor (Welda Stock, Welda CRM) hem de özel yazılım geliştiriyor. Bu yüzden aşağıdaki yöntemi, kimden teklif alırsanız alın işleyecek biçimde kurduk.
Karar yazılım için değil, süreç için verilir
Yöneticilerin çoğu bu soruyu tek bir karar gibi sorar: "Şirket olarak hazır mı kullanalım, kendimize mi yazdıralım?" Oysa aynı şirkette bordronun hazır pakette, müşteri kaydının bulut bir üründe, bayi fiyatlandırmasının ise size özel bir modülde çalışması son derece normaldir. Tek cevap aramak, ya hiçbir ayrıcalığı olmayan işler için sıfırdan kod yazdırmaya ya da sizi farklı kılan işi başkasının kalıbına sokmaya götürür.
O yüzden ilk ayrım teknik değil, stratejiktir. Süreçlerinizi iki kümeye ayırın. Birincisi herkesin aşağı yukarı aynı yaptığı işler: fatura kesmek, maaş hesaplamak, e-posta göndermek, gider girmek. Bu alanlarda farklı olmanın müşterinize faydası yoktur; muhasebecinizin alışık olduğu standart bir akış, yaratıcı bir akıştan daha iyidir. İkincisi müşterinin sizi seçme sebebi olan işler: on dakikada çıkardığınız karmaşık teklif, sektörde kimsenin vermediği teslim garantisi, bayilerinize özel kademeli iskonto mantığı. Yazılım yatırımı için en güçlü aday bu ikinci kümedir.
Şu basit testi yapın: Bir rakibiniz bu süreci yarın sizinle birebir aynı yapmaya başlasa işinize bir şey olur mu? Olmazsa o süreç rutindir ve satın almak neredeyse her zaman daha doğrudur. Olursa süreci koruyan yazılımı değerlendirmeye almaya değer. Bu testin bir tuzağı var: Pek çok ekip "bizim işimiz farklı" der, ama farklı olan iş değil, yıllar içinde biriken alışkanlıktır. Müşteriniz o farkı görmüyorsa ve bedelini ödemiyorsa, önce süreci değiştirmeyi düşünün. Yazılımı alışkanlığa uydurmak, en pahalı değişim direnci biçimidir.

Hazır yazılımın karşılama oranını iki haftada ölçün
Satıcının özellik listesi size oranı söylemez, çünkü liste "bu özellik var" der; "sizin işiniz bu özellikle yapılabiliyor" demez. Ölçüm için özel bir araca gerek yok, bir tablo yeter. Yöntem şöyle işler.
İşi dökün. İki hafta boyunca süreci yürüten kişilerden gerçekten ne yaptıklarını satır satır yazmalarını isteyin. "Sipariş yönetimi" diye bir satır işe yaramaz; "bayiden WhatsApp ile gelen siparişi girmek", "iskonto kademesini kontrol etmek", "eksik ürünü başka depodan istemek" işe yarar. Orta ölçekli bir süreçte genellikle 30 ila 60 satır çıkar. Yöneticiye değil, işi yapana yazdırın; yöneticiler sürecin olması gerekenini, çalışanlar olanını bilir.
Ağırlık verin. Her satıra 1, 2 veya 3 yazın. 3, aksarsa müşterinin veya paranın doğrudan etkilendiği iştir; 2, sık yapılan ve zaman alan iştir; 1, seyrek veya önemsiz iştir. Her satıra 3 yazma eğilimine karşı dürüst olun: satırların yaklaşık beşte birinden fazlası 3 çıkıyorsa muhtemelen abartıyorsunuz.
Demoda kendi verinizle puanlayın. Satırları adayın karşısında, kendi gerçek örneklerinizle deneyin ve şu tabloya göre puan verin.
| Durum | Puan | Nasıl anlaşılır |
|---|---|---|
| Kutudan çıktığı gibi çalışıyor | 1,0 | Demoda canlı gördünüz, ek işlem gerekmedi |
| Ayarla çalışıyor | 0,8 | Kod yazılmadan, ekranlardan tanımlandı |
| Entegrasyonla veya otomasyonla çalışıyor | 0,5 | Başka bir sisteme bağlamak gerekiyor |
| Elle çözümle yürüyor | 0,2 | Excel, kopyala-yapıştır, not alma gerekiyor |
| Yok | 0 | Yapılamıyor veya yalnızca "yol haritasında" |
Hesaplayın. Her satırın ağırlığını puanıyla çarpın, toplayın ve toplam ağırlığa bölün. Örnek olarak, hayali bir tesisat malzemesi toptancısını düşünelim: 30 çalışan, üç depo, 400'e yakın bayi. Sipariş ve stok tarafındaki bütün satırları puanladığında toplam ağırlık 120, kazanılan puan 85 çıkıyor. Yani hazır ürünün karşılama oranı yaklaşık yüzde 71.

Yüzde 71 tek başına size pek bir şey söylemez. Aynı puanları süreç alanlarına böldüğünüzde ise tablo değişir: müşteri kaydı, stok, sipariş girişi ve raporlama hazır üründe rahatça karşılanırken bayiye özel iskonto kuralları ile sevkiyat planlaması ciddi biçimde geride kalıyor. Bu dağılım, "özel yazılım yaptıralım" değil, "bu iki alanı çözelim" dedirtir. Ayrıntılı döküm olmadan bu ayrımı yapamazsınız.

Ortalamanın sakladığı iki şey: kırmızı çizgi ve görünmez elle çözüm
Oran yüksek çıksa bile iki durumu ayrıca kontrol etmeden karar vermeyin. Birincisi kırmızı çizgilerdir. Ağırlığı 3 olan bir satır sıfır puan aldıysa, ortalama yüzde 90 bile olsa o ürün sizin için eksiktir. Bir ilaç deposunda parti ve son kullanma takibi yoksa diğer her şeyin kusursuz çalışması durumu kurtarmaz. Satırları puanlamadan önce kırmızı çizgilerinizi yazıp imzalayın; aksi halde iyi bir demonun etkisiyle onları sessizce esnetirsiniz.
İkincisi elle çözümlerin maliyetidir. 0,2 puan verdiğiniz satırlar tabloda küçük görünür ama her gün birinin zamanını yer. Bunu para yerine saatle yazın, çünkü saat tartışma yaratmaz. Örnek: Üç satış temsilcisi her gün bayi iskontosunu ayrı bir Excel'den kontrol edip siparişe elle işliyor. Kişi başı günde 40 dakika ve ayda 22 iş günü varsayarsak bu, ayda 44 saat eder. Üstelik bu saate hatalı iskontonun geri dönüşü, temsilci izindeyken işin durması ve o Excel'i yalnızca bir kişinin anlaması dahil değildir.
Bu hesabı her elle çözüm için yapın ve toplamı yazın. Bazen sonuç sizi şaşırtır, ama her zaman yaptırma yönünde değil: Ayda iki saat alan bir kopyala-yapıştır için yazılım yaptırmak, açıkça bir israftır. Bazı açıkları kapatmamak en doğru karardır. Elle çözümü kalıcı olarak kabul ettiyseniz, sahibini ve yazılı talimatını belirleyip konuyu kapatın.
Çoğu işletmenin gerçek cevabı: hazır çekirdek, özel parça
Kararın iki seçenekli sorulması en büyük yanılgıdır. Yönetici için çoğu zaman en doğru yol üçüncüsüdür: işin büyük kısmını yürüten hazır bir ürün ve yalnızca açık kalan noktalara yapılan küçük geliştirmeler. Örnek toptancımız için bu, stok ve siparişi hazır bir üründe tutmak, bayi iskonto hesabını ise o ürüne API ile bağlanan küçük bir uygulamada çözmek anlamına gelebilir.
Bu yolun da kendi içinde dereceleri vardır. En hafifi otomasyon araçlarıdır: Make, Zapier veya n8n gibi araçlarla "yeni sipariş gelince şu tabloya yaz, şu kişiye bildir" türü akışları kod yazmadan ya da çok az kodla kurabilirsiniz. Bir üst seviye entegrasyondur: iki sistemin API üzerinden birbiriyle konuşması, veriyi elle taşımayı bitirir. Daha üstünde, hazır ürünün yanında çalışan küçük özel uygulamalar gelir: bayi portalı, teklif hesaplayıcı, saha ekibi için tek ekranlık araç gibi. Tekrarlayan işleri nereden yakalayacağınızı görmek için iş akışı otomasyonu örneklerine bakabilirsiniz.
Hibrit yolun çalışması tek bir şarta bağlıdır: hazır ürünün kapıları açık olmalı. Ürünün belgelenmiş bir API'si yoksa, API yalnızca üst pakette açılıyorsa veya veri yazmaya izin vermiyorsa, kurduğunuz yapı kırılgan kalır. Ayrıca satıcı API'yi değiştirdiğinde sizin parçanız etkilenir; bu da bakım bütçesine yazılması gereken bir kalemdir. Hibrit çözümü "ucuz özel yazılım" diye düşünmeyin; iki dünyanın kısıtlarını da taşır, karşılığında ikisinin en güçlü yanını verir.

Satıcıya ve yazılım ekibine sorulacak farklı sorular
Hazır ürün demosu ile yazılım firması görüşmesi aynı toplantı değildir; soruların da aynı olmaması gerekir. Hazır üründe aradığınız, ürünün sizin işinizle ne kadar örtüştüğü ve ileride elinizi kolunuzu bağlayıp bağlamayacağıdır. Bu görüşmede şunları sorun:
- En karmaşık üç gerçek senaryomuzu şimdi, kendi örnek verimizle gösterebilir misiniz?
- "Yol haritasında" dediğiniz özellik için yazılı tarih verebilir misiniz, gecikirse ne olur?
- Aboneliği bitirirsem bütün veriyi, hangi biçimde ve kaç günde alırım? Örnek bir dışa aktarım dosyası görebilir miyim?
- API belgeleriniz herkese açık mı, hangi pakette geçerli, kullanım limiti var mı?
- Son iki yılda fiyat modelinizde neyi değiştirdiniz? Kullanıcı, şube veya işlem artınca hangi kalem büyür?
Özel yazılım görüşmesinde ise aradığınız şey, ekibin belirsizliği nasıl yönettiğidir. Çünkü özel projede en büyük risk teknik değil, başta kimsenin bilmediği gereksinimlerdir. Şunları sorun:
- Kod yazmadan önce neyi teslim ediyorsunuz? Ekran akışlarını onaylamadan geliştirmeye geçiyor musunuz?
- Ne sıklıkla çalışan sürüm görürüz? Sürümü ne zaman kendi verimizle deneyebiliriz?
- Kapsam değişikliği nasıl fiyatlanır ve kim onaylar?
- Yarın sizinle çalışmayı bıraksak başka bir ekip kodu devralabilir mi? Dokümantasyon neyi kapsıyor?
- Canlıya çıktıktan sonra izlemeyi, güncellemeyi ve hataları kim üstleniyor; yanıt süreleri yazılı mı?
Bir ipucu: Bir yazılım firması, ihtiyacınızı dinlemeden "evet, yaparız" diyorsa dikkatli olun. İyi bir ekip size bazı parçaları yazdırmamanızı da söyler. Satıcı tarafında da aynısı geçerlidir: "Her şeyi yapıyoruz" diyen demo, puan tablonuzda karşılığını bulana kadar yalnızca bir iddiadır.
Kodun sahibi olmak ne demek, ne demek değil?
Özel yazılımın en cazip vaadi sahipliktir: kimse fiyatı artıramaz, ürünü kapatamaz, yol haritası sizindir. Bunların hepsi doğrudur, ama madalyonun öbür yüzünü de görmek gerekir. Sahip olmak, sorumlu olmak demektir. Hazır üründe bir güvenlik açığını, tarayıcı güncellemesinin bozduğu ekranı veya sunucu arızasını satıcı çözer. Özel yazılımda bu iş, sizin bakım sözleşmenizdeki bir kalemdir ya da hiç kimsenin işi değildir.
Özel yazılım ilk gün bitmez. İşletmeler genellikle canlıya çıkışı bitiş çizgisi sanır, oysa asıl dönem o gün başlar: kullanıcılar gerçek talepleri getirir, bağlı sistemler değişir, kütüphaneler güncellenir. Bütçenizi yalnızca geliştirme için ayırdıysanız, ikinci yılda yazılımınız yavaş yavaş eskimeye başlar. Yazılımın da bir işletme gideri olduğunu baştan kabul etmeyen firmalar için özel yazılım kısa sürede eski ve dokunulmaz bir sisteme dönüşür.
Bir de kişiye bağımlılık meselesi var. Kodu tek bir serbest geliştirici yazdıysa ve belgelemediyse, teoride sahibi siz olsanız da pratikte o kişiye bağlısınızdır. Kaynak kodunun size ait kod deposunda durması, teknik dokümantasyon teslimi ve başka bir geliştiricinin kurulumu tek başına yapabilmesi, sahipliğin gerçek ölçütleridir.
Hukuki taraf da atlanmamalıdır. Türkiye'de yazılım Fikir ve Sanat Eserleri Kanunu kapsamında korunur; mali hakların devri için yazılı sözleşme ve hakların ayrı ayrı gösterilmesi aranır. Yani "parasını ben ödedim, kod benim" varsayımı tek başına yeterli olmayabilir. Sözleşmedeki maddeyi mutlaka avukatınıza kontrol ettirin. Welda'nın özel yazılım hizmetinde kaynak kodu, telif ve dokümantasyon müşteriye aittir, ama bunu hangi firmayla çalışırsanız çalışın yazılı olarak görün.

Türkiye'de sıfırdan yazdırmamanız gereken işler
Bazı alanlarda karar, karşılama oranı hesaplanmadan bile bellidir. Kuralları devletin belirlediği ve sık değiştiği süreçlerde, küçük bir işletmenin kendi kodunu mevzuata yetiştirmesi akılcı değildir. Bu alanlarda farklı olmanın da müşteriniz için değeri yoktur.
e-Fatura, e-Arşiv ve e-Defter. Bu süreçler Gelir İdaresi Başkanlığı'nın teknik kurallarına tabidir ve bu kurallar güncellenir. Özel yazılımınızın fatura üretmesi gerekse bile bunu sıfırdan kurmak yerine yetkili bir özel entegratöre veya mali yazılıma bağlamak genellikle en sağlam yoldur. Yazdıracağınız şey "e-Fatura programı" değil, sisteminizle entegratör arasındaki bağlantıdır. İade, iptal ve düzeltme durumlarının da bu bağlantıda çalıştığını test edin. Hangi belge ve yükümlülüğün sizi kapsadığını mali müşavirinizle netleştirin.
Bordro ve SGK bildirimleri. Parametreleri sık değişen, hatası doğrudan çalışana ve kuruma yansıyan bir alandır. Muhasebe ofisinizin veya hazır bordro paketinin işidir.
Kişisel veriler ve KVKK. Burada iki yol da kendiliğinden güvenli değildir. Hazır üründe sağlayıcının veri işleyen olarak nasıl çalıştığına, sunucuların nerede olduğuna, yurt dışı aktarım olup olmadığına ve sözleşme hükümlerine bakmanız gerekir. Özel yazılımda ise erişim yetkileri, kayıt tutma, saklama ve silme kurallarını siz baştan tasarlatırsınız. Kim tutarsa tutsun veri sorumlusu olarak yükümlülükleriniz devam edebilir; uygulamayı hukuk danışmanınızla değerlendirin.
Bu işleri özel projenin dışında bırakmak bütçeyi de rahatlatır. Geliştirme kaynağınız, mevzuatı takip etmek yerine sizi gerçekten ayıran kısma gider. Kolayca düşülen bir hata da özel bir sipariş sistemi yaptırırken "madem başladık, muhasebeyi de içine alalım" denmesidir. Kapsam böyle şişer ve proje esas amacından uzaklaşır.
Teklifleri aynı dile çevirin: beş yıllık maliyet sayfası
Hazır ürünün aylık bedeli ile özel yazılımın proje bedelini yan yana koymak anlamsızdır; biri süreklidir, öteki başlangıçta toplanır. Doğru karşılaştırma, aynı beş yılı ve aynı kalemleri her seçenek için ayrı ayrı doldurmaktır. Pazar için tek bir fiyat aralığı vermek bu yüzden yanıltıcı olur: Sonucu kapsamınız, entegrasyon sayınız ve destek beklentiniz belirler. Tablonuza en az şu kalemleri yazın:
- Başlangıç: Kurulum, keşif ve analiz, tasarım, geliştirme, veri aktarımı, eğitim.
- Tekrar eden: Lisans veya abonelik (kullanıcı ve şube artışıyla birlikte), barındırma, bakım ve destek sözleşmesi, entegratör ve mesajlaşma gibi üçüncü taraf hizmetler.
- Değişim: Yıllık yeni özellik ihtiyacı, mevzuat veya bağlı sistem değişikliğine uyum, hazır üründe ücretli özelleştirme.
- İç zaman: Projeye ayırdığınız yönetici ve uzman saatleri, ilk ayların verim düşüşü, kalan elle çözümlerin saatleri.
- Çıkış: Beşinci yılda bu sistemi bırakmak isteseniz veriyi taşımanın ve ekibi yeniden eğitmenin bedeli.
İki tuzağa dikkat edin. Hazır üründe en çok atlanan kalem, kullanıcı başına fiyatın büyüme hızınızla birlikte artmasıdır. Özel yazılımda ise en çok atlanan kalem bakımdır; proje teklifinde görünmediği için yok sanılır. Teklif verenlerden bu sayfayı kendi rakamlarıyla doldurmalarını isteyin. Bir kalemi boş bırakan veya "duruma göre" diye geçen firmaya o kalemin neye göre değiştiğini sorun.

Yaptırmaya karar verdiyseniz en küçük sürümle başlayın
Özel yazılım projelerinin en bilinen hatası, bütün ihtiyaç listesini ilk sürüme sığdırmaya çalışmaktır. Puan tablonuz burada da işe yarar: İlk sürümün kapsamı, en düşük puanı alan ve ağırlığı 3 olan satırlardır. Geri kalan her şey sonraki sürüme kalabilir. Örnek toptancımızda ilk sürüm yalnızca bayi iskontosunu hesaplayıp siparişe yazan bir araç olabilir. Sevkiyat planlaması, o araç gerçek siparişlerde işlerini görmeye başladıktan sonra konuşulur.
Başarı ölçütünü de baştan yazın. "Süreç hızlansın" ölçüt değildir; "bayi iskontosu için ayda harcanan 44 saat 5 saatin altına insin" ölçüttür. Bu ölçütü projeye başlamadan bugünkü durumla birlikte kaydedin, yoksa altı ay sonra işe yarayıp yaramadığını kimse söyleyemez. Sürece bir de sahip atayın: Şirketinizde karar verebilen, haftada belirli bir zaman ayırabilen tek bir kişi. Bu kişi yoksa en iyi ekip bile sonunda yanlış şeyi kusursuz yapar.
Sık yapılan diğer hatalar şunlar: Yeni sistemi eski ekranların kopyası gibi istemek (eski kusurları da taşırsınız), veri aktarımını son haftaya bırakmak (eski verinin kalitesi genellikle sürpriz yapar), son kullanıcıyı canlıya çıkışa kadar görmemek ve eski sistemle yeni sistemi süresiz paralel yürütmek. Hazır ürüne geçişte de geçerli olan bir kural: Geçiş tarihinden sonra eski kayıt yolunu kapatın, çünkü iki sistem birlikte çalıştıkça ikisine de güven azalır. Kayıtlarınız Excel'deyse aktarımı erkenden deneyin; boş hücreler ve farklı yazılmış isimler en çok orada ortaya çıkar.

Welda bu kararın neresinde duruyor?
Karşılama oranınız hazır ürün lehine çıkıyorsa ve işiniz uyuyorsa elimizde iki ürün var. Welda Stock perakende için stok ve satış tarafını, Welda CRM klinik, salon ve stüdyolar için randevu ve müşteri takibini yönetir. Welda CRM'i 7 gün ücretsiz deneyip yukarıdaki puan tablosunu kendi verinizle doldurabilirsiniz. İşiniz bu kalıpların dışındaysa bunu size söyleriz; üretim planlama veya bordro gibi alanlar için hazır bir ürünümüz yok.
Hazır ürün yetmediğinde özel web uygulamaları, iç araçlar, süreç otomasyonu, WhatsApp Business API akışları, API entegrasyonları ve canlı panolar geliştiriyoruz. İş keşif ve gereksinimle başlar, ekran akışları kod yazılmadan onayınıza sunulur, geliştirme sürümler halinde ilerler, canlıya çıkıştan sonra da bakım ve destek sürer. Kendi ürünlerimizi canlıda işlettiğimiz için yazılımın günlük operasyon yükünü de biliyoruz; bu da "şunu yazdırmayın" diyebilmemizi kolaylaştırıyor.
Tablonuzu doldurduysanız, hazır yazılım mı özel yazılım mı kararını ücretsiz bir görüşmede birlikte gözden geçirebiliriz. Tablo henüz yoksa da en karmaşık üç senaryonuzu anlatmanız başlamak için yeterlidir. Fiyat, kapsam ve entegrasyon ihtiyacınıza göre belirlendiği için rakam da bu görüşmede netleşir. Kavramlara daha yakından bakmak isterseniz özel yazılımın ne olduğunu ve ne zaman gerektiğini anlatan yazımız iyi bir başlangıçtır.
Sık sorulan sorular
Hazır yazılım mı özel yazılım mı daha ucuz?
Başlangıçta genellikle hazır yazılım daha az para gerektirir, ama beş yılda sonuç kullanıcı sayınıza, entegrasyonlarınıza ve elle çözümlerinize göre değişir. Doğru cevabı genel bir kural değil, aynı kalemlerle doldurduğunuz beş yıllık maliyet sayfası verir. Hazır yazılım mı özel yazılım mı karşılaştırmasını kendi rakamlarınızla ücretsiz görüşmede yapabiliriz.
Küçük işletme özel yazılım yaptırmalı mı?
Çoğu küçük işletme için ilk adım hazır üründür. Ancak tek bir süreç işin kalbini oluşturuyor ve hazır ürünlerde karşılık bulmuyorsa, bütün şirketi değil yalnızca o süreci kapsayan küçük bir uygulama işletme ölçeğinden bağımsız olarak mantıklı olabilir.
Özelleştirilebilir hazır yazılım özel yazılımın yerini tutar mı?
Ayarlarla çözülen işlerde evet. Ancak satıcıya ücretli olarak özel kod yazdırdığınızda, her sürüm güncellemesinde o kodun çalışıp çalışmayacağını sormanız gerekir. Özelleştirme arttıkça hazır ürünün en büyük faydası olan sorunsuz güncellemeden uzaklaşırsınız.
Özel yazılım ne kadar sürede biter?
Süreyi kapsam ve entegrasyon sayısı belirler; bu yüzden tek bir süre söylemek doğru olmaz. Asıl sormanız gereken, ilk çalışan sürümü ne zaman görebileceğinizdir. Sürümler halinde ilerleyen bir projede en kritik parçayı erken deneyip gerisine o deneyime göre karar verebilirsiniz.
Hazır yazılımdan özel yazılıma sonradan geçilebilir mi?
Evet, üstelik bu çoğu zaman sağlıklı bir yoldur. Hazır ürünü kullandığınız dönem, ihtiyaçlarınızı gerçek kullanımla netleştirir. Geçişi kolaylaştırmak için en baştan verinizi tam ve düzenli dışa aktarabildiğinizi test edin; bulut ürünlerde bu ve benzeri konular için bulut yazılımın temel mantığına bakabilirsiniz.
Yapay zekâ özel yazılımı gereksiz hale getirir mi?
Yapay zekâ araçları bazı geliştirme işlerini hızlandırıyor, küçük iç araçlar yapmayı da kolaylaştırıyor. Ama kararın zor kısmı aynı kalıyor: doğru gereksinimi bulmak, veriyi güvende tutmak, sistemi yıllarca bakımlı tutmak. Kodun yazılması kolaylaştıkça önemli olan, kimin neyi neden yaptırdığı ve sonrasında kimin sorumlu olduğu olur.