MotoRiders

Kısa özet

Türkiye'deki Voge sürücüleri bilgiyi, etkinliği ve fırsatı farklı yerlerde arıyordu: sohbet bir grupta, duyuru başka bir hikâyede, indirim bir mesajda kayboluyordu. MotoRiders'ı, bu dağınık akışı tek bir topluluk platformunda birleştirmek için kurduk.

Sonuç: motoriders.com.tr üzerinde forum, üye profili, model deneyimleri, rotalar, etkinlikler, bayi/satıcı vitrinleri ve üye ilanları aynı çatı altında çalışıyor. Altyapı Cloudflare edge üzerinde; site "broşür" değil, her gün kullanılan bir ürün.

Proje neydi?

MotoRiders, Voge markası etrafında toplanan sürücülerin ortak dünyası. Amaç basit görünen ama zor bir şeydi:

• Bilgiyi aranabilir ve kalıcı hale getirmek
• Deneyimi (model yorumları, rotalar, buluşmalar) görünür kılmak
• Ticari iş birliklerini (bayi, satıcı, kampanya) topluluğa zarar vermeden yerleştirmek
• Yönetimi "admin panelinden bir şey silmek" seviyesinden çıkarıp gerçek bir moderasyon düzenine oturtmak

DN Yazılım tarafında bu, tipik bir kurumsal site işi değildi. Keşiften deploy'a kadar ürün gibi ele alındı: roller, onaylar, medya, performans, mobil kullanım, içerik yönetimi.

Problem: Topluluk vardı, düzen yoktu

Motosiklet topluluklarında tanıdık bir tablo:

1. Sohbet dağınık. WhatsApp ve sosyal gruplarda bilgi hızla akıyor ama aranmıyor. Dün konuşulan lastik basıncı yarın kayboluyor.
2. Etkinlik dağınık. Buluşma bir story'de kalıyor; kim nerede, ne zaman, kim geliyor belirsiz.
3. Güven dağınık. "Bu satıcı güvenilir mi?", "Bu modelde kim ne yaşadı?" sorularının cevabı kişisel tanıdık zincirine bağlı.
4. İş birliği dağınık. Bayi ve satıcılar topluluğa katkı vermek istiyor ama tek kanal yok; spam ile değer arasındaki çizgi bulanık.

İhtiyaç bir "güzel anasayfa" değildi. İhtiyaç, üye girişi olan, roller taşıyan, içerik üreten, onay bekleyen, bildirim atan bir platformdu.

Zorluk 1 — Broşür site ile ürün sitesini karıştırmamak

İlk mimari karar: bunu statik bir vitrin gibi düşünmeyecektik.

Klasik "5 sayfalık site" yaklaşımı burada çöker:

• Forum konuları, yanıtlar, tepkiler, çözüm işaretleme
• Üye profilleri, garaj, rozetler, doğrulama
• Etkinlik önerisi ve onay
• Rota paylaşımları
• Pazar yeri / ilanlar
• Bayi ve satıcı panelleri
• Yönetim ve moderasyon

Bunların her biri kendi veri modeli, kendi yetki kuralı ve kendi arayüz yoğunluğunu ister. Erken aşamada "hepsini bir kerede mükemmel" demek yerine ürünü çekirdek topluluk akışı + ticari yüzeyler diye katmanladık.

Akıllıca olan kısım: ölçeğe uygun mimari. Ne "her şey mikroservis" aşırılığı, ne de "tek PHP dosyası" naifliği. Tek Next.js uygulaması, edge'de çalışan bir Worker, ilişkisel veri ve nesne depolama ile ilerlemek.

Zorluk 2 — Edge'de gerçek uygulama çalıştırmak

Türkiye'den erişilen, medya ağır, oturumlu bir platformu klasik VPS'te de kurabilirdik. Tercihimiz Cloudflare ekosistemi oldu:

• Workers ile uygulama katmanı
• D1 ile ilişkisel veri
• R2 ile medya
• CDN ve edge cache ile statik/yarı-statik yüzeyler

Bu seçim bedavaya hız getirmez; doğru kullanılmazsa tersine sürtünme yaratır. Bizim için kazanç şuydu:

• Türkiye ve yakın bölgelerde düşük gecikme
• Medya ve HTML'in aynı kenarda yaşaması
• Deploy'un "sunucu güncellemesi" değil, sürüm yayınlamak olması
• Bakım yükünün küçük ekibe sığması

DN Yazılım'ın blog tarafında da yazdığı gibi: edge her işe ilaç değil. Ama oturumlu + medyalı + sık güncellenen bir topluluk ürününde, doğru sınırlarla çok işe yarıyor.

Zorluk 3 — Yetki modeli: "admin her şeyi yapar" yetmez

Topluluk büyüdükçe tek süper kullanıcı modeli çöker. MotoRiders'ta roller bilinçli ayrıldı:

• Süper yönetici
• Yönetici
• Bölge lideri
• İl temsilcisi
• Moderatör
• Üye

Bu sadece menüde rozet göstermek değil. Örneğin forumda:

• Kim kilitleyebilir / sabitleyebilir
• Kim taşıma talebi açar, kim onaylar
• Kim konu başlığını değiştirebilir
• Kim açılış metnini (rehber içerikler) düzenleyebilir

özellikle hassas. Resmi ve sabitlenmiş rehber konuların başlığı ve URL'si WhatsApp paylaşımlarına, yer imlerine ve arama sonuçlarına bağlı. Başlık değişince bağlantının ölmesi kabul edilemez.

Çözüm yaklaşımı:

• Hassas işlemler için sunucu tarafı yetki kontrolü (sadece butonu gizlemek yetmez)
• Başlık değişse bile slug'ın sabit kalması
• Değişikliklerin kayda geçmesi
• Kilitli içerikte bile kontrollü düzenleme hakkı (doğru role)

Bu tür kurallar "ürün detayı" gibi görünür; aslında topluluğun güvenidir.

Zorluk 4 — Medya ve görsel optimizasyonu edge'de başka türlü kırılır

Topluluk platformlarında görsel her yerde: avatar, ilan, kapak, rota, etkinlik. Next.js Image Optimization ile Cloudflare Images bağını birlikte kullanmak güçlü; ama göreli /api/media/... yollarının edge optimizer tarafından statik asset sanılması gibi pratik tuzaklar çıkar.

Karşılaştığımız tipik senaryo:

• Medya endpoint'i doğrudan açılınca dosya geliyor
• Optimizer üzerinden istenince "upstream invalid" benzeri hata

Sebep çoğu zaman "dosya yok" değil; optimizer'ın kaynağı yanlış yerden araması.

Çözüm çizgisi (meslek sırrı olmadan):

• Dinamik medya ile statik asset yollarını ayırmak
• Optimizer'ın görebileceği şekilde kaynak URL stratejisi kurmak
• Aynı origin / public fetch davranışını production'da doğrulamak

Bu sınıf hatalar demo'da görünmez, canlı trafikte görünür. O yüzden "çalışıyor" demeden önce gerçek domain üzerinde uçtan uca kontrol şart.

Zorluk 5 — Masaüstü / mobil aynı ürün, farklı alışkanlık

Sürücü kitlesi mobilde yaşıyor; yönetim ve uzun okuma çoğu zaman masaüstünde. Bu yüzden kabuk tasarımı ikiye bölündü:

• Mobilde alt sekme (forum, etkinlik, bildirim, profil)
• Masaüstünde yan menü + üst bar (arama, hesap, tema, bildirim)

Küçük ama kritik bir örnek: bildirim çanı mobilde vardı, masaüstünde yoktu. "Mobilde var" yetmez; ürünün ana yüzeylerinde tutarlı olmalı. Benzer şekilde yerinde CMS düzenleme butonunun kartın hangi köşesinde durduğu bile kullanım kalitesini değiştiriyor — çünkü kartın sağ üstü sık sık favori/paylaşım gibi aksiyonlarla dolu.

Zorluk 6 — İçerik yönetimi: her metin için developer çağrılamaz

Duyuru, hero metni, hakkımızda, paket açıklamaları… Bunlar sık değişir. Her değişiklik için deploy beklemek hem pahalı hem yavaş.

Bu yüzden yerinde CMS yaklaşımına gittik: yetkili kullanıcı sayfada içeriğin üstüne gelince düzenleyebiliyor, kaydedince yayınlanıyor. Amaç WordPress klonu yapmak değil; operasyonel sürtünmeyi düşürmek.

Akıllıca olan: CMS'i herkese açmamak, alanları şemayla sınırlamak, zengin metin ile düz metni ayırmak. "Her şeyi HTML editör" tuzağına düşmeden.

Zorluk 7 — Topluluk + ticaret dengesi

Platformda hem üye ilanları hem premium satıcı/bayi yüzeyleri var. Bu dengede iki risk:

1. Ticaret topluluğu boğar
2. Ticaret görünmez kalır, iş birliği ölür

Çözüm "reklamı her yere yapıştırmak" değil; paket, onay ve vitrin kurallarıyla kontrollü öne çıkarma. Kampanya / bildirim tarafında da "ne kadar çok o kadar iyi" yerine planlı, kullanıcıyı yormayan bir akış hedeflendi.

Burada bilinçli olarak rakam, fiyat ve iç kural detayına girmiyoruz — bunlar operasyonel sır. Dışarıdan görünen ise şu: ticaret, platformun birinci sınıf vatandaşı; ama forumun üstüne oturmuyor.

Zorluk 8 — Performans: her şeyi ilk boyada yüklememek

Messenger, asistan, bazı yönetim parçaları… Hepsi ilk paint'e girerse LCP ve etkileşim bozulur. Kabukta ertelenmiş yükleme (idle / ihtiyaç anı) kullandık: kullanıcı asıl içeriği görsün, ikincil widget'lar sonra gelsin.

Aynı mantık menüde de geçerli: büyük kullanıcı kartı menüyü aşağı itiyorsa, hesabı üst bara taşımak hem UX hem performans algısını düzeltir. "Özellik eklemek" bazen "doğru yere koymak"tır.

Ne teslim edildi? (dışarıdan görünen kapsam)

Canlı adreste bugün görülebilen başlıca yüzeyler:

• Topluluk forumları (kategori, konu, yanıt, tepki, moderasyon)
• Üye hesapları ve profiller
• Model katalogu ve kullanıcı deneyimleri
• Rotalar
• Etkinlikler
• Bayi ve indirimli satıcı vitrinleri
• Üye ilanları / pazar yeri
• Bildirimler
• Yönetim ve onay akışları
• Yerinde içerik düzenleme

Teknik iskelet (yüksek seviye):

• Next.js uygulama
• Cloudflare Workers deploy
• D1 + R2
• Edge uyumlu medya ve görsel pipeline
• Rol tabanlı yetki ve denetim izi

Öğrendiklerimiz (bir sonraki işe taşıdığımız dersler)

1. Topluluk ürünü = içerik sitesi değildir. Yetki, onay, bildirim ve güven tasarımı baştan konuşulmalı.
2. Edge güçlüdür, sihir değildir. Özellikle medya + image optimizer + aynı origin fetch üçgenini production'da test etmeden "bitti" demeyin.
3. Slug'ı başlıktan ayırın. Paylaşılan bağlantılar topluluğun hafızasıdır.
4. Mobil ve masaüstünü ayrı düşünün, sonra birleştirin. Aynı özellik iki yüzeyde farklı yerde yaşayabilir; tutarsızlık bug gibi hissedilir.
5. Operasyonu ürünün içine gömün. Yerinde CMS, onay kuyrukları, moderasyon barı — bunlar "sonra ekleriz" değil, yaşayan sistemin parçası.
6. Küçük ekip için doğru soyutlama. Az servis, net sınır, sık deploy.

Sonuç

MotoRiders'ı bir "motosiklet temalı web sitesi" olarak değil, Türkiye'deki Voge sürücüleri için çalışan bir topluluk işletim sistemi olarak ele aldık.

Dağınık sohbetin yerine aranabilir bilgi; kaybolan duyurunun yerine kalıcı içerik; rastgele mesajların yerine kurallı iş birliği koyduk. Altyapıyı Cloudflare edge'e oturttuk; ürünü küçük parçalarla büyüttük; hassas yerlerde yetkiyi ve kaydı sıkı tuttuk.

Canlı adres: https://motoriders.com.tr

DN Yazılım olarak bu işte yaptığımız şey, güzel ekran çizmekten çok şuydu: büyüyen bir topluluğun temposuna dayanan mimariyi kurmak.