Seyahat Giderlerini Paylaşmak İçin Mobil Uygulama Nasıl Oluşturulur?

Sorun ve Hedef Kullanıcılarla Başlayın

Ekran tasarlamaya veya teknolojiyi tartışmaya başlamadan önce, uygulamanın kimlere hizmet ettiğini ve hangi anları iyileştirmesi gerektiğini acımasızca netleştirin. Gider bölüşmek “basit” görünür; ta ki gerçek bir gezi karışık para birimleri, yarı ödenmiş akşam yemekleri ve kaybolan bir fiş ekleyene kadar.

Bu uygulama kimler için?

Çoğu seyahat gider paylaşım uygulaması birkaç tekrarlanabilir kullanıcı grubuna hitap eder. Önce bir ana grup seçin (sonra genişletebilirsiniz):

• Grup gezisindeki arkadaşlar; yemek, yolculuk ve biletler için sırayla ödeme yaparlar
• Çiftler; tatili muhasebeye çevirmeden adil paylaşım isterler
• Aileler; ebeveynler önden öder ve sonra uzlaştırır
• Takımlar (spor kulüpleri, iş gezileri) şeffaflık ve dışa aktarma ister

Her grubun beklentileri farklıdır. Arkadaşlar hız ve hafif bir ton isteyebilir; ekipler denetlenebilirlik, izinler ve dışa aktarım-ready kayıtlar talep edebilir.

Tasarlanacak gerçek acı noktaları

Kullanıcıların şikâyet ettiği en karmaşık durumları belgeleyin:

• Dengesiz ödemeler: biri oteli ayarlar, diğerleri yemeği ve ulaşımı karşılar
• Her yerde fişler: kağıt slipleri, e-postalı faturalar, ekran görüntüleri
• Nakit vs kart: birisi nakit, diğeri kartla öder; bahşişler unutulur
• Para birimleri: döviz kurları değişir, dönüşümler farklı yapılır, yuvarlama tartışma yaratır
• “Ben o yemekte yoktum”: bir giderde kimlerin katıldığına dair anlaşmazlıklar

Bunları 5–10 röportaj gibi gerçek insanlarla test edebileceğiniz senaryolara dönüştürün.

Başarı kriterlerini tanımlayın (daha iyi ne demek?)

İlk sürümünüz için ölçülebilir hedefler koyun:

• Gider ekleme süresi: örn. kilidi açıp kaydetmeye kadar 20 saniyenin altında
• Daha az anlaşmazlık: trip başına daha az düzenleme/iptal, “kimin ne borcu?” mesajlarının azalması
• Açıklık: her giderde ödeyen, katılanlar, bölüşme yöntemi ve açıklama görünür

Bu kılavuzun yaklaşımı

Bu yazı fikir ve MVP tanımından kenar durumlara, UX akışlarına, izinlere, veri mantığına ve son olarak test ve lansmana kadar pratik, uçtan uca bir yol haritasıdır. Doğru kullanıcılar ve sorunlarla başlarsanız, sonraki her karar kolaylaşır.

MVP'yi Tanımlayın: İlk Sürümün Yapması Gerekenler

Seyahat gider paylaşım uygulaması için bir MVP “daha küçük bir uygulama” değil; kullanıcının seyahatteki tek işini güvenilir şekilde yapan bir versiyonudur: ortak harcamaları yakalamak ve kimin ne kadar borçlu olduğunu gösterip tartışma çıkarmamak.

MVP hedefleri (ilk sürümün yapması gerekenler)

Kapsamı sıkı ve sonuç odaklı tutun. Güçlü bir ilk sürüm sadece şu yeteneklerle başarılı olabilir:

• Gezi oluştur: isim, tarih opsiyonel, varsayılan para birimi
• Üye ekle: en azından isimle; davetler zamanla eklenebilir
• Gider ekle: tutar, kim ödedi, kim katıldı, opsiyonel not/kategori
• Kişi başı bakiyeleri görme: “sana borçlu / sen borçlusun”
• Ödeme kaydetme (settle up): “Alex Sam'e $40 ödedi” gibi basit bir kayıtla bakiyeyi azaltma

Bu beş işi sorunsuz yapabiliyorsanız, kullanıcıların bir geziyi bitirebileceği bir gider bölüşme uygulamanız var demektir.

Ertelemeye karar verilecekler

Birçok özellik “zorunlu” gibi görünür fakat çekirdek akışı doğrulana kadar bekleyebilir:

• Tam muhasebe raporları ve karmaşık dışa aktarmalar
• Gelişmiş vergi/KDV kuralları, yevmiye mantığı veya iş gideri uyumluluğu
• Karmaşık roller ve izinler (temel üye erişimi dışında)
• Derin otomasyon (fiş OCR, banka senkronizasyonu) ve zengin analizler

MVP hız ve açıklığı tamamlıktan önce tutmalıdır.

Basit kullanıcı hikâyeleri (teknik olmayan)

Hikâyeleri herkesin değerlendirebileceği günlük dille yazın:

• “Yemeği ben ödedim; dörtümüz arasında bölüştür.”
• “Taksi paylaştık ama Pat binmedi—Pat'ı hariç tut.”
• “Hemen şimdi kimin ne borcu olduğunu görmek istiyorum.”
• “Sam bana geri ödedi; işaretleyip toplamların güncellenmesini istiyorum.”

Kabul kriterleri: ‘tamam’ ne demek?

Her hikâye için somut kontroller tanımlayın. “Yemeği böl” için örnek:

• Kullanıcı 30 saniyenin altında tutar, ödeyen, katılımcıları girebilmeli.
• Uygulama her kişinin bakiyesini hemen ve tutarlı şekilde güncellemeli.
• Gider düzenlenip silindiğinde bakiyeler doğru yeniden hesaplanmalı.

Bu, kapsam kaymasını önlerken insanların güveneceği bir seyahat gider uygulaması inşa etmenizi sağlar.

Seyahat Gider Paylaşımı için Temel Özellikler

Bir seyahat gider paylaşım uygulaması, grubun harcamayı hızlıca yakalamasını ve matematiğe güvenmesini sağladığında başarılı olur. “Güzel özellikler” eklemeden önce, çekirdek özellik setinin gerçek gezilerde nasıl çalıştığını karşıladığından emin olun: birden çok kişi, birçok küçük harcama ve sıkça “sonra hallederiz” anları.

Geziler ve gruplar

Kullanıcılar birden çok gezi oluşturabilmeli (örn. “Lizbon 2026”) ve basit bir link ya da kod ile başkalarını davet edebilmeli. Katılan biri üye olur ve giderlere eklenebilir.

Üye yönetimini hafif tutun: isim değiştir, erken ayrılanı çıkar, istersen roller (admin vs üye) ekleyin.

Giderler: önemli minimum detaylar

Her gider, haftalar sonra bile faydalı kalacak kadar yapı içermeli:

• Tutar ve para birimi
• Kim ödedi (ödeyen)
• Kim katıldı (katılımcılar)
• Kategori (yemek, ulaşım, konaklama, etkinlik)
• Notlar (opsiyonel)
• Tarih/saat (varsayılan “şimdi”)
• Konum (opsiyonel; hafıza için faydalı)

Hızlı giriş, mükemmel veriden daha önemlidir. Akıllı varsayılanlar (son ödeyen, son katılımcılar) dokunma sayısını azaltır.

Kullanıcıların beklediği bölüşme tipleri

Eşit bölüşme varsayılan olmalı, ancak esneklik sunun:

• Eşit paylaşım
• Özel tutarlar (ör. Alex ekstra ödedi)
• Yüzdeler (ör. %70/%30)
• Paylar (ör. yetişkin 2 pay, çocuk 1 pay)
• Hariç tutmalar (ör. “Sam içmedi, hariç tut”)

Bakiyeler ve özetler

Uygulama her zaman “kim kime ne kadar borçlu?” sorusuna cevap vermeli. Kişi başı toplamlar, gezi toplamı ve borçların otomatik olarak netlendiği net bakiye görünümü sunun (ki kullanıcılar çok küçük transferler için peşinde koşmasın).

Ödemeler (settle up)

Kullanıcıların geri ödemeleri kaydetmesine izin verin: ödemeyi işaretle, tutarı/tarihi sakla ve isteğe bağlı yöntem (nakit, banka transferi, PayPal) belirtme. Güvence için kanıt eklemeye (ekran görüntüsü veya not) izin verin ama opsiyonel tutun; böylece kapatma hızlı olur.

Çoklu Para Birimi, Yuvarlama ve Gerçek Dünya Kenar Durumları

Çoklu para birimi, gider bölüşme uygulamalarında sihirli ya da tartışma çıkaran noktalardan biridir. Her sayının hangi para birimini temsil ettiğini ve nasıl dönüştürüldüğünü açık tutarak çoğu “ben daha fazlasını ödedim” anını önleyebilirsiniz.

İşlem para birimi vs gezi “ana” para birimi

Her gideri bir işlem para birimi (mağazada gerçekte ödenen) ve bir gezi ana para birimi (grubun toplamları karşılaştırdığı) olarak ele alın.

Örneğin: bir akşam yemeği €60 (işlem), ama gezi ana para birimi USD ise uygulama €60 → $65.40 (dönüştürülmüş) gösterirken orijinal €60’ı şeffaflık için saklar.

Bir döviz kuru stratejisi seçin (ve gösterin)

İki iyi seçenek genelde şöyle:

• Giriş anında sabit: gider eklendiğinde kullanılan kuru saklayın. Bu stabil ve denetlenebilir.
• Günlük güncellemeler: çevrilmiş tutarları günlük kur ile yeniden hesaplayın. Uzun geziler için faydalı olabilir ama toplamların değişmesi sürpriz yaratabilir.

Hangi yolu seçerseniz seçin, gider detaylarında kur ve zaman damgasını gösterin (örn. “1 EUR = 1.09 USD • 2025-12-26”). Düzenlemeleri destekliyorsanız, kullanıcıların gider bazında kur kilitlemesine izin verin.

“Kuruş” anlaşmazlıklarını önleyecek yuvarlama kuralları

Yuvarlama bir detay değil—politika meselesidir. Tutarlı kurallar kullanın:

• Kişi başı payı ana para biriminin en küçük birimine (örn. kuruş) yuvarlayın.
• Kalan farkı deterministik olarak birine atayın (ör. ödeyen veya en büyük paya sahip kişi) ve küçük bir “yuvarlama düzeltmesi” satırı gösterin.

Nakit, kart ve karışık ödemeler

Destekleyin:

• Nakit: nakit ödeyen kişi ödeyendir.
• Kart: ödeyen kart sahibi kabul edilir.
• Karışık: tek bir gideri birden fazla ödemeyle bölme (örn. $40 kart + $10 nakit) ve toplamı katılımcılar arasında bölme.

Bahşiş, servis ücreti ve indirimler

Bunları ya ayrı kalemler olarak modelleyin (en açıklayıcı yöntem) ya da giderle ilişkilendirilmiş ayarlamalar olarak. Böylece sadece bazı kişilerin bahşişe katılması veya indirimin belirli öğelere uygulanması kolay olur.

UX ve Ekran Akışı: Gider Eklemeyi Hızlı Yapın

Bir seyahat gider uygulaması hızıyla kazanır veya kaybeder. İnsanlar takside, kuyrukta veya gürültülü restoranlarda maliyetleri kaydeder—akışınız bir not almak gibi hissettirmeli, form doldurmak gibi değil.

Ana ekranları eşleyin (ve tahmin edilebilir tutun)

Kullanıcıların bir gezide öğrenebileceği küçük ekran setiyle başlayın:

• Gezi listesi: aktif geziler önde, arşivlenenler aşağıda
• Gezi detayları: özet toplamlar, kimlerin olduğu ve basit bir etkinlik akışı
• Gider ekle: “kaydet”e en hızlı yol
• Gider detayları: girilenler, kim ödedi, kimlerin borçlu olduğu ve düzenleme geçmişi
• Bakiyeler: kişi bazlı net pozisyon ve “sonraki ne yapmalıyım?” ipucu
• Ödeme kaydetme: ödemeleri kaydet ve kişileri kapat

Gider girişini gerçekten hızlı yapın

“Gider ekle” ekranını akıllı varsayılanlar etrafında tasarlayın:

• Para birimini geziye göre ön-doldurun, tek dokunuşla değişime izin verin.
• Son kullanılan bölüşmeyi hatırlayın (eşit, paylar, yüzdeler) ve yeniden kullanın.
• Hızlı katılımcı geçişleri sunun (avatarlara dokunarak dahil/ hariç bırak).
• Ödeyeni varsayılan olarak mevcut kullanıcıya ayarlayın; genelde doğru olan budur.

İyi bir kural: kullanıcı sık kullanılan bir gideri 10–15 saniyede kaydedebilmeli.

Açık dil kullanın ve kaydetmeden önce onaylayın

Belirsiz etiketlerden kaçının. “Paid by” yerine “Ödeyen” ve “Owed by” yerine “Borçlu” gibi net terimler hata oranını düşürür. Kaydetmeden önce kompakt bir onay satırı gösterin: tutar, ödeyen ve kimlerin dahil olduğu.

Eğer sıra dışı görünüyorsa (örn. sadece bir kişi borçlu), nazikçe sorun: “Sadece Alex ile mi bölüştürülsün?”

Grup açıklığı için tasarlayın

Gezi detayları hızlı kontrolleri desteklemeli: filtreler (kişi, kategori, tarih) ve kişi bazlı görünüm. Bir etkinlik akışı (activity feed) güven oluşturur, özellikle düzenlemeler yapıldığında.

Yolda işe yarayan temel erişilebilirlik

Okunabilir kontrast, büyük dokunma hedefleri ve açık çevrimdışı göstergeler (“Cihazda kaydedildi—sonra senkronize edilecek”) kullanın. Seyahat koşulları öngörülemez; UI buna göre dayanıklı olmalı.

Hesaplar, Davetler ve İzinler

Bir seyahat gider paylaşım uygulamasının ömrü, grubun aynı geziye ne kadar hızlı girebildiğine bağlıdır. Hesap ve davet kararlarınız sürtünmeyi azaltmalı.

MVP ile eşleşen bir oturum açma yaklaşımı seçin

MVP için genelde en basit ama güven veren seçenek istenir:

• Sadece davet ile sihirli link: en hızlı onboarding, parola sorunlarını azaltır.
• Apple/Google ile giriş: çoğu kullanıcı için pürüzsüzdür.
• E-posta + parola: inşa etmesi daha zahmetli ama bazı hedef kitleler için gerekli olabilir.

Pratik bir uzlaşma: Apple/Google + sihirli link. Hesap istemeyenler davetle katılabilir; düzenli kullanıcılar sonra gerçek bir oturum bağlayabilir.

Davetler: önce link, sonra QR, kişiler opsiyonel

İlk olarak paylaşılabilir bir davet linki sunun; kişi doğrudan geziye katılabilsin. Yüz yüze anlar için QR kodu ekleyin (tren platformu, hostel check-in). Kişi listesinden davet etme hoş ama izin talepleri ve kenar durumlar ekler—erken aşamada sıklıkla değmez.

Davetleri zaman sınırlı yapın:

• Linkleri makul bir süre sonra (veya ilk kullanımdan sonra) süresi dolacak şekilde ayarlayın.
• Adminlerin bir linki iptal/yenilemesine izin verin.

Hesapsız misafirler: mümkün ama kontrollü olsun

Gruplarda bazıları uygulama yüklemeyecek veya oturum açmayacaktır. Destekleyip desteklemeyeceğinize baştan karar verin:

• Misafir katılımcılar: oturum yok; bölüşümlere dahil edilebilir ama erişimleri sınırlıdır.
• İsimsiz üyeler: daha sonra “sahiplenilebilecek” bir yer tutucu isim.

Yaygın bir MVP kuralı: misafirler yalnızca davet linki üzerinden görüntüleyip gider ekleyebilir, ancak silme veya gezi ayarlarını değiştirme gibi yetkiler yoktur.

İzinler: para söz konusu olunca sürprizlere yer yok

Kim neyi düzenleyebilir açık olmalı:

• Trip admin: geziyi yeniden adlandırabilir, üyeleri yönetebilir, davetleri iptal edebilir, her gideri silebilir.
• Paylaşılan sahiplik (önerilen): herkes gider ekleyebilir; sadece oluşturucu (veya admin) gideri düzenleyip silebilir.

Bu, kasıtlı veya kazara değişiklikleri önlerken akışı hızlı tutar.

Çakışmalar: iki kişi aynı gideri düzenlerse?

Gerçek gruplar hızlı hareket eder. Düzenlemeleri öngörülebilir yapın:

• Son kaydeden kazanır kuralı ve görünür “Alex tarafından 2 dk önce düzenlendi” izi.
• Hafif bir değişiklik geçmişi ekleyin (son birkaç revizyon olsun) ki hatalar geri alınabilsin.
• Bir gider düzenlenirken, editör açtığında değiştiyse hafif bir uyarı gösterin.

Amaç mükemmel versiyon kontrolü değil—tartışmaları önlemek ve gezinin akmasını sağlamak.

Veri Modeli ve Gider Bölüşme Mantığı

Temiz bir veri modeli uygulamanızı öngörülebilir kılar: her ekran, hesaplama, dışa aktarma ve senkronizasyon buna bağlıdır. Onlarca tabloya gerek yok—doğru yapı taşları ve açık kurallar yeter.

Temel varlıklar (ölçeklenen minimum)

Pratik olarak genelde şunlar gerekir:

• User: profil, varsayılan para birimi, opsiyonel ödeme bilgileri
• Trip: isim, tarihler, temel para birimi, durum (açık/kapalı)
• Membership: Kullanıcıları Trip'e bağlar (rol, davet durumu, izinler)
• Expense: kim ödedi, ne zaman, nerede, para birimi, toplam tutar, kategori, notlar
• Split: giderin nasıl paylaştırıldığı (eşit, pay, yüzde, özel tutarlar)
• Settlement: uygulamada kaydedilen para transferleri (kimden kime, ne kadar, yöntem)
• ExchangeRate: gider anında kullanılan kur (kaynak, zaman damgası)

Değiştirilemez vs düzenlenebilir geçmiş (audit trail vs sadelik)

Düzenlemeler birçok uygulamayı karıştırır. İki yaklaşım:

• Değiştirilemez kayıtlar (audit trail): Expense hiçbir zaman üzerine yazılmaz; düzeltme kaydı oluşturulur. Anlaşmazlıklar için iyidir ama UI'yi karmaşıklaştırır.
• Düzenlenebilir kayıtlar (basit): Expense yerinde düzenlenir. MVP için daha kolaydır; yine de updated_at, updated_by ve para etkileyen alanlar için hafif bir değişiklik günlüğü saklayın.

Orta yol: düzenlemeye izin verin ama para etkileyen alanlar için hafif bir geçmiş tutun.

Bakiye hesaplama ve netleme (transferleri en aza indirin)

Bakiye hesaplaması:

• Her gider için: her katılımcı kendi payını borçlu olur.
• Ödeyen kişi ödediği toplam tutar kadar kredi alır.
• Net bakiye = kredi − borç. Pozitifse “alacaklı”; negatifse “borçlu”.

Sonra yerleşimler için netleme yaparak borçluları alacaklılarla eşleştirip minimum transfer sayısını üretin.

Örnek: 3 kişi, 4 gider

Gezi üyeleri: Alex (A), Blair (B), Casey (C). Tüm bölüşmeler dahil olanlar arasında eşit.

1. Akşam yemeği $60, A ödedi (A,B,C) → kişi başı $20

2. Taksi $30, B ödedi (B,C) → kişi başı $15

3. Müze $45, C ödedi (A,C) → kişi başı $22.50

4. Market $90, A ödedi (A,B,C) → kişi başı $30

Net sonuçlar:

• A: ödedi 150; borcu 72.50 → +77.50
• B: ödedi 30; borcu 65.00 → −35.00
• C: ödedi 45; borcu 87.50 → −42.50

Yerleşimler (netlenmiş): B → A $35.00, C → A $42.50.

Ekler: fiş saklama + meta veri

Fişleri Expense'e bağlı ekler olarak ele alın: bir image URL/object key, küçük önizleme, uploaded_by, created_at ve opsiyonel OCR meta verisi (mağaza, algılanan toplam, güven).

Gideri resim yüklenirken veya çevrimdışıyken kullanılabilir kılmak için ek kaydını ana gider alanlarından ayırın.

Teknoloji Yığını ve Uygulama Mimarisi Seçimi

Teknoloji seçimleriniz, inşa etmek istediğiniz ürüne hizmet etmeli: hareket halindeyken hızlı, spotty bağlantıda çalışabilen ve herkesin bakiyesini tutarlı tutan bir paylaşılan gezi cüzdanı.

Hızlıca spec'ten çalışır bir uygulamaya geçmek istiyorsanız, planlama ve uygulamayı kısaltan araçlar yardımcı olabilir. Örneğin, Koder.ai gibi platformlarda akışları sohbetle tanımlayıp (geziler, giderler, bakiyeler, settle-up) bir uygulama yığını (React web, Go + PostgreSQL backend, Flutter mobil) üretebilirsiniz. Bu ürün kararlarının yerine geçmez ancak MVP'ye ulaşma süresini kısaltabilir ve güvenli yineleme için snapshot/rollback sunabilir.

Platform stratejisi: native, çapraz-platform veya web-öncelikli

En sorunsuz kamera, çevrimdışı depolama ve OS entegrasyonları için native iOS (Swift) ve Android (Kotlin) ideal—ancak iki kod tabanı maliyeti vardır.

Çoğu ekip için çapraz-platform (Flutter veya React Native) pratik bir orta yol: tek bir UI katmanı, hızlı yineleme ve iyi performans.

Web-öncelikli (responsive web app) hızla doğrulama sağlar ama çevrimdışı ve fiş yakalama genelde daha az pürüzsüz hissedilir.

Backend ihtiyaçları: senkronizasyon, gerçek zamanlı güncellemeler, bildirim, depolama

Basit bir gezi cüzdanı bile backend'ten faydalanır:

• Hesap ve davet yönetimi
• Bulut senkronizasyonu (herkes güncellemeleri görsün)
• Gerçek zamanlı güncellemeler (WebSockets veya canlı sorgular)
• Push bildirimleri (“Alex bir akşam yemeği ekledi”)
• Fiş resimleri ve dışa aktarmalar için depolama

İlk günden çevrimdışı-öncelikli planlayın

Çevrimdışı takip bir eklenti değil. Yerel veritabanı (SQLite/Realm) kullanın ve şu tasarımları uygulayın:

• Geziler/giderlerin yerel önbelleği
• Bekleyen değişiklikler kuyruğu (oluştur/düzenle/sil)
• Çakışma yönetimi (son yazma kazanır veya alan bazlı birleştirme), artı açık kullanıcı mesajları

API'leri zihinsel modele göre tasarlayın

Endpointleri basit ve tahmin edilebilir tutun:

• /trips, /trips/{id}/members
• /trips/{id}/expenses
• /trips/{id}/balances
• /trips/{id}/settlements

Bu yapı gider bölüşme algoritması ve gelecekteki özelliklerle (ödeme linkleri, çoklu para birimi takibi) uyumlu.

Basit bir mimari diyagramı (uygulama rehberi olarak)

Mobile App (UI)
  -\u003e Local DB + Sync Queue
  -\u003e API Client
       -\u003e Backend (Auth, Trips, Expenses, Balances)
            -\u003e Database
            -\u003e File Storage (receipts)
            -\u003e Notifications

Bu diyagramı geliştirme sırasında görünür tutun—“hızlı düzeltmeler”in MVP'yi karmaşıklaştırmasını önler.

Fişler, Fotoğraflar ve Yararlı Otomasyon

Fişler “doğru olduğunu düşünüyoruz”dan “biliyoruz”a geçmeyi sağlar. Özellikle nakit ödemeler, ortak kart kullanımı veya farklı para birimleri olduğunda tartışmaları azaltır.

Fiş yakalama, kullanıcıyı yavaşlatmamalı

Fiş eklemeyi gider eklemenin bir parçası gibi hissettirin: kamera aç → çek → hızlı kırp/döndür → giderle ilişkilendir. Akış basit olmalı.

Birkaç pratik detay:

• Kamerayı hızlı ve güvenilir yapın (anında açılma, düşük ışıkta iyi varsayılanlar).
• Basit bir kırp aracı, “Yeniden çek” ve “Atla” seçenekleri sunun.
• Hız için hafif bir önizleme, detaylar için tam çözünürlük saklayın.

Opsiyonel OCR (kullanıcı onayıyla)

OCR faydalı ancak güvenilir olmalı. Toplam tutar ve satıcı gibi alanları öneri olarak çıkarın; kaydetmeden önce hızlı kullanıcı onayı isteyin.

İyi bir desen: çıkarılan değerleri düzenlenebilir chipler olarak gösterin (örn. “Toplam: 42.80”, “Satıcı: Café Rio”) ve kullanıcıların düzeltmesine izin verin. OCR başarısız olsa bile kullanıcı birkaç saniyede kaydı tamamlayabilmeli.

Akıllı varsayılanlar: zaman ve konum

Tarih/saat cihazdan otomatik alınsın ve mümkünse konum (şehir veya mekan) önerilsin. Her zaman düzenlemeye izin verin—insanlar gideri sonra kaydedebilir.

Rahatsız etmeyen bildirimler

Aşağıdaki durumlar için bildirim kullanın:

• Yeni gider eklendi (özellikle paylaşılan bakiyeyi etkiliyorsa)
• Ödeme talebi (birisi kapatmak istiyor)
• Gezi kapandı (düzenleme için tekrar açılması gerekir)

Fişler için gizlilik kontrolleri

Fişler telefon numarası, sadakat ID'si, imza veya kısmi kart numarası içerebilir. Basit bir anahtar sunun: fişi katılımcılarla paylaş veya yalnızca rakamları paylaş. Bu, güveni korur ama grubu takibi engellemez.

Yerleşimler, Dışa Aktarmalar ve Geziyi Kapatma

İyi bir bölüm, insanlar birbirine nasıl geri ödeme yapacağını ve daha sonra bunu nasıl kanıtlayacağını bildiğinde tamamlanır. Bu özellik hesaplamaları kapanışa dönüştürür.

“Settle up” ne anlama gelsin?

İki geçerli seçenek:

• Sadece uygulama kaydı: uygulama kim kimden ne kadar aldı takip eder; para başka yerde akar (nakit, banka transferi). Basit ve ödeme işleme yükünü almaz.
• Harici ödeme linkleri: uygulama “Alex'e $18 öde” kısayolu üretir ve ödeme uygulamasını açar. Bu sürtüşmeyi azaltır ama bölgesel entegrasyon gerektirir.

Link veriyorsanız, modüler ve bölgeye duyarlı yapın (mevcutluğu garanti etmeyin).

Kısmi yerleşimleri destekleyin

Kullanıcıların her kişi için birden fazla ödeme kaydetmesine izin verin. Örnek: “Sam Jordan'a 20$ nakit ödedi” ve “Sam 15$ banka transferi yaptı” gibi, bakiye sıfırlanana kadar. Her zaman gösterin:

• güncel bakiye (borçlu/alacaklı)
• yerleşim geçmişi (zaman damgası, yöntem, not)
• kalan tutar

İnsanların gerçekten ihtiyaç duyduğu dışa aktarmalar

Reimburse veya kayıt için sunun:

• CSV (tablolama/muhasebe için)
• PDF özet (toplamlar, kişi bazlı bakiyeler, gider listesi)

Para birimi, kullanılmış kur ve kim ödedi bilgisini dahil edin.

Gezi kapatma akışı net olsun

Kapatma şu şekilde olmalı:

1. açık bakiyeleri göster ve kapatmayı öner
2. son dışa aktarımları oluştur
3. geziyi arşivle (varsayılan olarak salt okunur)

Arşivlenen geziler aranabilir ve paylaşılabilir kalmalı; kazara düzenleme olmasın diye korunmalı.

Güvenlik, Gizlilik ve Güven Düşünceleri

Seyahat gider uygulamaları beklenenden daha hassas verilerle uğraşır: kim kiminle gezdiği, nereye gittikleri, ne kadar harcadıkları ve çoğu zaman fişlerdeki kişisel bilgiler. Erken güven inşa etmek, daha az churn ve destek talepleri demektir.

Uygulamanızın uygulaması gereken güvenlik temelleri

Veri hareket halindeyken ve depolandığında koruyun:

• Transit şifreleme: tüm API çağrıları ve resim yüklemeleri için HTTPS/TLS kullanın.
• Güvenli depolama: jetonlar ve önbellek verilerini OS güvenli depolamasında (Keychain/Keystore) saklayın. Düz metin dosya veya loglardan kaçının.
• En az yetki: gerçekten ihtiyaç duyduğunuz izinleri isteyin (kamera gibi). İçeride admin erişimini sınırlayın ve denetleyin.

Fişleri hassas içerik olarak ele alın

Fişler telefon numarası, sadakat ID veya kısmi kart numarası içerebilir. Hafif kontroller sunun:

• Kullanıcıya yüklemeden önce görüntüyü gözden geçirme ve kırpma verin.
• Hassas alanları bulanıklaştırma/gizleme araçları düşünebilirsiniz.
• OCR çalıştırıyorsanız, ne çıkarıldığını şeffaf gösterin ve silme/düzeltme izni verin.

Veri saklama ve kullanıcı kontrolü

Kullanıcılar bir gezi tamamlanınca silme bekleyebilir:

• CSV/PDF dışa aktarımları ve gezi/hesap seviyesinde veri silme sağlayın.
• Yedeklerin ne kadar süre tutulduğunu ve “silme”nin ne anlama geldiğini açıkça belirtin.
• Geziyi kapatma ve bundan sonra katılımcıları kaldırmayı kolaylaştırın.

Analitik: aşırı toplama yapmayın

Ürün sağlığını izlerken gizliliğe saygılı olun. Odaklanın: özellik kullanımı (örn. “gider eklendi”, “gezi oluşturuldu”, “dışa aktarma yapıldı”)—fiş içerikleri veya hassas kişisel detaylar yerine. Hassas konum verisini yalnızca zorunluysa ve açık onay ile toplayın.

Spam ve kötüye kullanıma karşı korumalar

Davetler ve paylaşılan notlar suiistimal edilebilir. Davetler için hız sınırı, yeni hesaplar için doğrulama ve basit bir engelleme/şikâyet akışı ekleyin. Paylaşılan içerik için dosya tipleri, boyut limitleri ve tarama gibi temel moderasyon korumaları uygulayın.

Test, Lansman Kontrol Listesi ve Yineleme Planı

Seyahat gider paylaşım uygulaması göndermek; gösterişli ekranlardan çok güvenle ilgilidir: matematik yanlışsa veya veriler kaybolursa kullanıcı geri dönmez. Test ve dağıtımı ürün özellikleri olarak ele alın.

Matematiği test edin (otomatikleştirin)

Gider bölüşme algoritmanız etrafında birim testleri oluşturun:

• Bölüşme türleri (eşit, paylar, yüzdeler, tam tutarlar)
• Çoklu para birimi dönüşümleri (gider başı sabit kur vs gezi kuru)
• Yuvarlama kuralları (ek kuruş kime gider)
• Netleme ve yerleşim matematiği

Sıfır-tutar, iade, çoğaltılmış girişler ve yerleşim sonrası düzenlemeler gibi kötü durumları da kapsayın.

Akışları test edin (gerçek gezilerin yaptığı şeyler)

Çoğu hata günlük aksiyonlarda ortaya çıkar. Entegrasyon testleri ekleyin:

• Başkaları düzenlerken gider ekle/düzenle/sil
• Davetler: yanlış e-posta, süresi dolmuş link, yeniden katılma, cihaz değişimi
• Çevrimdışı mod: çevrimdışıyken gider oluşturma, yeniden bağlanma, çakışma çözümü ve senkronizasyon denemeleri

Beta kontrol listesi (store öncesi)

Küçük bir beta ile seyahat eden gruplarda doğrulayın:

• Zayıf ağlardaki performans ve uçuş modu davranışı
• Pil tüketimi (fotoğraf yükleme ve arka plan senkronizasyonu başlıca etkenler)
• Çökme izleme, loglama ve kolay bir hata rapor yolu

Lansman planı ve yineleme

App Store varlıklarını, onboarding ve hafif bir yardım merkezini hazırlayın (ör. /help sayfası). Destek e-postası ve uygulama içi “Geri bildirim gönder” kısayolu ekleyin.

Lansman sonrası, aktivasyonu (ilk gezi oluşturma), tutunmayı (geziyi yeniden açma) ve “yerleşim yapıldı” anını takip edin. Düşüşleri azaltan düzeltmeleri önceliklendirin: kafa karıştıran para birimi istemleri, yavaş gider ekleme akışı, davet hataları—ve ardından küçük, ölçülebilir sürümlerle yineleyin.

Hızlı inşa edip sık test ediyorsanız, güvenli yineleme sunan araçlar (anlık görüntüler ve geri alma gibi) hassas mantık—bakiye ve yerleşim hesapları gibi—üzerinde sık değişiklik yaparken özellikle faydalıdır.