Randevu platformu

01Sorun

Hizmet işletmeleri randevuyu telefonla ajanda arasındaki boşlukta kaybediyor. Bu platformda aynı çekirdek, yalnızca ayarla her sektöre uyuyor.

Hazır randevu ürünleri ya tek bir sektörü varsayıyor ya da her işletmeyi aynı hizmet kataloğuna, aynı personel modeline ve aynı çalışma saatlerine sığdırmaya çalışıyor. Hiçbiri gerçek bir salonun ya da kliniğin işleyişine uymuyor.

02Yaklaşım

Alan modeli her sektör için kopyalanmadı; bir kez kurulup ayarlanabilir yapıldı. Her işletme kendi hizmetlerini, personelini, çalışma saatlerini ve kurallarını kendisi tanımlıyor. İlk olarak güzellik merkezleri için devreye alındı; aynı çekirdek klinik, diyetisyen, fizyoterapist ve danışmanlık işlerine de uyarlanabiliyor.

03Çözüm

Sürümlü bir REST API ve aynı kod tabanından Android'de ve tarayıcıda çalışan bir Flutter istemcisi. Müşteri telefon numarası ve tek kullanımlık kodla giriyor, ilçeye ya da konuma göre arıyor ve personelin gerçek müsaitliğine göre randevu alıyor.

• Her işletme kendi kuralıyla

  Hizmetler, personel, çalışma saatleri ve kurallar işletme bazında tanımlanıyor; salon da klinik de aynı çekirdeği kullanıyor.

• Telefon numarasıyla giriş

  Tek kullanımlık kod ve kısa ömürlü erişim jetonlarıyla doğrulama.

• Gerçek müsaitlik

  Randevu, personelin takvimine göre denetleniyor.

• Yakındakini bul

  İlçeye ya da konuma göre arama.

• Paylaşılan API sözleşmesi

  İstemci, API sözleşmesinden üretiliyor; desteklenmeyen istemci sürümü açıkça reddediliyor.

• Tek komutla demo

  Veritabanı, nesne deposu, göçler, örnek veri ve API tek adımda ayağa kalkıyor.

04Ekranlar

Müşterinin telefonunda gördükleri. Demo işletme, demo veri.

1. 01Ana ekran

   Onay durumuyla bir sonraki randevu; altında uygulamayı açma sebebi olan iki şey: yeniden randevu almak ya da paketinde kaç seans kaldığına bakmak.

   
2. 02Beş adımda randevu

   Merkez, hizmet, uzman, tarih, onay: müşterinin karşısına her şeyi bir anda soran bir form çıkmıyor. Hizmetler kendi süresini ve fiyatını taşıyor, çünkü kataloğu her işletme kendisi tanımlıyor.

   

05Nasıl kurdum

Bir API, bir sözleşme, iki platformda tek istemci.

NestJS ve TypeScript

Node.js 22 üzerinde tek depo: API ve istemciyle paylaşılan sözleşme paketi yan yana.

Prisma ve PostgreSQL

Göçler ve örnek veri, API ayağa kalkmadan önce sıralı bir konteyner adımı olarak çalışıyor.

Flutter

API sözleşmesinden üretilen istemci; tek kod tabanından Android ve web.

Docker ve testler

Bütün yığın Docker Compose ile, dosyalar S3 uyumlu depoda (geliştirmede MinIO). Lint, tip denetimi, birim, uçtan uca ve kiracı yalıtımı testleri ayrı komutlar.

06Zor kısımlar

1. Yalıtım varsayılamaz

   Bir işletmenin verisinin ötekine görünmediği kanıtlanmalıydı. Normal testlerin yanında ayrı bir kiracı yalıtımı test paketi çalışıyor.

2. İstemci ve sunucu ayrı hızda

   Uygulama mağazadan güncellenene kadar eski sürüm kullanımda kalıyor. Bu yüzden API desteklemediği sürüme belirsiz bir hata vermiyor, açıkça reddediyor.

3. Terminalsiz gösterebilmek

   Ürünü geliştirme makinesinin dışında, telefonda ve terminal olmadan gösterebilmek gerçek bir gereksinimdi; betikli başlatıcılar ve yerel bir sürüm derlemesiyle çözüldü.

07Bugün

MVP yirmi günlük plana karşı tamamlandı ve API sözleşmesi v0.1'de donduruldu. Test durumu ve günlük ilerleme depo dokümantasyonunda takip ediliyor.