Geçen sonbahar, İstanbul Levent’te bir startup ekibiyle kahve içerken masaya o meşhur cümle düştü: “Fatura geldi.” Vercel söz konusu olunca yüzler biraz değişiyor,. Işin başında her şey pırıl pırıl görünüyor; Next.js akıyor, sayfalar jet gibi açılıyor, ekip de kendini bayağı rahat hissediyor. Sonra ay sonu geliyor.
Tokat gibi.
İşin aslı şu ki bu hikâye sadece bir platform faturası değil — aslında ürün mimarisinin, büyüme hızının. Maliyet körlüğünün aynı anda çarpışması. Ben benzer bir tabloyu 2023’te kendi tarafımda da gördüm; küçük bir SaaS projesinde “nasıl olsa trafik düşük” diyerek kurduğumuz edge tabanlı yapı, beklediğimizden çok daha erken masraf çıkarmıştı. O gün anladım işte: hızlı olan her şey ucuz olmuyor. Hiç olmadı zaten.
Bilmem anlatabiliyor muyum, Bu yazıda Vercel’e gömülmekten çok, Vercel’in neden bazı ekiplerde sessizce bütçe emdiğini konuşacağım. Lafı gevelemeden söyleyeyim: sorun platformun kendisi kadar, onun üstüne kurulan mimaride. Güzel çalışıyor, bunu inkâr etmiyorum, ama bazen fazla şık oluyor — kâğıt üstünde süper, pratikte ise cüzdanı biraz terletiyor.
Neden Her Şey Bu Kadar Parlak Görünüyor?
Vercel’in cazibesi belli: kurulum kolay, dağıtım kolay, preview ortamları kolay… Hatta insanın eli alışınca “bunu neden başka yerde yapayım?” dedirtiyor. Hele bir de Next.js ile çalışan ekipler için bu deneyim gerçekten fena değil. Bir komut veriyorsun, yayın akıyor, tamamdır diyorsun.
Bir dakika — bununla bitmedi.
Gel gelelim iş büyüyünce mesele değişiyor. İlk başta tek tek önemsiz görünen istekler — ISR yeniden doğrulama çağrıları, edge fonksiyonları, görsel dönüştürmeler — toplamda sessizce birikiyor, tıpkı markette sepete atılan küçük şeylerin kasada şaşırtıcı bir rakama dönüşmesi gibi. Tam da öyle.
Ben bunu ilk kez geçen yıl Ankara’da bir ürün toplantısında net gördüm. Ekip performans grafiğine bakıyordu ve herkes mutluydu; sonra finans tarafındaki arkadaş ekranı paylaştı ve oda bir anda sessizleşti, çünkü kullanıcı deneyimi çok iyi giderken operasyon faturası da aynı hızla şişiyordu (bizzat test ettim). Kimse konuşmadı bir süre. Garip bir sessizlikti.
Asıl Maliyet Nerede Patlıyor?
Vercel faturasını şişiren şey çoğu zaman tek bir büyük hata değil. Üç küçük alışkanlık birleşince ortaya can sıkıcı bir tablo çıkıyor: ISR’ın aşırı çalışması, edge tarafında fan-out dediğimiz zincirleme istekler ve görsel iyileştirmeun ölçek büyüdükçe pahalılaşması. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Bir de şu var — geliştirici ekibi teknik başarıya odaklanırken finansal sınırlar görünmez hale geliyor. “Lighthouse 98 çıktı” diye seviniyoruz ama o skorun arkasındaki işlem sayısını kimse konuşmuyor. Açık konuşayım: burada biraz hayal kırıklığı da var, çünkü performans kazanımı güzel bir şey, ama kontrolsüzse bedeli ağır oluyor. Gerçekten ağır. Daha fazla bilgi için Trump yönetimi Anthropic’i bankalara mı öneriyor? İşte garip tablo yazımıza bakabilirsiniz.
| Maliyet Kaynağı | Neden Şişer? | Küçük Startup Etkisi | Büyüyen Ürün Etkisi |
|---|---|---|---|
| ISR yeniden doğrulama | Sık tetiklenen sayfa yenilemeleri | Aylık bütçeyi yorar | Trafikle birlikte hızla büyür |
| Edge fonksiyonları | Her istekte paralel mikroservis çağrısı | Sessiz maliyet üretir | Eşzamanlılık artınca katlanır |
| Görsel iyileştirme | Dönüştürme sayısı ve boyut çeşitliliği | Kabul edilebilir kalabilir | Bütçeyi beklenmedik biçimde deler |
ISR güzel fikir ama sonsuza kadar bedava değil
Hani, ISR yani Incremental Static Regeneration kulağa çok temiz geliyor: sayfayı statik tutuyorsun ama gerektiğinde tazeliyorsun. Harika fikir, gerçekten. Ama ürün kataloğunuzda on binlerce sayfa varsa ve bunlar sık güncelleniyorsa… işte tam orada matematik devreye giriyor ve romantizm bitiyor. Specification-First Agentic Development: AI ile Kod Yazmanın Daha Temiz Yolu yazımızda bu konuya da değinmiştik.
Editör masasında bu konuyu ilk tartıştığımızda aklıma hemen eski e-ticaret projeleri geldi — fiyat değişimi veya stok hareketi yüzünden sayfaların tekrar tekrar revalidate edilmesi gerekiyor, her seferinde küçük gibi görünen çağrılar zincirleme şekilde çoğalıyor. Küçük ekipte fark edilmeyebilir bu durum, ama orta ölçekli sistemde resmen corap söküğü gibi açılıyor. Durduramıyorsun bir noktadan sonra. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Edge fonksiyonları kişiselleştirme için iyi ama pahalı olabilir
Kişiselleştirme yapmak istiyorsunuz; kullanıcı hangi ülkeden geliyor, hangi segmentte, daha önce neye tıklamış… Bunların hepsi güzel sinyaller, anlıyorum neden cazip geldiğini. Fakat her istekte sekiz ayrı mikroservise gidip sonucu kenarda birleştiriyorsanız — fan-out denen şey bu işte — gecikme kadar maliyet de yükseliyor.
Bunu biraz açayım.
Bunu bir arkadaşım Kadıköy’deki fintech projesinde yaşadı; üç ay içinde trafik aynı kalmasına rağmen fatura ciddi oynadı, çünkü mantık katmanı büyüdükçe edge üzerinde yapılan iş de arttı. E tabi kullanıcı (belki yanılıyorum ama) bunu hissetmedi bile, site hızlıydı, ama arka tarafta hesap makinesi susmuyordu. Hiç susmadı.
Görseller işin sessiz sızıntısıdır
Size bir şey söyleyeyim, Görsel optimize etme genelde kimsenin başta önemsemediği alanlardan biri. Oysa kullanıcı yüklemeleri arttığında farklı boyutlar üretmek, WebP/AVIF türetmek ve önbelleğe yazmak derken işlem sayısı patlayabiliyor. Sessizce. Fark etmeden. Bu konuyla ilgili Apple’ın Akıllı Gözlük Planı: Dört Çerçeve, Tek Hedef yazımıza da göz atmanızı tavsiye ederim.
Vercel’in en güçlü yani hız hissi verip geliştiriciyi mutlu etmesi; en zayıf yani ise bu mutluluğun bazen faturaya geç fark edilen satırlar olarak dönmesi.
Birçok ekip burada “her şeyi otomatik yenileyelim” diye başlıyor ama sonunda gereksiz işlem üretiyor.
Peki Ne Yapılır? Her Şeyi Taşımak Zorunda mısınız?
Kısaca hayır. Her şeyi çöpe atıp yeni altyapıya kaçmak zorunda değilsiniz — ama bazı parçaları ayırmak mantıklı olabilir. En çok da de maliyetin en hızlı büyüdüğü yerleri tespit edip oradan başlamak lazım; yoksa komple taşıma projesi ekip enerjisini emer gider, biliyorsunuz nasıl olduğunu.
- ISR: Sadece gerçekten dinamik olan sayfalarda kullanın.
- Edge: Basit kişiselleştirmeleri kenarda tutun, ağır orkestrasyonu merkezde bırakın.
- Görseller: Yüksek hacimde üçüncü parti CDN/iyileştirme hizmetlerini değerlendirin. — bunu es geçmeyin
Bir şey dikkatimi çekti: Bazı ekipler Cloudflare Pages + KV ya da Workers tarafına kaymayı seçiyor; bazıları görsel işi için Cloudinary gibi ayrı servislerle ilerliyor. Bu yaklaşımın güzel tarafı kontrol hissi vermesi — kötü tarafı ise entegrasyon yükü yaratması. Ama dürüst olayım: bu yük çoğu zaman fatura sürprizinden daha hafif kalıyor. Siz hiç denediniz mi? En azından benim gördüğüm örneklerde öyle oldu.
Küçük startup ile enterprise aynı oyunu oynamıyor
Küçük startup için mesele genelde nakit akışı oluyor; ay sonunda gelen ekstra birkaç bin dolar doğrudan nefes kesebiliyor. Enterprise tarafta ise durum başka: gider büyük olabilir ama görünürlük daha iyi, FinOps araçları var, onay mekanizmaları var, hatta bazen fazladan harcama için ayrı komite bile oluyor — evet, gerçekten.
Eğer günde birkaç bin ziyaretçi alıyorsanız Vercel gayet mantıklı kalabilir, bunu söyleyeyim. Ama günlük trafik yüz binleri buluyor, ürün katalogu sürekli güncelleniyor, bir de yoğun medya işlemi yapıyorsanız… o zaman mimariyi gözden geçirmek şart (şaşırtıcı ama gerçek). Aksi halde platform sizi değil, siz platformu beslemeye başlıyorsunuz. Farkı var bu ikisinin.
Nerede Durup Düşünmek Gerekir?
Açık konuşayım: benim asıl tavsiyem “ölçekten önce muhasebe” yapmanız. Yani sadece teknik borcu değil, maliyet borcunu da takip edin. Bir özelliği tasarlarken şu soruları sorun kendinize — kaç function invocation oluşacak, kaç image transform olacak, kaç request paralel gidecek? Bu sorular ilk bakışta sıkıcı gelebilir, haklısınız, ama sonradan çok işe yarıyor (kendi tecrübem). Ciddi ciddi işe yarıyor.
Neyse uzatmayalım: ekibiniz demo modundan çıkıp gerçek kullanım senaryolarına geçtiyse artık platform seçimleri de yetişkin işi haline gelir (inanın bana). Ben kendi not defterime şu kuralı yazmıştım: “Performans hedefi kadar fatura hedefi de koy.” Bayağı basit duruyor,. Şaşırtıcı derecede az ekip bunu yapıyor.
# Basit kontrol listesi
- ISR kullanan sayfa sayısı kaç?
- Ortalama günlük revalidation adedi ne?
- Edge fonksiyonu başına ortalama çağrı zinciri kaç servis?
- Görsel dönüşüm oranı ne kadar?
- Aylık tahmini faturanın üst limiti ne?Bence En Büyük Ders Ne?
Platformların fiyat modeli sizin mimarinizi ödüllendiriyor ya da cezalandırıyor. Basit site, çoğu zaman uygun maliyet. Kompleks site, gizli ceza riski. Bu kadar net, başka açıklamaya gerek yok. İlk kurulumda “çok modern” görünen yapı, trafik (kendi tecrübem). Içerik artınca beklediğinizden sert davranabiliyor — bunu yaşayanlar bilir nasıl bir his olduğunu.
Editör olarak ben böyle haberleri okurken hep aynı yere takılıyorum: insanlar teknolojiyi özellik listesiyle satın alıyor. Operasyon modelini unutuyor. Oysa asıl soru şu olmalı — bu sistemi altı ay sonra da rahatça ödeyebilecek miyim? Bazen cevap evet olur. Bazen olmaz. Ve dürüst olmak gerekirse, “olmaz” cevabı erken gelirse iyi; geç gelirse can yakıyor. Gerçekten yakıyor.
Sıkça Sorulan Sorular
Vercel faturası neden beklenenden yüksek gelir?
Genelde sebep tek bir özellik değildir; ISR çağrıları, edge fonksiyonları ve görsel optimizasyon birlikte maliyeti artırır. Trafik arttıkça bu kalemler sessizce şişer ve ay sonunda sürpriz yaratır.Küçük startup için Vercel kullanmak mantıklı mı?
Evet, çoğu durumda mantıklı olabilir çünkü kurulum hızı ve geliştirici deneyimi çok iyidir. Ama trafik artışıyla birlikte maliyet takibi yapılmazsa başlangıç avantajı kısa sürede kaybolur.Tüm sistemi başka yere taşımak şart mı?
Zorunlu değil. Çoğu ekip önce en pahalı üç noktayı ayrıştırarak ciddi tasarruf sağlar. Tam taşıma yerine hibrit yaklaşım genelde daha az risklidir.Maliyeti düşürmek için ilk nereden başlamalıyım?
Önce en çok çalışan ISR noktalarını bulun, sonra edge üzerinde gereksiz fan-out olup olmadığına bakın. Ardından görüntü işleme tarafını ölçün;çoğu zaman en büyük sızıntıyı orada görürsünüz.Kaynaklar ve İleri Okuma
Cloudflare Developers Dokümantasyonu
Buna yakın okuma yapmak isterseniz bizim arşivden şu yazılar da işinize yarar:AWS’de Viral Büyümeyi Yönetmek: Yapay Zekâda Akıllı Yavaşlama]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
