Hazır altyapı ile projeye özel web yazılım arasında herkes için geçerli tek bir doğru yoktur. İhtiyaçlar standartsa, mevcut bir ürün doğal biçimde uyuyorsa ve gelecekte kapsamlı geliştirme beklenmiyorsa hazır altyapı daha doğru olabilir. Kuruma özgü iş akışları, ayrıntılı yetkiler, kapsamlı entegrasyonlar, özel veri yapıları veya büyüme gereksinimleri varsa projeye özel web yazılım daha güçlü bir adaydır. İki durumun arasında kalan projelerde ise hazır servislerle özel geliştirmenin birlikte kullanıldığı hibrit yaklaşım düşünülebilir.
Kararı yalnızca ilk fiyat veya özellik listesiyle vermeyin. Yazılımın iş akışınıza ne kadar uyduğunu; veri ve hesap sahipliğini; entegrasyon, güvenlik, performans ve ölçek gereksinimlerini; lisansları; bakım sorumluluğunu ve ileride sistemden çıkış imkânını birlikte değerlendirin.
Bu rehberdeki karar matrisi, hangi seçeneğin daha çok araştırılması gerektiğini gösterir. Otomatik teklif, kesin maliyet hesabı veya güvenlik garantisi değildir.
Hazır Altyapı ile Projeye Özel Web Yazılım Arasındaki Fark Nedir?
Hazır altyapı, birden fazla işletmenin ortak ihtiyaçlarını karşılamak üzere önceden geliştirilmiş bir ürün veya platformdur. Temel sayfalar, içerik yönetimi, formlar, üyelik, satış ya da benzeri işlevler ürünün mevcut özellikleri, temaları, eklentileri ve yapılandırma seçenekleriyle kurulabilir.
Projeye özel web yazılım ise işletmenin onaylanmış gereksinimlerine göre tasarlanan iş akışları, veri modeli, kullanıcı rolleri, entegrasyonlar ve yönetim araçlarından oluşur. Bu ifade her satır kodun sıfırdan yazıldığı anlamına gelmez. Projeye özel bir sistem de güvenilir açık kaynak kütüphanelerden, framework’lerden ve üçüncü taraf servislerden yararlanabilir. Özgün olan; bu bileşenlerin kurumun gerçek sürecine göre nasıl yapılandırıldığı, geliştirildiği ve bir araya getirildiğidir.
Hibrit yaklaşımda ise standart bir ihtiyacı olgun bir hazır servis karşılar; kuruma fark yaratan iş akışı veya yönetim katmanı özel geliştirilir. Örneğin e-posta gönderimi ya da ödeme gibi standart bir servis dışarıdan alınırken, departmanlara özgü onay süreci ve raporlama paneli projeye özel olabilir.
Bu nedenle soru yalnızca “hazır mı, özel mi?” değildir. Daha kullanışlı soru şudur: Hangi ihtiyaç standart kalmalı, hangi ihtiyaç yapılandırılmalı ve hangi ihtiyaç gerçekten özel geliştirme gerektiriyor?
Karar Vermeden Önce Dört Ayrımı Netleştirin
1. Özellik var mı, iş akışına gerçekten uyuyor mu?
Bir hazır üründe ihtiyaç duyduğunuz özelliğin bulunması tek başına yeterli değildir. Özelliğin kullanıcılarınızın gerçek sürecine, yetki yapısına ve veri akışına nasıl uyduğunu inceleyin. Ekibiniz sürekli dışarıda tablo tutuyor, aynı veriyi birden çok kez giriyor veya ürünü kullanabilmek için kendi sürecini bozuyorsa görünürdeki özellik uyumu yapısal bir boşluğu saklıyor olabilir.
2. İlk fiyat mı, yaşam döngüsü maliyeti mi?
Başlangıç bedeline ek olarak lisans ve kullanıcı ücretleri, temalar, eklentiler, entegrasyonlar, veri taşıma, bakım, güncelleme, destek ve ilerideki geliştirmeler değerlendirilmelidir. Projeye özel geliştirmede ise keşif, tasarım, yazılım, test, dokümantasyon ve bakım sorumluluğu görünür olmalıdır.
Bu kalemleri kendi rakamlarınızla üç yıllık tabloda karşılaştırmak için web sitesinin toplam maliyeti rehberini kullanabilirsiniz. Hazır altyapının da özel yazılımın da her koşulda daha ucuz olduğu varsayılmamalıdır.
3. Kontrol sahibi olmakla sorumluluk almak aynı şey mi?
Kaynak kod, veri ve altyapı üzerinde daha fazla kontrol; güncelleme, güvenlik, izleme, yedekleme ve teknik yetkinlik sorumluluğunu da beraberinde getirir. Hazır bir üründe bu sorumlulukların bir kısmı sağlayıcı tarafından yürütülebilir. Özel yazılımda ise hangi tarafın hangi işi üstleneceği sözleşme ve bakım planında açık olmalıdır.
4. Bugünkü ihtiyaç ile büyüme planı aynı mı?
Bugün beş sayfa ve bir iletişim formuyla çalışan proje, ileride çoklu dil, bayi ağı, kullanıcı hesabı, başvuru süreci veya ERP entegrasyonu gerektirebilir. Her olası ihtiyacı ilk günden geliştirmek doğru değildir; fakat yakın büyüme planını yok saymak da erken altyapı değişikliğine yol açabilir. Kararınızı doğrulanmış yol haritası üzerinden verin.
İhtiyaçlar henüz yazılı değilse önce web sitesi ihtiyaç dokümanı hazırlama rehberindeki kapsam sorularını cevaplayın.
10 Kriterlik Hazır Altyapı ve Özel Yazılım Karar Matrisi
Aşağıdaki matris bir Kumsal Ajans editoryal karar aracıdır. Her satırda projenize en yakın durumu 0, 1 veya 2 olarak puanlayın:
- 0: İhtiyaç standart ve olgun bir hazır ürün tarafından doğal biçimde karşılanıyor.
- 1: Yapılandırma, sınırlı entegrasyon veya kısa teknik doğrulama gerekiyor.
- 2: Kuruma özgü gereksinim yapısal; hazır çözüm önemli bir boşluk bırakıyor.
| Karar kriteri | 0 — Hazır çözüme yakın | 1 — İnceleme / hibrit alanı | 2 — Özel geliştirmeye yakın |
|---|---|---|---|
| İş akışı | Standart sayfa, form veya satış akışı | Birkaç özel adım veya onay | Kuruma özgü, çok aşamalı süreç |
| Entegrasyon | Hazır bağlantı yeterli | API ile sınırlı uyarlama | Birden çok sistem arasında özel veri akışı |
| Kullanıcı rolleri | Standart yönetici/editör/üye rolleri | Bazı ek yetki kuralları | Departman, kayıt veya işlem bazlı ayrıntılı yetki |
| Veri yapısı | Ürünün standart alanları yeterli | Ek alan ve sınırlı ilişki | Özel veri modeli, kurallar ve raporlama |
| Performans ve ölçek | Öngörülebilir, standart kullanım | Yoğun dönemler veya büyüme belirsiz | Kritik hız, işlem hacmi ya da ölçek hedefi |
| Güvenlik ve risk | Standart risk profili ve yeterli sağlayıcı kontrolleri | Ek yapılandırma ve denetim | Kuruma özgü tehdit, erişim veya süreklilik gereksinimi |
| İçerik ve çoklu dil | Bağımsız, standart içerik girişi | Özel alan veya onay ihtiyacı | Bağlı çeviriler, çok ekipli onay ve özel yayın akışı |
| Sahiplik ve taşınabilirlik | Sağlayıcının dışa aktarımı yeterli | Bazı veri veya hesap bağımlılıkları | Kod, veri, hesap ve geçiş üzerinde yüksek kontrol ihtiyacı |
| Süre ve başlangıç bütçesi | Hızlı yayın ve sınırlı bütçe öncelikli | Aşamalı geliştirme mümkün | Keşif, geliştirme ve test için kaynak ayrılmış |
| Bakım kapasitesi | Sağlayıcı modeli kabul edilebilir | Sorumluluklar paylaşılacak | Özel yol haritası ve teknik bakım ekibi gerekli |
Toplam puanı şu şekilde okuyabilirsiniz:
- 0-6: Hazır altyapı güçlü adaydır. Yine de lisans, veri dışa aktarımı, güvenlik ve bakım koşullarını doğrulayın.
- 7-13: Hibrit çözüm veya kısa bir teknik keşif gerekir. En yüksek puanlı satırlar için prototip ya da entegrasyon testi yapın.
- 14-20: Projeye özel web yazılım güçlü adaydır. Kapsam, teslim ölçütleri ve bakım sorumluluğu yazılı hâle getirilmelidir.
Bu aralıklar bilimsel bir ölçek değildir ve tek başına satın alma kararı vermez. Güvenlik, kritik entegrasyon, veri taşınabilirliği veya mevzuat gibi yüksek etkili tek bir gereksinim, toplam puandan bağımsız olarak ayrıca incelenmelidir.
Hazır Altyapı Hangi Durumlarda Yeterli Olabilir?
Kumsal Ajans olarak projeleri öncelikle özel yazılım perspektifiyle değerlendiriyoruz. Buna rağmen aşağıdaki koşullar bir aradaysa hazır altyapı makul bir seçim olabilir:
- Kurumsal tanıtım, standart içerik, blog, iletişim veya temel satış gibi yaygın ihtiyaçlar bulunuyorsa
- Ürünün mevcut işlevleri ihtiyacın büyük bölümünü iş akışını bozmadan karşılıyorsa
- Ayrıntılı rol, özel veri modeli ve kapsamlı entegrasyon gerekmiyorsa
- Kısa sürede yayına çıkmak ve başlangıç bütçesini sınırlı tutmak öncelikliyse
- Yakın yol haritasında kapsamlı geliştirme öngörülmüyorsa
- Sağlayıcının güncelleme, destek, veri dışa aktarma ve lisans koşulları kabul edilebiliyorsa
Hazır ürün seçerken yalnızca demo ekranına bakmayın. Gerçek içerik, rol ve veri örneklerinizle küçük bir deneme yapın. API sınırlarını, eklenti ve tema bağımlılıklarını, lisans yenilemelerini, yedekleme yöntemini ve sistemden ayrılmak istediğinizde veriyi hangi formatta alabileceğinizi yazılı olarak doğrulayın.
Hazır olmak, güvensiz veya kalitesiz olmak demek değildir. İyi yönetilen ve gereksinime uyan olgun bir ürün, standart bir süreç için gereksiz özel geliştirmeden daha sürdürülebilir olabilir. Sorun, ürünün doğal sınırlarıyla kurumun ihtiyaçları arasındaki fark büyüdüğünde başlar.
Projeye Özel Web Yazılım Hangi Durumlarda Gerekçelidir?
Aşağıdaki ihtiyaçlar hazır ürünün birkaç ayarıyla değil, sistemin temel çalışma biçimiyle ilgiliyse özel geliştirme değerlendirilmelidir:
- Kuruma özgü başvuru, onay, hesaplama, sipariş veya operasyon süreçleri
- CRM, ERP, ödeme, bayi, rezervasyon, üyelik veya başka servislerle özel entegrasyon
- Departman, kullanıcı, kayıt veya işlem düzeyinde ayrıntılı rol ve yetkiler
- Birbiriyle ilişkili özel veri yapıları, raporlar ve otomasyon kuralları
- Bağlı çoklu dil içerikleri ve ekipler arası yayın/onay süreci
- Hazır yapının doğrulanmış performans veya ölçek sınırlarını aşan gereksinimler
- Kod, veri, hesap, dokümantasyon ve taşınabilirlik üzerinde daha fazla kontrol
- Birkaç yıl içinde değişmesi beklenen ve kurum için stratejik olan bir iş akışı
Özel yazılım, tüm isteklerin ilk günden yapılması anlamına gelmemelidir. Önce iş açısından en kritik akış belirlenebilir; diğer modüller ölçülebilir kabul ölçütleri ve aşamalı yol haritasıyla geliştirilebilir. Bu yaklaşım, belirsizliği “her şeyi özel yapalım” kararıyla saklamak yerine görünür kılar.
Projeye özel sistem de otomatik olarak hızlı, güvenli veya ölçeklenebilir değildir. Bu sonuçlar; doğru keşif, mimari, kod inceleme, test, izleme, güncelleme ve bakım uygulamalarıyla sağlanır.
Hibrit Yaklaşım Ne Zaman Daha Doğrudur?
Bazı projelerde standart işlevleri tekrar geliştirmek yerine güvenilir hazır servisler kullanmak, kuruma özgü katmanı ise özel geliştirmek daha dengeli olabilir. Örneğin:
- Ödeme altyapısı hazır bir sağlayıcıdan alınır, sipariş ve onay akışı özel geliştirilir.
- E-posta gönderimi harici bir servisle yapılır, bildirim kuralları yönetim panelinde kuruma göre çalışır.
- Standart kimlik doğrulama servisi kullanılır, uygulamadaki rol ve veri erişim kuralları özel yazılır.
- İçerik yönetimi projeye göre yapılandırılır, harita veya depolama gibi hizmetler uzman sağlayıcılara bırakılır.
Hibrit modelde asıl soru bağlantının kurulup kurulamayacağı değildir. API sınırları, hata durumları, veri sahipliği, servis kesintisi, fiyat değişikliği ve sağlayıcıdan çıkış planı da incelenmelidir.
Güvenlik ve Sürdürülebilirlik Seçenekten Çok Süreçle İlgilidir
“Hazır sistem güvensizdir” veya “özel yazılım güvenlidir” biçimindeki iki cümle de eksiktir. Her iki yaklaşım; güncel olmayan bileşenler, yanlış yapılandırma, zayıf erişim kontrolleri veya yetersiz bakım nedeniyle risk oluşturabilir.
OWASP’ın güncel olmayan bileşenler rehberi, kullanılan istemci ve sunucu bileşenlerinin ve bunların bağımlılıklarının sürümlerinin bilinmesini, düzenli izlenmesini ve yükseltme uyumluluğunun test edilmesini önerir. Bu sorumluluk hazır üründe sağlayıcı ile müşteri arasında, özel yazılımda ise geliştirici, müşteri ve altyapı ekibi arasında açıkça paylaşılmalıdır.
NIST Güvenli Yazılım Geliştirme Çerçevesi, güvenli geliştirme uygulamalarının kurumun iş gereksinimleri, risk toleransı ve kaynaklarıyla uyumlu biçimde önceliklendirilmesini; maliyet, uygulanabilirlik ve uygunluğun da dikkate alınmasını söyler. Dolayısıyla marka adından veya “özel” etiketinden önce şu kanıtları isteyin:
- Bileşen ve bağımlılık envanteri
- Güncelleme ve güvenlik düzeltmesi süreci
- Yedekleme ve geri dönüş testi
- Rol ve erişim kontrolü
- Test, kayıt ve hata izleme yaklaşımı
- Olay ve hizmet kesintisi sorumlulukları
- Bakım sona erdiğinde uygulanacak devir planı
Kod, Veri ve Hesap Sahipliğini Sözleşmede Yazın
Kumsal Ajans projelerinde, sözleşmedeki ödeme ve teslim koşulları tamamlandıktan sonra proje için özel geliştirilen kaynak kodlar müşteriye devredilir. Proje kapsamında üretilen içerikler, müşteri ve kullanıcı kayıtları ile operasyonel veriler müşterinin mülkiyetindedir.
Alan adı, hosting, sunucu, e-posta ve üçüncü taraf servis hesaplarının mümkün olduğunca doğrudan müşteri adına oluşturulmasını tercih ediyoruz. Teknik yönetimin Kumsal Ajans tarafından yürütüldüğü durumda yetkilendirmeler alınır; proje tesliminde veya hizmet ilişkisinin sona ermesinde erişimler müşteriye devredilir.
Proje kapsamına göre devir listesinde kaynak kod deposu ve güncel sürüm, veritabanı ve gerekli yedekler, sunucu ve yönetim paneli erişimleri, alan adı ve servis hesapları, kurulum bilgileri ile varsa API ve entegrasyon dokümantasyonu bulunabilir. Teslim edilecek öğeler teklif ve sözleşmede tek tek yazılmalıdır.
Burada özel geliştirilen kod ile üçüncü taraf bileşenleri ayırmak gerekir. Open Source Initiative’ın lisans açıklamaları, açık kaynak kullanımının lisans koşullarına bağlı olduğunu ve copyleft dâhil farklı lisansların farklı yükümlülükler taşıyabildiğini gösterir. Açık kaynak kütüphanelerin, lisanslı bileşenlerin veya üçüncü taraf servislerin mülkiyeti projeyle birlikte otomatik olarak devredilmez; müşteriye ilgili lisans kapsamında kullanım hakkı sağlanır. Bu bölüm hukuki görüş yerine geçmez; proje için kullanılan lisanslar gerektiğinde uzman tarafından ayrıca değerlendirilmelidir.
Altı Aylık Ücretsiz Teknik Destek Neyi Kapsar?
Aksi teklif veya sözleşmede belirtilmedikçe Kumsal Ajans, projeye özel web yazılımlarında canlıya geçiş ya da nihai teslim tarihinden itibaren altı ay ücretsiz teknik destek sunar. Bu dönem garanti niteliğindeki hata giderme sürecidir.
Ücretsiz dönem şunları kapsar:
- Teslim edilen kapsam içindeki yazılım hatalarının giderilmesi
- Mevcut işlevlerin onaylanan biçimde çalışmasının sağlanması
- Proje kaynaklı teknik sorunların incelenmesi
Yeni özellik, modül veya entegrasyon; kapsam genişletme; tasarım ve kullanıcı deneyimi revizyonu; yoğun içerik/veri girişi; üçüncü taraf servis değişiklikleri; başka ekiplerin müdahalesinden doğan çalışmalar; alan adı, sunucu ve lisans ücretleri bu kapsama girmez. Düzenli bakım, güvenlik güncellemeleri, performans takibi ve operasyonel izleme için ayrıca aylık bakım ve destek modeli oluşturulur.
Bu sınırların teklif, kabul ölçütleri ve destek başlangıç tarihiyle birlikte yazılması, hata giderme ile yeni geliştirme arasındaki anlaşmazlığı azaltır.
Anonimleştirilmiş Gerçek Proje Örneği
Aşağıdaki örnek gerçek bir projeden anonimleştirilmiştir. Müşteri adı, sektör, tarih, kullanıcı sayısı ve entegrasyon ayrıntıları kimliğin ortaya çıkmaması için paylaşılmamaktadır. Ölçülmemiş bir performans, maliyet veya zaman kazanımı iddia edilmemektedir.
Farklı departmanları ve kullanıcı rolleri bulunan bir kurum, mevcut hazır altyapısında performans, yetkilendirme ve entegrasyon sorunları yaşıyordu. Yeni talepler eklentilerle karşılanmaya çalışıldıkça sistem karmaşık ve yönetilmesi zor hâle gelmişti.
Kumsal Ajans önce kurumun iş süreçlerini ve mevcut verisini analiz etti. Ardından markaya özel bir yönetim paneli ve modüler web yazılım altyapısı geliştirildi. Veriler kontrollü biçimde yeni sisteme aktarıldı; kullanıcı rolleri, iş akışları ve üçüncü taraf servis bağlantıları kurumun gereksinimlerine göre yeniden yapılandırıldı.
Bu örnekte özel geliştirme kararının nedeni yalnızca “daha özgün görünmek” değildi. Hazır yapıyla gerçek operasyon arasındaki boşluk; yetki, veri ve entegrasyon katmanlarında yapısal hâle gelmişti. Karar matrisinde bu satırların ayrı ayrı yüksek puan alması, özel yazılım için gerekçe oluşturuyordu.
Kararı Teklife Dönüştürmeden Önce Sorulacak Sorular
- Hangi gereksinimler standart, hangileri kuruma özgü?
- Hazır üründe bu gereksinimler doğal özelliklerle mi, geçici çözümlerle mi karşılanıyor?
- API, kullanıcı, depolama, trafik, rol ve veri dışa aktarma sınırları neler?
- Üç yıllık lisans, entegrasyon, bakım ve geliştirme bütçesi nasıl karşılaştırılıyor?
- Kaynak kod, veri, alan adı, sunucu ve servis hesapları kimin kontrolünde olacak?
- Kullanılan açık kaynak ve lisanslı bileşenlerin koşulları neler?
- Güncelleme, güvenlik, yedekleme, izleme ve olay müdahalesinden kim sorumlu?
- Kabul testi hangi senaryolar ve ölçütlerle yapılacak?
- Altı aylık hata giderme ile bakım ve yeni geliştirme nasıl ayrılacak?
- Sağlayıcı veya ekip değiştiğinde kod, veri, dokümantasyon ve erişimler nasıl devredilecek?
Altyapı yaklaşımı netleştikten sonra farklı teklifleri aynı kapsam ve kanıt düzeyinde değerlendirmek için 12 kriterlik teklif karşılaştırma puan kartından yararlanabilirsiniz.
Sonuç: Ürünü Değil, Uyum ve Sorumluluk Modelini Seçin
Hazır altyapı; standart ihtiyacı doğal biçimde karşılıyor, hızlı yayın önceliğine uyuyor ve kabul edilebilir bir lisans, veri ve bakım modeli sunuyorsa doğru seçim olabilir. Projeye özel web yazılım; kuruma özgü iş akışı, veri, rol, entegrasyon veya kontrol ihtiyacı yapısal hâle geldiğinde gerekçelidir. Hibrit yaklaşım ise standart servisleri yeniden üretmeden özgün operasyon katmanını geliştirmeyi sağlar.
Karar matrisini doldurun, en yüksek puanlı gereksinimleri gerçek veriyle test edin ve sahiplik ile bakım sorumluluklarını sözleşmeye yazın. Hiçbir yaklaşımı yalnızca “ucuz”, “hızlı”, “güvenli” veya “ölçeklenebilir” etiketiyle seçmeyin.
Projenizin hazır, hibrit veya projeye özel bir yapıya ihtiyaç duyup duymadığını birlikte değerlendirmek için Kumsal Ajans web yazılım hizmetini inceleyebilirsiniz.
Sık Sorulan Sorular
Hazır altyapı her zaman daha mı ucuzdur?
Hayır. Hazır altyapı daha düşük başlangıç bedeli ve daha kısa kurulum süresi sunabilir; ancak lisans, kullanıcı, tema, eklenti, entegrasyon, veri taşıma ve ilerideki geçiş giderleri birlikte değerlendirilmelidir. Projeye özel yazılımın keşif, geliştirme, test ve bakım maliyetleri de aynı zaman aralığında karşılaştırılmalıdır. Karar güncel tekliflerle hazırlanmış yaşam döngüsü bütçesine dayanmalıdır.
Projeye özel yazılım her zaman daha güvenli midir?
Hayır. Özel geliştirme daha fazla kontrol sağlayabilir fakat güvenlik; mimari, erişim kontrolü, kod inceleme, test, güncelleme, izleme ve bakım süreçlerine bağlıdır. Hazır bir ürün de düzenli güncelleniyor, doğru yapılandırılıyor ve gereksinime uyuyorsa güvenli biçimde kullanılabilir. Her iki seçenekte de sorumluluklar ve kanıtlar incelenmelidir.
Hazır altyapıyla başlayıp daha sonra özel yazılıma geçilebilir mi?
Evet; ancak geçiş kolaylığı veri dışa aktarma imkânına, hesap sahipliğine, URL yapısına, entegrasyonlara ve lisans koşullarına bağlıdır. Hazır sistem seçilirken verinin hangi formatta alınabileceği ve yeni sisteme geçişte hangi bağımlılıkların taşınamayacağı önceden sorulmalıdır.
Özel yazılımda kaynak kod ve veriler kime ait olur?
Bu konu sözleşmede açıkça yazılmalıdır. Kumsal Ajans projelerinde ödeme ve teslim koşulları tamamlandıktan sonra projeye özel geliştirilen kaynak kodlar müşteriye devredilir; proje içerikleri ve operasyonel veriler müşteriye aittir. Açık kaynak kütüphaneler, lisanslı bileşenler ve üçüncü taraf servisler ise kendi lisans koşullarına tabidir.
Altı aylık ücretsiz teknik destek neleri kapsar?
Aksi teklif veya sözleşmede belirtilmedikçe canlıya geçiş ya da nihai teslimden sonraki altı ay, teslim edilen kapsamdaki yazılım hatalarının giderilmesini ve proje kaynaklı teknik sorunların incelenmesini kapsar. Yeni özellikler, kapsam genişletme, tasarım revizyonları, yoğun içerik girişi, üçüncü taraf değişiklikleri, düzenli bakım ve servis ücretleri kapsam dışıdır.
