Tek bakışta operasyon: kim sırada, kim müsait, kim meşgul ve sürücüler durak alanına göre nerede?
Kağıt defterden canlı operasyon sistemine
2yaka, taksi durağında her gün tekrar eden çok temel bir güven probleminden doğdu: sıraya kimin önce girdiği, kimin yolcu aldığı, kimin sıradan çıktığı ve yöneticinin ne zaman müdahale ettiği çoğu zaman kağıt, WhatsApp veya sözlü hafıza üzerinden takip ediliyor. Bu yalnızca verimsizlik yaratmıyor; şoförün günlük kazancını ve durak içindeki adalet duygusunu doğrudan etkiliyor.
Benim ürün yaklaşımım bu problemi sadece dijital bir listeye çevirmek değildi. Sırayı tek bir kaynaktan hesaplayan, değişiklikleri kayıt altında tutan, şoföre kendi konumunu açıkça gösteren ve yöneticinin müdahalesini görünür kılan bir operasyon modeli tasarladım. Ürünün merkezindeki vaat bu yüzden teknoloji değil: her şoförün hak ettiği sırayı alması ve durağın hafızasının tek bir kişiye bağlı kalmaması.
Geliştirme liderliği: tek uygulama değil, birbirine bağlı dört yüzey
2yaka'nın admin paneli, durak paneli ve mobil uygulama geliştirme süreçlerini uçtan uca yönettim; tanıtım sitesini de aynı ürün dili ve edinim akışının parçası olarak geliştirdim. Bu çalışma yalnızca ekran üretmekten oluşmadı. Rol modelinden veritabanı ilişkilerine, mobil konum yaşam döngüsünden bildirim davranışına, web paneli yetkilerinden yayın ve migration disiplinine kadar katmanların aynı operasyon gerçeğini anlatmasını sağlamak gerekiyordu.
Şoför mobil uygulamada kendi durağını, sıra pozisyonunu ve rezervasyonlarını görüyor. Durak yöneticisi canlı kuyruğu, sürücüleri, davetleri, rezervasyonları, performansı ve geofence alanını yönetiyor. Süper admin ise duraklar, yöneticiler, başvurular, bildirimler, geri bildirimler ve platform ayarları üzerinde sistem geneli kontrol sağlıyor. Landing sitesi bu karmaşık ürünü iki ayrı kullanıcıya—şoföre ve durak sahibine—anlaşılır bir değer önerisiyle açıklıyor.
Mobil ana ekran dekoratif bir harita değil; sürücünün konumu, durak alanı, sıra ve çalışma durumu için canlı operasyon yüzeyi.
Şoför uygulaması: konum, sıra ve karar aynı ekranda
Mobil uygulamayı Expo SDK 53, React Native 0.79, React 19 ve Expo Router üzerinde geliştirdim. Ana ekranın görevi mümkün olduğunca nettir: sürücü hangi durağa bağlı olduğunu, müsait ya da meşgul durumunu, durak alanına olan ilişkisini ve gerçek sıra pozisyonunu tek bakışta görür. Kullanıcı gerektiğinde manuel olarak sıraya girip çıkabilir; geofence otomasyonu ise fiziksel alana giriş ve çıkışı algılayarak bu akışı destekler. Manuel kontrolü korumak bilinçli bir ürün kararıydı, çünkü konum izni, cihaz üreticisi, batarya optimizasyonu veya zayıf bağlantı hiçbir zaman operasyonun tek karar noktası olmamalıydı.
Uygulama telefon tabanlı kimlik doğrulama, onboarding, profil ve araç bilgileri, birincil ve ikincil durak üyelikleri, bildirim merkezi, sıra geçmişi, rezervasyon teklifleri ve ayar akışlarını aynı navigasyon sistemi içinde taşıyor. Zustand ve TanStack Query ile yerel/uzak state sınırlarını ayırdım; Secure Store ile oturum bilgisini, AsyncStorage ile gerekli yerel tercihleri yönettim. Haptic geri bildirim, native tarih-saat seçiciler, image picker, deep link ve pull-to-refresh gibi mobil davranışları ürün akışının doğal parçaları olarak ele aldım.
Çoklu durak modeli: sürücü bağlı olduğu durakları, her durağın canlı kuyruğunu ve kendi pozisyonunu görebiliyor.
Sıra motoru: görünür pozisyonun arkasındaki kurallar
Sıra, istemcinin ekrana yazdığı basit bir sıra numarası değil. Gerçek kaynak PostgreSQL tarafındaki aktif kuyruk sözleşmesi. Şoförün sıraya girişi join-queue, çıkışı leave-queue akışından geçiyor; aktif liste get_active_queue RPC üzerinden okunuyor. Pozisyon sabit bir kolon gibi saklanmak yerine aktif kayıtlar, öncelik ve giriş zamanı üzerinden yeniden hesaplanıyor. Böylece iki cihaz aynı anda işlem yaptığında ya da yönetici kuyruğa müdahale ettiğinde tüm istemciler aynı kaynağa dönebiliyor.
Sistemde manuel giriş, geofence girişi ve offline yeniden katılım gibi giriş yöntemleri ayrıştırılıyor; çıkış nedeni de kayıt altına alınıyor. Yönetici bir şoförü öne aldığında, arkaya gönderdiğinde veya sıradan çıkardığında bu işlem bir audit izi bırakıyor. Günlük queue session yapısı operasyon günlerini birbirinden ayırıyor. Çoklu durak üyeliği için driver_stations ilişkisi, sürücünün birincil durağını korurken başka duraklara da kontrollü biçimde katılmasına imkân veriyor. Buradaki asıl tasarım hedefi, her kullanıcı yüzeyinin aynı sıra gerçeğini göstermesi ve anlaşmazlık anında sistemin ne olduğunu açıklayabilmesiydi.
Rezervasyon yüzeyi teklif, bekleyen iş, zaman, yolcu sayısı ve konum bağlamını sürücünün çalışma akışına taşıyor.
Rezervasyon ve bildirimler: sıra dışındaki operasyonu da yönetmek
Ürün büyüdükçe yalnızca sıra yönetmek yeterli olmadı. Durak yöneticisinin yolcu rezervasyonu oluşturabildiği, bir sürücüye doğrudan atayabildiği veya uygun sürücülere teklif olarak yayınlayabildiği bir rezervasyon akışı geliştirdim. Sürücü mobil uygulamada teklifi görüyor, kabul veya reddediyor; sistem pending, offered, accepted, assigned, en-route, completed ve cancelled gibi durumları izliyor. Süresi içinde cevaplanmayan tekliflerin kapanması ve aynı sürücünün kısa aralıklarla tekrar tekrar rahatsız edilmemesi backend kurallarının parçası.
Bildirim sistemini de tek tip push mesajı olarak ele almadım. Kuyruğa katılma, sıra yaklaşması, sıra gelmesi, rezervasyon teklifi, rezervasyon hatırlatması ve genel duyuru farklı önem ve ses politikalarına sahip. Android kanal kimlikleri, foreground davranışı, persistent queue status ve turn alert gibi durumlar ayrı sözleşmelerle yönetiliyor. Bildirim aksiyonları uygulama arka plandayken riskli operasyonu doğrudan değiştirmiyor; ilgili ekranı açıp kullanıcıdan onay alıyor. Expo push ile mobil iletim, Supabase loglarıyla izlenebilirlik ve panelden gönderilen duyurular aynı yaşam döngüsünde buluşuyor.
Durak yöneticisi operasyon alanını harita üzerinde tanımlar; merkez, yarıçap ve çokgen geometri mobil konum davranışını besler.
Durak paneli: günlük operasyonun çalışma masası
Durak panelini Next.js 15 üzerinde, masaüstünde yoğun veri gösterebilen ama gerektiğinde telefondan da yönetilebilen bir operasyon aracı olarak geliştirdim. Panelde canlı pano, sıra yönetimi, sürücü listesi ve detayları, davet akışı, rezervasyonlar, bildirimler, performans, hesap ve ayarlar bölümleri bulunuyor. QR ve davet kodu ile sürücü katılımı; isim, telefon ve plaka üzerinden üyelik yönetimi; sıra müdahalesi ve sürücü durumları aynı durak bağlamında tutuluyor.
Geofence editörü bu panelin en kritik teknik yüzeylerinden biri. Yönetici durağın fiziksel konumunu, operasyon merkezini, yarıçapı veya çokgen alanı harita üzerinde tanımlayabiliyor. Bu veri yalnızca görsel bir ayar değil; mobil uygulamanın konum değerlendirmesini, otomatik giriş/çıkış davranışını ve saha raporlarını etkiliyor. MapLibre ile harita katmanlarını, PostGIS ile coğrafi veriyi ve durak bazlı yetki kontrolünü birleştirdim. Panel ayrıca PWA olarak cihaz ana ekranına kurulabiliyor; böylece küçük bir durak ofisindeki bilgisayar, tablet veya telefon aynı operasyon yüzeyine dönüşebiliyor.
Durak panelinin mobil çalışma hali: harita, geofence, aktif sıra sayaçları ve yönetim bölümleri küçük ekranda da erişilebilir.
Süper admin: tek durağı değil, platformu işletmek
Süper admin paneli durak yöneticisinin ekranının büyütülmüş hali değil; farklı bir karar yüzeyi. Burada platform geneli KPI ve harita görünümü, durak listesi ve detayları, yeni durak oluşturma, şoförler, yöneticiler, başvurular, raporlar, bildirimler, geri bildirimler ve platform ayarları yer alıyor. Durakları arama, filtreleme ve durumuna göre ayırma; yönetici atama; üyelikleri inceleme; başvuruları onaylama veya reddetme ve duyuru göndermek bu katmanda toplanıyor.
Admin ile durak paneli arasındaki sınırı özellikle korudum. Durak yöneticisi yalnızca yetkili olduğu operasyon alanını görürken süper admin cross-station veriyle çalışıyor. Bu yüzden UI farklılığı kadar veri erişimi de rol ve tenant bağlamına dayanıyor. Bir durak kaydı soft-delete edildiğinde yalnızca ana satırı saklamak yeterli değil; aktif yönetici bağlantıları, sürücü üyelikleri, açık kuyruk kayıtları, oturumlar ve bekleyen talepler de tutarlı şekilde kapanmalı. Bu tür yaşam döngülerini yalnızca ekrandaki butona bırakmayıp veritabanı sözleşmeleri ve migrationlarla güvence altına aldım.
Backend: aynı gerçeği paylaşan çok kiracılı sistem
Backend Supabase üzerinde PostgreSQL, Auth, Realtime, Storage ve Edge Functions bileşenlerini birlikte kullanıyor. Temel model stations, profiles, drivers, vehicles, driver_stations, station_managers, queue_sessions, queue_entries, reservations, driver_locations, invitations, notifications ve audit tabloları etrafında kuruluyor. Şoför ve yönetici aynı profile sahip olabilir ama farklı üyelik ilişkileri üzerinden yetki kazanır; bu ayrım özellikle bir kişinin birden fazla durakta veya birden fazla rolde bulunabildiği gerçek dünya senaryoları için önemliydi.
Join/leave, rezervasyon aksiyonları, davet işleme, SMS/push iletimi, konum kontrolü ve yönetici sıra müdahaleleri Edge Function veya güvenli RPC sınırlarından geçiyor. RLS politikaları veriyi station_id ve aktif üyelik bağlamında izole ediyor. Soft delete, audit log, telefon ve plaka normalizasyonu, atomic rate limiting, fail-closed CORS ve input validation gibi kararlar ürünün yalnızca demo verisiyle değil gerçek kullanıcı ve operasyon verisiyle çalışabilmesi için eklendi. En zor kısım tablo sayısını artırmak değil, her mutasyonun Auth, profil, araç, üyelik ve sıra ilişkileri arasında yarım kalmadan tamamlanmasını sağlamaktı.
Realtime mimarisi: hız kadar tutarlılık ve yük kontrolü
Kuyruk değişikliği mobil uygulamaya, durak paneline ve admin görünümüne gecikmeden yansımalı; fakat her ekranın ayrı sorgu ve kanal açması üretim yükünü hızla büyütebilir. Realtime katmanında station tabanlı kanallar, TanStack Query invalidation ve aktif kuyruk RPC sözleşmesini birlikte kullandım. WebSocket kanallarını yüzey başına çoğaltmak yerine birleştirmek, mobilde duplicate subscription açılmasını engellemek ve gerektiğinde broadcast kullanmak aynı olayın gereksiz yere tekrar işlenmesini azalttı.
Bu mimaride Realtime tek başına doğruluk kaynağı değil; istemciyi değişiklikten haberdar eden taşıma katmanı. Bağlantı koptuğunda veya uygulama foregrounda döndüğünde istemci aktif kuyruğu yeniden okuyarak kendini toparlıyor. Bu ayrım gerçek cihaz davranışında kritik oldu. Özellikle Android üreticilerinin arka plan kısıtları, zayıf bağlantı, eski uygulama sürümleri ve Supabase schema cache gibi konular kağıt üzerindeki mutlu akıştan farklı sonuçlar üretebiliyor. Ürünü geliştirirken cihaz, web, veritabanı ve deployment doğrulamasını birbirinden ayrı kanıt katmanları olarak ele aldım.
Test, yayın ve üretim operasyonu
2yaka yalnızca feature geliştirdiğim bir proje olmadı; release ve production işletimini de yönettiğim bir sistem oldu. Monorepo Turborepo ve pnpm workspaces ile landing, admin, durak, mobile ve ortak paketleri aynı sözleşme altında tutuyor. TypeScript kontrolleri, web production buildleri, mobil unit testleri, API ve güvenlik testleri, Android cihaz kontrolleri, migration drift kontrolleri ve release preflight adımları birbirinden ayrı çalışıyor. Bir Git push, veritabanı migrationı, Realtime publication, Vercel deployu ve mağaza buildi aynı şey değil; her birini kendi çıktısıyla doğrulamak gerekiyor.
Mobil tarafta Android AAB ve iOS release hazırlığı; web tarafında Vercel projeleri ve özel domainler; backend tarafında Supabase migration ve Edge Function yayınları ayrı operasyon akışları. Konum ve bildirim gibi cihaz bağımlı özelliklerde emülatör çıktısını yeterli görmeyip gerçek Android cihazlarda uzun süreli test ve bildirim davranışı kontrolleri yaptım. Üretimde eski istemcileri bozabilecek backend değişikliklerinde yeni mobil build beklemek yerine, mümkün olduğunda geriye uyumlu ve hedefli server-side düzeltmeler geliştirdim.
Ürünü anlatmak da sistem tasarımının parçasıydı
Tanıtım sitesini genel bir SaaS vitrini gibi değil, iki farklı kullanıcı grubunun gerçek itirazlarına cevap veren bir ürün yüzeyi olarak geliştirdim. Şoför tarafında sıra pozisyonu, geofence, bildirim ve geçmiş; durak tarafında canlı operasyon, sürücü yönetimi, davet ve raporlama anlatılıyor. Ana sayfa bu iki tarafı aynı vaat altında birleştiriyor: kağıt defter ve belirsizlik yerine görünür, adil ve yönetilebilir bir durak düzeni.
Canlı site; ürün sayfaları, indirme akışı, durak başvurusu, iletişim, blog, gizlilik, kullanım şartları ve KVKK yüzeylerini içeriyor. Mobil uygulama ekranları ve durak paneli görselleri doğrudan ürünün kendisinden geliyor. Bu sayede pazarlama katmanı soyut vaatler yerine çalışan arayüzü gösteriyor. 2yaka benim için product strategy, UX, mobil mühendislik, web uygulamaları, backend, saha operasyonu ve release yönetiminin tek projede kesiştiği en kapsamlı ürün sistemlerinden biri oldu.
Bugünkü durum ve öğrendiğim en önemli şey
2yaka.net bugün canlı. Portfolyo için bu vaka çalışmasını hazırlarken ana siteyi, aktif repo yapısını, mobil ekranları, durak paneli yüzeylerini, backend fonksiyonlarını ve test dizinlerini yeniden inceledim. Çalışmanın ölçeği tek bir uygulama dosyasından değil; sürücü ve yönetici akışlarını aynı veritabanı gerçeğinde buluşturan ürün kararlarından geliyor.
Bu proje bana saha yazılımının yalnızca güzel ve hızlı bir arayüz olmadığını öğretti. Gerçek ürün; konum izni reddedildiğinde, telefon uykuya geçtiğinde, şoför iki durağa bağlı olduğunda, yönetici yanlış kişiyi çıkardığında, eski bir istemci yeni şemaya bağlandığında veya bir deployment kaynak kodun gerisinde kaldığında da tutarlı davranmalı. 2yaka'da yönettiğim geliştirme süreci tam olarak bu katmanların tamamını kapsadı: problemi tanımlamak, ürünü tasarlamak, kodlamak, yayınlamak, üretimde izlemek ve gerçek davranışa göre tekrar düzeltmek.
