WordPress mi Özel Yazılım mı? Kurumsal Site Kararı

Kurumsal bir site yaptırmaya karar verdiğinizde önünüze gelen üç teklif arasında ciddi bir fark olur ve bu fark neredeyse her zaman aynı cümleyle açıklanır: "Biz WordPress ile yapıyoruz, onlar sıfırdan yazıyor." WordPress mi özel yazılım mı sorusu tam burada başlar. Fakat teklifi karşılaştırırken bakılan tek şey ilk teslim bedeli olduğu için, kararın asıl belirleyicisi olan üç kalem gözden kaçar: siteyi ayakta tutmanın kime ne kadar iş çıkaracağı, kaynak kodun kimin olduğu ve iki yıl sonra geliştiriciyle yollar ayrıldığında elinizde ne kalacağı.

Bu yazıda satış cümlesi yok. WordPress ile özel yazılımı, yıllardır her iki tarafın da devir alma ve kurtarma işlerini yapan bir sistem yöneticisi gözünden karşılaştırıyorum: hangi işlerde hazır CMS gerçekten yeterli, hangi noktada zorlama olmaya başlıyor, bakım ve güncelleme yükü pratikte kimin omzuna biniyor, sözleşmede hangi maddeler olmazsa kaynak kod sizin olmuyor ve üç yıllık toplam maliyet kaleminde ilk teslim bedeli aslında ne kadar küçük bir pay tutuyor. Sonunda da somut bir karar ağacı bırakıyorum.

Teklifler Arasındaki Fiyat Farkı Nereden Geliyor#

Fiyat farkının kaynağı teknoloji değil, yazılan satır sayısıdır. WordPress teklifinde ajans, kimlik doğrulama, kullanıcı rolleri, medya kütüphanesi, revizyon geçmişi, form altyapısı, çok dillilik, arama, SEO alanları ve yönetim panelini hazır alır; kendi yazdığı kısım tema ve birkaç özel alan tanımından ibarettir. Özel yazılım teklifinde bunların hepsi yeniden yazılır ya da bir çatı (framework) üzerine kurulur — yani aynı işlevin arkasında 200 saatlik değil, 800 saatlik bir emek vardır.

Bu yüzden "WordPress ucuz" demek yanlış. Doğrusu şu: WordPress, sitenizin ihtiyaçlarının %80'i piyasada zaten çözülmüş standart ihtiyaçsa ucuzdur. O oran düştükçe hazır altyapıyı zorlamaya başlarsınız ve zorlama, eklenti üstüne eklenti, filtre üstüne filtre olarak birikir. Bir noktadan sonra "hazır sistemi eğip bükme" maliyeti, sıfırdan yazma maliyetini geçer. Kırılma noktasını bulmak bu yazının asıl konusu.

Tekliflerde şu kalemin ayrı yazılıp yazılmadığına bakın: teslim sonrası bakım. Çoğu WordPress teklifi bu kalemi hiç içermez, çünkü "WordPress zaten kendini günceller" varsayımı vardır. Bu varsayım yanlıştır ve faturası ikinci yılda kesilir.

WordPress Gerçekte Ne Zaman Yeter#

WordPress, içerik ağırlıklı ve iş akışı standart olan sitelerde fazlasıyla yeterlidir. Kurumsal tanıtım sitesi, blog, haber/duyuru, referans ve hizmet sayfaları, basit başvuru formları, çok dilli kurumsal yapı, kariyer sayfası — bunların hepsi WordPress'in tam olarak tasarlandığı iştir ve özel yazılımla yapmak sadece parayı yakmak olur.

Şu beş şart aynı anda sağlanıyorsa WordPress'te kalın:

1. Sitenin merkezinde içerik var, karmaşık bir iş süreci değil.
2. Kullanıcı rolleri "yönetici / editör / yazar" gibi standart bir hiyerarşiye oturuyor.
3. Dış sistemlerle entegrasyon ya yok ya da tek yönlü ve basit (form → e-posta, form → CRM).
4. Trafik öngörülebilir; anlık on binlerce eşzamanlı isteğe göre tasarım gerekmiyor.
5. Sayfa yapısını içerik ekibinin geliştiricisiz değiştirebilmesi bir gereksinim.

Beşinci madde çoğu zaman kararı tek başına verir. Özel yazılımda "ana sayfaya yeni bir bölüm ekleyelim" isteği bir geliştirme talebidir; WordPress'te bir öğleden sonra işidir. Kurumsal iletişim ekibi olan şirketlerde bu fark, üç yılda onlarca küçük talep demektir.

WordPress'in yetmediği yer ise "içerik" olmaktan çıkıp "uygulama" olmaya başlayan noktadır. Bunu kabaca şöyle test edebilirsiniz: sitede bir kaydın hayat döngüsü (oluşturma → onay → revizyon → arşiv) birden fazla rolün elinden geçiyorsa ve her adımda farklı doğrulama kuralları varsa, artık bir uygulama yazıyorsunuz demektir.

Özel Yazılım Ne Zaman Zorunlu Hale Gelir#

Özel yazılım, veri modeliniz standart dışıysa ve iş kuralları sitenin kendisi olduğunda zorunlu hale gelir. Aşağıdaki durumlarda WordPress'i zorlamak, ilk yıl ucuz görünüp ikinci yıl pahalıya patlayan klasik senaryodur:

• Karmaşık ilişkisel veri. Bayi → şube → personel → yetki matrisi gibi çok katmanlı ilişkiler. WordPress'te bunu wp_postmeta üzerine kurmak mümkündür ama her sorgu bir meta_query yığınına döner ve tablo birkaç yüz bin satıra ulaştığında yönetim paneli sürünmeye başlar.
• Yoğun yazma işlemi. Sipariş, rezervasyon, IoT verisi, log toplama gibi sürekli INSERT alan işler. WordPress okuma için önbelleklenebilir; yazma yükü önbelleklenemez.
• Sözleşmeli entegrasyon. ERP, muhasebe, banka, kargo, e-fatura entegrasyonlarında hata yönetimi, tekrar deneme kuyruğu ve mutabakat gerekir. Bunu eklenti mimarisinde güvenilir kurmak zordur.
• Denetim izi zorunluluğu. "Kim, ne zaman, hangi alanı değiştirdi" kaydının hukuki geçerlilik taşıması gerekiyorsa özel şema şart.
• Ağır özel arayüz. Kullanıcının 40 alanlı formu adım adım doldurduğu, ara kayıt tuttuğu, hesaplama yaptığı ekranlar.

Bir de ara yol var ve Türkçe içeriklerde neredeyse hiç konuşulmuyor: WordPress'i sadece içerik motoru olarak kullanıp uygulamayı ayrı yazmak. Kurumsal siteyi WordPress'te tutar, karmaşık modülü ayrı bir uygulama olarak app.sirket.com alt alan adında yayına alırsınız. İkisi aynı sunucuda, aynı SSL altında yaşayabilir; kullanıcı için tek site gibi görünür. Bu yaklaşım hem içerik ekibinin özerkliğini korur hem de karmaşıklığı WordPress'in dışına taşır. Alt alan adı kurulumunu subdomain nedir yazısındaki adımlarla yapabilirsiniz.

Bakım ve Güncelleme Yükü Pratikte Kimde#

Kararın en çok yanlış hesaplanan kalemi budur. İki tarafın da bakım yükü var, ama karakterleri tamamen farklı.

WordPress tarafında yük sık ama küçüktür. Çekirdek, tema ve eklentiler ayrı ayrı sürüm çıkarır; ayda birkaç güncelleme normaldir. Otomatik güncelleme çözüm gibi görünür fakat bir eklenti güncellemesi tema fonksiyonuyla çakıştığında site beyaz ekrana düşer ve bunu genellikle ziyaretçi haber verir. Doğru kurgu şudur:

# Güncellemeden önce mutlaka veritabanı + dosya yedeği
wp db export ~/yedek/$(date +%F)-oncesi.sql --allow-root
tar -czf ~/yedek/$(date +%F)-wp-content.tar.gz wp-content/

# Neyin güncelleneceğini önce listele, körlemesine güncelleme
wp plugin list --update=available --fields=name,version,update_version
wp core check-update

# Önce staging kopyasında dene, sonra canlıda uygula
wp plugin update --all --dry-run

--dry-run çıktısında beklenmedik bir eklenti görürseniz durun. Güncellemeyi doğrudan canlıda yapmak, üç yılda en az bir kez sizi gece yarısı kurtarma operasyonuna sokar. Bu yüzden ciddi kurumsal sitelerde ayrı bir test kopyası tutulur; staging ortamı nedir yazısında kurulumu anlatılıyor. Güncelleme sonrası kırılan sitelerin çözümü için wordpress güncelleme yönetimi rehberi işinizi görür.

Özel yazılım tarafında yük seyrek ama büyüktür. Aylarca hiçbir şey yapmazsınız; sonra PHP sürümü destek dışına çıkar, çatının uzun destekli sürümü biter, kullanılan bir kütüphane arşivlenir ve önünüze "iki haftalık yükseltme projesi" gelir. Kimse ayda 20 dakika güncelleme yapmadığı için bu iş birikir.

Son satır kritik: özel yazılımda geliştirici olmadan geçirdiğiniz her ay bir borç birikimidir. WordPress'te ise iyi kurulmuş bir bakım rutini, geliştirici olmadan uzun süre yürür — güvenlik tarafında wordpress güvenliği yazısındaki sertleştirme adımları uygulanmışsa.

Kaynak Kod Kimin: Sözleşmede Aranacak Maddeler#

Kaynak kodun size ait olduğunu varsaymayın; sözleşmede açıkça yazmıyorsa büyük ihtimalle değildir. Türkiye'deki ajans sözleşmelerinde en sık gördüğüm eksikler şunlardır:

1. Devir maddesi. "Teslim edilen yazılımın mali hakları, bedelin tamamının ödenmesiyle birlikte devredilir" ifadesi olmalı. Sadece "kullanım hakkı verilir" yazıyorsa siteyi kullanırsınız, sahibi olmazsınız.
2. Depo (repository) erişimi. Kodun sizin hesabınızdaki bir depoda tutulması, ajansın oraya katkı vermesi en temizidir. Depo ajansın hesabındaysa ilişki bittiğinde tarihçe de gider.
3. Üçüncü taraf lisansları. Kullanılan ticari tema, eklenti veya kütüphanelerin lisansları kimin adına? WordPress projelerinde en sık yaşanan kopuş budur: ajansın toplu lisansıyla kurulmuş premium eklenti, ilişki bitince güncelleme almaz.
4. Belgelendirme. Kurulum adımları, ortam değişkenleri, cron görevleri, dış servis anahtarlarının nerede tutulduğu.
5. Veri sahipliği ve dışa aktarma. Veritabanı dökümünün istendiğinde teslim edileceği.

Şunu somut olarak kontrol edin: elinizde kodun tamamı var mı? Test için basit bir doğrulama:

# Depoda dışarıdan çekilen bağımlılıklar dışında her şey var mı
git clone <depo-adresi> proje && cd proje
ls -la
test -f composer.json && composer install --no-dev
test -f .env.example && echo ".env.example var - ortam degiskenleri belgelenmis"

.env.example yoksa ve composer.json içindeki bazı paketler ajansın özel deposundan geliyorsa, kodu devralsanız bile kuramazsınız. WordPress tarafında karşılığı şudur: wp-content/plugins altındaki premium eklentilerin lisans anahtarları kimin hesabına bağlı?

Geliştiriciye Bağımlılık ve Devir Riski#

Bu, üç yıllık maliyetin görünmeyen ama en pahalı kalemidir. Ajansla yollar ayrıldığında yeni bir ekibin siteyi devralma süresi, iki modelde çok farklıdır.

WordPress'te devir kolaydır çünkü ortak bir dil vardır: yeni geliştirici wp-content/themes/aktif-tema altına bakar, functions.php ve şablon hiyerarşisini tanır, veritabanı şeması standarttır. Bir haftada yön bulur. Kötü senaryo, siteyi devraldığınızda içinde 40 eklenti ve sayfa oluşturucu (page builder) ile üretilmiş, veritabanına gömülü kısayol yığını bulmanızdır — bu durumda "WordPress kolaydır" avantajı buharlaşır.

Özel yazılımda devir süresi doğrudan belgelendirme ve kod kalitesiyle orantılıdır. Testleri olan, standart bir çatı kullanan, README'si düzgün bir projeyi yeni ekip iki-üç haftada devralır. Belgesiz, testsiz, "sadece yazan bilir" bir projede bu süre aylara çıkar ve genellikle "baştan yazalım" kararıyla biter — yani üç yıl önce ödediğiniz geliştirme bedelini ikinci kez ödersiniz.

Riski düşürmenin en etkili yolu, sözleşmeye devir provası koymaktır: teslimden sonra bağımsız bir geliştiricinin projeyi temiz bir sunucuda ayağa kaldırabilmesi kabul kriteri olsun. Bir öğleden sonrada ayağa kalkmıyorsa proje henüz teslim edilmemiştir.

Üç Yıllık Toplam Maliyet Tablosu#

Fiyat rakamı vermiyorum çünkü rakamlar bayatlar; onun yerine kalemleri ve göreli ağırlıklarını koyuyorum. İlk teslim bedelini 1 birim kabul edip diğer kalemleri ona oranla yazıyorum. Aşağıdaki ağırlıklar, orta ölçekli kurumsal projelerde gözlemlediğim tipik dağılımdır; sizin projenizde kaymalar olacaktır ama sıralama genellikle değişmez.

Tabloyu okuduğunuzda üç sonuç çıkar. Birincisi, ilk teslim bedeli üç yıllık toplamın genellikle yarısından azıdır — teklifleri sadece bu kalemle karşılaştırmak yanıltıcıdır. İkincisi, WordPress'in gerçek maliyeti barındırma değil, tekrar eden lisanslar ve düzenli bakımdır; bakımı yapmazsanız maliyet düşmez, sadece "beklenmeyen olay" satırına taşınır. Üçüncüsü, özel yazılımın maliyeti sabit gibi görünse de "küçük içerik değişikliği" satırı sessizce büyür; ana sayfada bir başlık değiştirmek için bilet açan bir şirketin üç yıl sonundaki faturası şaşırtıcı olur.

Barındırma Tarafındaki Fark: İki Yaklaşımın Sunucu İhtiyacı#

WordPress paylaşımlı barındırmada mutlu çalışır çünkü ihtiyaç duyduğu her şey (PHP, MySQL, mod_rewrite, mail) standart pakette vardır. Özel yazılım genellikle bir süreç yöneticisi, kuyruk işçisi, planlı görev ve bazen Node.js derleme adımı ister — bunlar paylaşımlı ortamda ya kısıtlıdır ya hiç yoktur. Kabaca:

# Özel yazılımın tipik ihtiyaç duyduğu, paylaşımlıda olmayan şeyler
# - kalıcı arka plan süreci (supervisor / systemd unit)
# - WebSocket için upgrade başlıkları
# - kendi PHP eklentileri ve ini ayarları
location /ws/ {
    proxy_pass http://127.0.0.1:6001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Bu satırları paylaşımlı bir hesapta yazamazsınız; sanal sunucuya geçmeniz gerekir. Yani özel yazılım kararı, çoğu zaman barındırma kararını da beraberinde getirir. WordPress tarafında ise yükün büyüdüğü noktada önce önbellek ve PHP ayarları devreye girer; sınırlara çarptığınızı gösteren belirtiler için paylaşımlı hosting kaynak limitleri yazısına bakın. Dış servis çağrılarının zaman aşımına düşmesi gibi klasik bir belirtiyi ise curl error 28 hatası yazısında adım adım çözüyoruz.

Taşınma ihtimalini de kararın parçası yapın: WordPress'i bir sunucudan diğerine taşımak belgelenmiş, tekrarlanabilir bir iştir (wordpress manuel site taşıma). Özel yazılımın taşınması, kurulum belgesi yoksa her seferinde küçük bir arkeoloji projesidir.

Karar Ağacı: Hangi Durumda Hangisi#

Aşağıdaki soruları sırayla cevaplayın; ilk "evet" aldığınız yerde durun.

1. Sitede kullanıcıların veri girdiği, onaydan geçen ve durumu değişen kayıtlar var mı? Evetse özel yazılıma (ya da WordPress + ayrı uygulama modeline) yaklaşın.
2. Dış bir sistemle çift yönlü, hata toleransı gerektiren entegrasyon var mı? Evetse aynı yön.
3. Günlük yazma hacmi okuma hacmine yaklaşıyor mu? Evetse aynı yön.
4. İçerik ekibi geliştiriciye sormadan sayfa yapısı değiştirebilmeli mi? Evetse WordPress.
5. Bütçe üç yıllık bakımı kaldırıyor mu? Kaldırmıyorsa WordPress; çünkü bakımsız özel yazılım, bakımsız WordPress'ten daha hızlı çürür.
6. Teknik ekibiniz var mı? Yoksa WordPress + dışarıdan bakım anlaşması en düşük riskli kurgudur.

Hazır platformlarla (site kurucu hizmetleri) kıyaslamayı da kararın içine katmak istiyorsanız, sahiplik ve taşınabilirlik açısından farkları wix mi wordpress mi yazısında ayrıntılı ele aldım — özel yazılım kararının mantığı orada da aynı eksende ilerliyor.

Sıkça Sorulan Sorular#

Kurumsal bir site için WordPress yeterli mi#

Çoğu kurumsal tanıtım sitesi için fazlasıyla yeterlidir. Kurumsal site dediğimiz yapı genellikle hakkımızda, hizmetler, referanslar, blog, kariyer ve iletişim sayfalarından oluşur; bunların hepsi WordPress'in doğal işidir. Yetersiz kaldığı yer, sitenin bir "uygulama" haline geldiği noktadır: çok adımlı onay süreçleri, karmaşık yetki matrisleri ve yoğun veri girişi. Karar verirken sayfa sayısına değil, kayıtların hayat döngüsüne bakın.

Özel yazılım gerçekten daha güvenli mi#

Doğrudan değil, sadece daha az hedeftir. WordPress dünyanın en yaygın CMS'i olduğu için otomatik tarayıcılar sürekli bilinen eklenti açıklarını dener; bu, güncel tutulan bir kurulumda gürültüdür, güncel tutulmayanda felakettir. Özel yazılımda bilinen açık listesi yoktur ama sizin yazdığınız hataları da kimse sizin için bulmaz. Pratikte güvenliği belirleyen teknoloji değil, güncelleme disiplini ve sunucu sertleştirmesidir.

Ajans siteyi WordPress ile yapıp özel yazılım fiyatı isteyebilir mi#

İsteyebilir ve bu her zaman kötü niyet anlamına gelmez. Bir WordPress projesinde de sıfırdan tema geliştirme, özel içerik tipleri, çok dilli yapı ve entegrasyon yazılmışsa emek gerçekten yüksektir. Ayrımı görmek için teklifte "kullanılacak hazır eklentiler" listesini isteyin. Liste uzunsa ve yazılacak özel kod azsa, emek de o oranda azdır.

Kaynak kodun bana ait olduğunu nasıl garantiye alırım#

Sözleşmeye mali hakların devri maddesini açıkça yazdırarak. "Kullanım hakkı" ile "mali hakların devri" hukuken çok farklı şeylerdir. Ayrıca kod deposunun sizin kurumsal hesabınızda açılmasını, üçüncü taraf lisansların şirketiniz adına alınmasını ve teslimde kurulum belgesiyle ortam değişkenleri örneğinin verilmesini şart koşun. Son olarak bağımsız bir geliştiricinin projeyi temiz bir sunucuda ayağa kaldırabilmesini kabul kriteri yapın.

WordPress ile başlayıp sonra özel yazılıma geçebilir miyim#

Geçebilirsiniz ve çoğu şirket için en akılcı yol budur. İçerikle başlayıp gerçek kullanım verisini topladıktan sonra hangi modülün özel yazılım gerektirdiğini görürsünüz. Geçişte içeriği taşımak zor değildir; zor olan URL yapısını korumaktır. Eski adresleri 301 ile yeni adreslere eşleyip arama sonuçlarındaki birikimi kaybetmeyin, aksi halde iki-üç aylık bir trafik düşüşü yaşarsınız.

Sayfa oluşturucu eklentiler ileride sorun çıkarır mı#

Evet, en sık karşılaştığım devir sorunu bunlardır. Sayfa oluşturucular içeriği kendi kısa kod veya JSON yapılarıyla veritabanına yazar; eklentiyi kaldırdığınızda sayfada ham işaretleme kalır. Tek bir oluşturucuya bağlı kalacaksanız bunu bilinçli bir karar olarak verin ve içerik dışa aktarma yolunuz olduğundan emin olun. Kurumsal sitelerde blok editörü ve özel alanlarla ilerlemek, uzun vadede taşınabilirliği belirgin biçimde artırır.

Üç yıl sonra hangi model daha ucuz çıkar#

Küçük ve içerik odaklı sitelerde WordPress neredeyse her zaman daha ucuzdur; çünkü değişiklik talepleri geliştirici gerektirmez. Buna karşılık iş süreçlerini taşıyan bir sitede WordPress'i zorlamanın maliyeti üçüncü yılda özel yazılımı geçer: eklenti çakışmaları, performans yamaları ve her yeni ihtiyaçta artan özel kod birikir. Kırılma noktasını belirleyen şey trafik değil, iş kurallarının karmaşıklığıdır.

Kapanış#

WordPress mi özel yazılım mı sorusunun tek doğru cevabı yok; doğru olan, kararı ilk teslim bedeliyle değil üç yıllık sahiplik maliyetiyle vermek. İçerik odaklı, iş kuralları standart bir kurumsal site için WordPress hem daha hızlı hem daha ucuzdur ve içerik ekibinize özerklik verir. Kayıtların durum değiştirdiği, entegrasyonların çift yönlü olduğu ve yazma hacminin yüksek olduğu işlerde ise özel yazılım kaçınılmazdır — ama ancak sözleşmede mali hak devri, depo erişimi, belgelendirme ve devir provası varsa gerçekten sizindir. Hangi tarafı seçerseniz seçin, bakım kalemini bütçeye yazmadan başlamayın: üç yılda kırılan sitelerin neredeyse tamamı, bakımı "sonra bakarız" diye erteleyen projelerden çıkıyor.

Altyapı tarafında ihtiyacınız netleştiyse: içerik odaklı bir kurumsal siteyi ayağa kaldıracaksanız WordPress hosting paketleri gerekli PHP ve veritabanı ayarlarıyla hazır gelir, kurumsal tanıtım siteleri için kurumsal hosting tarafına bakabilirsiniz. Güncelleme ve yedek disiplinini kendiniz taşımak istemiyorsanız WordPress bakım hizmeti bu yükü üstlenir. Projeniz hazır CMS'in dışına taşıyorsa ve kendi süreç yöneticinizi, kuyruğunuzu, özel PHP ayarlarınızı kuracaksanız VDS sunucu tarafına geçmeniz gerekir; işin yazılım kısmını dışarıya vermek isterseniz özel yazılım sayfasındaki kapsamı inceleyebilirsiniz.