Vaka Çalışması: Lojgo — İki Taraflı Lojistik Platformunu Nasıl Kurguladık?

Lojgo, araç taşıma süreçlerini dijitalleştiren bir lojistik platformu: nakliye ihtiyacı olan müşterilerle profesyonel sürücüleri bir araya getiriyor. Bu yazıda projeyi nasıl kurguladığımızı, iki taraflı bir pazar yerinde hangi kararların kritik olduğunu anlatıyoruz.

Problem

Araç taşıtmak isteyen biri bugün hâlâ telefonla firma arıyor, fiyatı sözlü öğreniyor, aracının nerede olduğunu ancak arayarak öğrenebiliyor. Sürücü tarafında ise sorun tersinden aynı: rotası belli olan bir sürücü, dönüş yolunu boş yapmamak için iş bulmakta zorlanıyor. İki taraf da var, ama birbirini bulamıyor.

Neden iki taraflı pazar yeri zordur?

Klasik bir uygulamada tek bir kullanıcı yolculuğu tasarlarsınız. Pazar yerinde iki ayrı yolculuk ve ikisinin kesiştiği bir müzakere anı vardır. Zorluk şurada: platform, iki tarafın da aynı anda var olmasını gerektirir. Sürücü yoksa müşteri teklif alamaz, müşteri yoksa sürücü uygulamayı açmaz.

Bu yüzden ilk kararımız kapsamı ilanın çevresinde toplamak oldu: ilan aç, teklif al, teklifi seç, taşımayı izle. Bu zincir uçtan uca çalışmadan başka hiçbir özelliğin anlamı yok.

Kurduğumuz akış

• Çift taraflı yapı. Aynı uygulamada iki rol: aracını taşıtmak isteyen müşteri ve rotasındaki ilanlara teklif veren sürücü. Roller ayrı ekranlar, ayrı yetkiler ve ayrı bildirim mantığı demek.
• Hızlı ilan ve teklif sistemi. Müşteri dakikalar içinde ilan açıyor, birden fazla sürücüden rekabetçi teklif alıyor ve fiyat ile profil güvenini birlikte değerlendirerek seçim yapıyor.
• Gerçek zamanlı konum takibi. Taşıma başladıktan sonra aracın nerede olduğunun görülebilmesi, telefon trafiğinin büyük kısmını ortadan kaldıran özellik.
• Profil ve güven katmanı. Sürücü profili, geçmiş işler ve değerlendirme; pazar yerinde fiyattan sonra gelen ikinci karar kriteri.

Teknik tarafta verdiğimiz kararlar

Çapraz platform geliştirme. iOS ve Android'in tek kod tabanından çıkması, iki ayrı yerel uygulama yazmaya göre hem süreyi hem bakım maliyetini düşürüyor. Sürücü tarafı sahada, müşteri tarafı ofiste — ikisinin de aynı hızda güncellenmesi gerekiyor.

Konum verisini ölçülü toplamak. Sürekli konum takibi hem pil tüketir hem kişisel veri yükü getirir. Konumun yalnızca aktif taşıma sırasında ve gerekli sıklıkta toplanması, mağaza izin gerekçesini de KVKK tarafını da rahatlatır.

Bildirimler akışın parçası. Pazar yerlerinde bildirim bir "ek özellik" değil, ürünün kendisidir: teklif geldi, teklif kabul edildi, taşıma başladı. Bunlar geç ulaşırsa platform çalışmaz.

Bu projeden çıkardığımız üç ders

• Önce tek zinciri bitirin. İlan → teklif → seçim → takip zinciri kusursuz çalışmadan yan özelliklere geçmek, iki taraflı ürünlerde en sık yapılan hata.
• Güven, özellik listesinden önce gelir. Kullanıcı aracını tanımadığı birine teslim ediyor; profil, değerlendirme ve şeffaf fiyat bu yüzden lüks değil zorunluluk.
• Rolleri baştan ayırın. "Sonra sürücü ekranı ekleriz" diye başlanan projelerde veri modeli genelde baştan yazılmak zorunda kalıyor.

Benzer bir ürün mü düşünüyorsunuz?

Pazar yeri, rezervasyon, saha ekibi yönetimi gibi çok rollü ürünlerde en kritik aşama ilk kapsam kararıdır. Bu tür projeleri kendi ekibimizle geliştiriyoruz; Lojgo dahil işlerimizi projeler sayfamızdan inceleyebilir, kendi fikriniz için ücretsiz keşif görüşmesi talep edebilirsiniz.