​

Ücretsiz katman ve paywall gözden geçirmesi

Tarih: 2026-08-29 Bağlam: ~200 kayıtlı üye, ~300 izlenen site, 1 ödeyen müşteri, hesap başına ~1.5 monitör.

---

​

Teşhis

Paywall yanlış eksende duruyor. Bugünkü tek gerçek duvar hacim (monitör sayısı), ama ajans profilinin canını yakan şey hacim değil: müşteriye gösterilen yüzey (status page, alan adı, marka), geçmiş veri (aylık rapor), ekip ve nöbet (SMS/eskalasyon). Bunların hepsi ya bedava ya da yanlış basamakta. İki sayı bunu özetliyor:

• Ortalama 1.5 monitör/hesap, ücretsiz limit 10. Medyan kullanıcı limitin ~%15’ini kullanıyor — limit onun için görünmez.
• 5-10 müşterisi olan bir ajans da 10’un altında kalıyor. Yani limit onun için de görünmez. Duvar iki profilin de arasına düşmüyor.

Daha kritiği: ajans 10’u aşsa bile **Solo’ya ($5.99) düşüyor ve orada 50 site buluyor.** Ajans profili Team'e ($19.99) hiç ulaşmıyor. Asıl taşınması gereken duvar Free→Solo değil, Solo→Team.

---

​

Mevcut durum (koddan çıkarıldı, ilanla karşılaştırmalı)

Kaynaklar: plans.ts:25-215, CheckRange.tsx:11, statusPageDetail.route.ts:30, monitoring.constants.ts:37.

---

​

Önce kapatılması gereken 4 sızıntı

Bunlar fiyatlandırma kararı değil, hata. Yeni limitler koyulmadan önce kapanmalı, yoksa yeni limitler de aynı şekilde delinir.

​

1. Check aralığı sunucuda hiç kontrol edilmiyor — 60× maliyet açığı

PLAN_MIN_LIMITS yalnızca frontend’te: CheckRange.tsx:11-16. Backend tarafında tek sınır Math.max(5_000, ...): detailSite.controller.ts:334. Elinde token olan herhangi bir ücretsiz kullanıcı PUT /site/:id/change-check-interval ile 5 saniye yazabilir. 5 dakika yerine 5 saniye = 60× probe, üstelik 3 bölgeden. Tek bir hesap tüm edge kapasitesini yiyebilir. Yapılacak: aralık alt sınırını UserSource.limits’e taşı (minCheckIntervalMs) ve changeCheckInterval içinde uygula. Site oluşturma yolunda da aynı sınır geçerli olmalı.

​

2. stats koleksiyonunda TTL yok — saklama politikası fiilen “sonsuz”

Stat.model.ts hiçbir TTL indeksi tanımlamıyor. Buna karşılık yeni monitoring hattının tamamı 3 gün: MON_RUN_TTL_DAYS = 3 (buildExpiresAt.ts:1), Evidence de expiresAt TTL’li. Yani ücretli planların bile satılabilir bir “geçmiş” vaadi yok, ücretsiz katmanın da maliyeti sınırsız büyüyor. Saklama süresi hem en büyük gizli maliyet hem de satılmayan en değerli ajans özelliği.

​

3. Solo’nun SMS kotası yalan söylüyor

notificationLimits.user.byType.sms = 10 (plans.ts:98) ama sms: false (plans.ts:106). Kota var, kanal kapalı. İkisinden biri düzeltilmeli — tercihen kota 0’a çekilmeli, SMS Team’de kalmalı.

​

4. “Powered by Watchman Tower” hiçbir planda kaldırılamıyor

Footer.tsx:55 koşulsuz. Ajansın müşterisine gösterdiği sayfada bizim markamız duruyor ve bunu kaldırmanın satın alınabilir bir yolu yok. Bu, ajansın en yüksek ödeme isteği olan kalemlerden biri ve şu anda ürün olarak mevcut değil.

---

​

Önerilen yeni yapı

Prensip: ücretsiz katman “kendi sitesini izleyen birey” için tasarlansın, tam ve utanmadan çalışsın; üçüncü müşteride duvara çarpsın. Ajans profilinin duvara çarpma sırası — hepsi ilk hafta içinde:

1. 3. müşteri sitesi → monitör limiti (gün 1-3)
2. İlk aylık rapor → 7 günlük geçmiş yetmiyor (gün 30, ama farkına 7. günde varır)
3. Müşteriye link yollama → 1 status page, üstünde bizim markamız (gün 1)
4. Ekibe devretme → paylaşım 0, takım yok (gün 5-10)
5. Müşteri SLA sorunca → SMS/eskalasyon yok

Bireysel kullanıcı bunların hiçbirine çarpmaz: 1 site, 1 status page, 7 günlük geçmiş, e-posta + push alarm — ürünün tamamı ona bedava ve eksiksiz.

​

Neden Solo da 10’a iniyor

Solo’nun bugünkü 50 site limiti, “bağımsız operatör” tarifiyle uyuşmuyor ve ajansı $5.99’da tutuyor. Solo 10’a inince merdiven şöyle okunur:

• 1-3 site → Free
• 4-10 site (serbest çalışan, birkaç müşteri) → Solo $5.99
• 10+ site + ekip + müşteri yüzeyi → Team $19.99

Bu tek değişiklik, ajans profilinin varış noktasını $5.99'dan$19.99’a taşıyor.

​

3 mü 5 mi?

Kesin sayı segmentasyon sorgusundan sonra seçilmeli. Karar kuralı: mevcut ücretsiz hesapların en az %80’i yeni limitin altında kalmalı. backend-ts/scripts/analytics/account-segmentation.mongo.js çıktısındaki 1 ve 2-4 kovalarının toplam payı bunu doğrudan verir. 1.5 ortalamayla 3’ün rahat geçmesi bekleniyor; 2-4 kovası şişkin çıkarsa 5’e çekilir.

---

​

Göç: grandfathering bedava geliyor

Mimaride şanslı bir ayrım var — limit kontrolü Plan’ı değil, kullanıcı başına kopyalanan UserSource.limits’i okuyor (checkUserSourceLimits.middleware.ts:62), ve bu kopya kayıt anında User post-save hook’unda oluşuyor (User.model.ts). Sonuç:

• plans dokümanını güncellemek yalnızca yeni kayıtları etkiler.
• Mevcut 200 hesap, usersources üzerinde updateMany çalıştırılmadıkça eski limitlerinde kalır — yani grandfathering varsayılan davranış.
• 26 sitelik tohum veri ve 7 aylık gözlem hiçbir şekilde risk altında değil.

Uygulama adımları:

1. firstCreatePlans yalnızca planCount === 0 iken çalışıyor (plans.ts:13) — seed’i değiştirmek canlıyı değiştirmez. Dosyanın altındaki appAgentLimit backfill bloğu (plans.ts:236-268) doğru deseni gösteriyor: idempotent findOneAndUpdate + hedefli UserSourceModel.updateMany.
2. Plan dokümanı güncellendikten sonra Redis plan cache’i (plan:data:*, plan:name:*) mutlaka tazelenmeli — plan.service.ts:35.
3. Saklama süresi önce okuma tarafında uygulanmalı (API plan penceresinden eskisini döndürmesin), TTL indeksi sonra. Ters sırada yapılırsa tohum veri silinir ve geri gelmez.

---

​

Ölçüm

Değişiklikten önce ve 30 gün sonra aynı sorgu koşulmalı (backend-ts/scripts/analytics/account-segmentation.mongo.js). İzlenecekler:

• 2-4 ve 5-9 kovalarındaki hesap sayısı — limitin gerçekten ısırıp ısırmadığı
• ücretsiz katmanın aylık probe payı — maliyet tarafının düşüşü
• zombi hesap sayısı — login yok ama check koşuyor
• Free→Solo ve Solo→Team dönüşümleri — asıl aranan sinyal Solo→Team

Tek ödeyen müşteriyle istatistiksel anlamlılık yok; bu yüzden karar kriteri dönüşüm oranı değil, duvara çarpan hesap sayısı olmalı. Kimse duvara çarpmıyorsa duvar hâlâ yanlış yerde demektir.