Hareket Halinde Gider Notları İçin Mobil Uygulama Nasıl Oluşturulur

Ne İnşa Ediyorsunuz ve Neden Önemli?

“Hareket halindeki gider notları” uygulaması, harcamayı gerçekleştiği anda yakalamak için tasarlanmış basit bir mobil araçtır—bir sokak köşesinde, takside, havaalanı sırasındayken. Öncelik hızdır: minimum yazma, birkaç dokunuş ve iş tamam. Uygulama uzun formlar veya kusursuz veri girişi gerektirirse, gerçek hayat yoğunlaştığında insanlar kullanmaz.

Kimler İçin

Bu tür bir uygulama, giderlerini takip eden serbest çalışanlar, hafif geri ödeme kayıtlarına ihtiyaç duyan küçük ekipler ve birden fazla para birimi ve fiş ile uğraşan gezginler için özellikle yararlıdır. Ayrıca haftanın sonunda o “18,40 ₺” harcamasının ne olduğunu sıkça unutan herkes için faydalıdır.

Bu rehberde neyi inşa edecek/karar vereceksiniz

Makale sonunda şu amaçlarla bir MVP gider notları uygulaması için net bir planınız olacak:

• Hızlı bir gider yakalama (tutar, kategori, kısa not)
• Mümkünse fiş fotoğrafı ekleme
• Çevrimdışı güvenilir çalışma ve sonra senkronizasyon
• Fatura, dosyalama veya geri ödeme zamanı geldiğinde basit gider raporları dışa aktarma

Ayrıca birkaç pratik karar vereceksiniz—kullanıcılarınız için “hızlı yakalama”nın ne anlama geldiği, bütçenize uyan tarama yaklaşımı ve gizliliği sürtüşme yaratmadan nasıl ele alacağınız gibi.

Önce MVP, sonra yinele

Amaç tam bir muhasebe sistemi oluşturmak değil. Günlük olarak düşünmeden kullanılabilecek bir sürümle başlayın. Gerçek kullanım desenlerini gördükçe daha akıllı öneriler, daha iyi raporlar ve derin entegrasyonlar ekleyebilirsiniz.

Bu rehber odaklı kalır: amaç gereksiz karmaşıklığa kaymadan gönderilebilir ilk sürümü oluşturmak.

Kullanıcı İhtiyaçları ve Temel Kullanım Durumları

Uygulamanız hareket halindeki gider notları içinse temel ihtiyaç basittir: gider gerçekleştiği anda yakalanmalı, detaylar dağınık olsa bile. İnsanlar kasada “muhasebe yapmak” istemezler—ileride güvenebilecekleri hızlı bir kayıt isterler.

Temel kullanıcı işleri

Çoğu kullanıcı üç işi takip eder:

• Şimdi yakala: tutar (veya fotoğraf), satıcı ve “müşteri öğünü” gibi kısa bir ipucu.
• Detayları sonra düzelt: kategori, vergi/ipuç ayrımı, proje/müşteri, ödeme yöntemi.
• Sonra gönder/dışa aktar: finans bölümüne paylaşma, geri ödemeler veya kişisel bütçeleme araçları.

Tasarım yapılacak ortak sorunlar

Hız sorunları genellikle gider takip alışkanlıklarını bozar:

• Kayıp fişler (kağıt solar, atılır veya hiç yazdırılmaz).
• Bağlamı unutma (yemeğin kimle olduğu, hangi işe ait olduğu).
• Yavaş formlar (çok fazla zorunlu alan, çok fazla ekran, çok fazla yazma).

Birincil senaryoyu seçin

Uygulamanızın diğerlerinden daha iyi yapacağı bir “varsayılan an” seçin: kahve/taksi/ hareket halindeyken yemek—bir el telefonda, kötü ışık, sınırlı zaman, kesik sinyal. Bu senaryo MVP kararlarınızı yönlendirmeli (büyük düğmeler, minimum yazma, zarif çevrimdışı davranış).

Sizi dürüst tutacak başarı metrikleri

Erken ölçülebilir sonuçları tanımlayın:

• Gider kaydetme süresi: örn. temel bir giriş için 10–15 saniyenin altında.
• Tamamlama oranı: yakalanan öğelerin % kaçının 48 saat içinde kesinleştiği.

Basit kullanıcı hikâyeleri

• “Bir gezgin olarak, bir fişin fotoğrafını çekip anında kaydetmek istiyorum, böylece otelden önce kaybetmem.”
• “Bir danışman olarak, ‘Project Delta’ gibi bir notu tek dokunuşla eklemek istiyorum ki ileride giderleri doğru gönderebileyim.”
• “Bir yönetici olarak, temiz bir dışa aktarım istiyorum ki geri ödemeler gereksiz yazışma gerektirmesin.”

Gider Notları için MVP Özellik Kontrol Listesi

Bir gider notları uygulaması, temel bilgileri saniyeler içinde yakalayıp sonra geri çekildiğinde başarılı olur. MVP için güvenilir bir “Gider Ekle” akışına odaklanın: kaydı güvenilir şekilde kaydetsin ve sonra kolayca bulunabilsin.

Zorunlu alanlar (hâlâ tamamlanmış hissettiren minimum)

Bunları vazgeçilmez olarak başlatın:

• Tutar (ondalık desteği ve açık para birimi gösterimi)
• Satıcı (kime ödendi)
• Kategori (en azından küçük bir başlangıç seti)
• Tarih (ne zaman gerçekleşti)
• Not (ileride yardımcı olacak kısa açıklama)
• Fotoğraf (opsiyonel ek, fakat uygulama desteklemeli)

Opsiyonel alanlar (faydalı ama kaydetmeyi engellememeli)

Sadece hızlı girilebilen ve açıkça değerli olanları ekleyin:

• Proje/müşteri (serbest çalışanlar ve ekipler için)
• Ödeme yöntemi (nakit, kart, geri ödenebilir vb.)
• Etiketler (ör. “seyahat” veya “vergiler” gibi esnek gruplama için)

Neler otomatik doldurulabilir

Otomatik doldurma sürtüşmeyi azaltır ve doğruluğu artırır:

• Tarih/saat varsayılan olarak “şimdi” ayarlı, düzenlenebilir.
• Para birimi cihaz yerel ayarına göre; manuel değişime izin verin.
• Konum kullanıcı izin verirse; MVP konuma ihtiyaç duymadan kullanılabilmeli.

“Not” ne demek kararını verin

Erken karar verin: “not” serbest metin mi yoksa birkaç şablon (ör. “Havaalanına taksi”, “Müşteri öğünü”) mu sunacaksınız? MVP için serbest metin yeterlidir. Daha sonra hız için birkaç hızlı seçenek ekleyebilirsiniz.

MVP kapsamı vs. “sonra” listesi

MVP kapsamı: gider oluşturma, düzenleme, listeleme/arama, temel kategoriler, fotoğraf ekleme, basit toplamlar.

Sonra: OCR tarama, akıllı kategori önerileri, dışa aktarmalar, çoklu para birimi dönüşümleri, ekip paylaşımı.

Gerçek Hayatta Hızlı Yakalama için UX Akışı

İyi bir gider notları uygulaması, bir hesabı öderken, bir toplantıya yürürken veya çantalarla uğraşırken yakalanmak üzere tasarlanmıştır. UX hedefi basit—kullanıcı düşünmeden saniyeler içinde kullanılabilir bir kayıt oluşturmalı.

Tek dokunuşla giriş noktası ile başlayın

Kullanıcıların uygulamayı aramasını istemeyin. En az bir hızlı başlatma seçeneği sunun:

• Kilit ekranı widget'ı veya ana ekran widget'ı ile “Yeni gider”
• Uygulama hızlı eylemi (ikon uzun basma) ile doğrudan giriş
• Sık kullanıcılar için OS kısayolları (ses kısayolu veya otomasyon)

Uygulama açıldığında doğrudan yakalama ekranında olmalı—bir gösterge panosunda değil.

Hıza uygun bir giriş modeli seçin

İki model iyi çalışır:

• Tek ekran: tutar, satıcı, kategori ve not aynı yerde. Deneyimli kullanıcılar ve hızlı düzenlemeler için en iyisi.
• Adım adım: tutar → kategori → detaylar. Büyük girdiler ve daha az dikkat dağıtıcı isteniyorsa en iyisi.

Adım adım seçerseniz, adım sayısını küçük tutun ve opsiyonel alanların atlanmasına izin verin.

Varsayılanlar ve akıllı önerilerle yazmayı azaltın

“Doğru” girdiyi kolaylaştırın:

• Son kullanılan ödeme yöntemi ve kategori
• Varsayılan para birimi (seyahat ederken hızlı geçiş)
• Son zamanlardaki satıcılardan öneriler

Tutar için büyük bir sayısal giriş kullanın ve metin alanlarını opsiyonel tutun.

“Şimdi kaydet, sonra düzenle”i destekleyin

Gerçek hayat dağınıktır. Kullanıcının bir tutarı (veya sadece bir fiş fotoğrafını) aldıktan sonra Savea dokunup hemen devam etmesine izin verin, sonra düzeltme yapabilsin.

Pratik akış:

• Hemen kaydet → hafif bir onay göster
• “Uncategorized” veya “Needs review” listesine gönder
• Listeden hızlı düzenlemeye izin verin, tam formu yeniden açmaya gerek kalmadan

Erişimi engellemeyen erişilebilirlik temelleri

Hızlı yakalama, dokunması veya okunması zor olursa başarısız olur. Büyük dokunma hedefleri, açık etiketler (sadece ikon olmasın), güçlü kontrast ve güvenilir karanlık mod desteği kullanın. Birincil eylem (Save) tek elle ulaşılabilir olmalı.

Fiş Fotoğrafları ve OCR Tarama Seçenekleri

Fiş yakalama bir gider notları uygulamasını ya zahmetsiz hissettirir—ya da can sıkıcı yapar. Hedefiniz basit: kuyrukta beklerken veya taksiye yürürken bile minimum sürtüşme ile okunabilir bir fiş fotoğrafı almak.

Kamera yakalama hedefleri

Kamera akışını “sadece çalışır” şekilde tasarlayın:

• Kağıt için otomatik odak ve otomatik pozlama (çoğunlukla parlak veya buruşuk)
• Net çerçeve ipuçları (kenar rehberleri) ve “Çok karanlık” veya “Daha yakınlaşın” gibi anlık geri bildirim
• Tek elle hızlı çekim: büyük deklanşör düğmesi, dokunmatik geri bildirim ve hızlı yeniden çekim

Tarama opsiyonel olmalı. Kullanıcı fotoğrafı anında kaydedip devam edebilmeli, sonra çıkarım arka planda gerçekleşsin.

OCR seçenekleri: cihazda vs sunucu tabanlı

Cihazda OCR gizlilik, çevrimdışı kullanım ve hız (yükleme yok) için iyidir. Eski cihazlarda, alışılmadık fiş formatlarında veya düşük kaliteli fotoğraflarda zorlanabilir.

Sunucu tabanlı OCR cihazlar arasında daha tutarlı olabilir ve merkezi olarak geliştirmesi daha kolaydır, fakat yükleme süresi ekler, ağ erişimi gerektirir ve gizlilik/uyumluluk soruları doğurur. Bu yolu seçerseniz, neyin yüklendiği ve ne kadar süre saklandığı konusunda açık olun.

Pratik bir yaklaşım hibrittir: önce cihazda deneyin, sonra kullanıcı çevrimiçi ve onaylıysa sunucu OCR sunun.

Ne çıkarılmalı (ve ne çıkarılmamalı)

Raporlama işlevselliğini güçlendiren yüksek güvenilirlikli alanlarla başlayın:

• Toplam tutar
• Satıcı adı
• Tarih
• Vergi (opsiyonel)
• Para birimi (simge + yerel ipuçlarından)

Satır kalemleri bekleyebilir; karmaşıklık ekler ve genelde basit gider raporları için gerekli değildir.

OCR başarısız olduğunda: düzenlemeyi hızlı yapın

Her zaman temiz bir manuel giriş ekranı sağlayın: dokunarak düzeltilebilen tutar/tarih, satıcı önerileri ve “Okunamadı olarak işaretle” seçeneği.

Çoğaltmaları önleyin

Hafifçe eşleşenler için uyarılar koyun: yeni bir fiş, toplam + zaman aralığı + satıcı benzerliği ile mevcut bir fişle yakından eşleşiyorsa kullanıcıya onaylatın; engelleme yapmayın.

Çevrimdışı Mod, Depolama ve Senkronizasyon Stratejisi

Bir gider notları uygulaması, bir metroda, müşterinin bodrumunda veya bir otoparkta çalışıyorsa “hareket halinde” gibi hissettirir. Çevrimdışını varsayılan sayın: kullanıcı bir gider ekleyebilmeli, fiş fotoğrafı iliştirebilmeli ve devam edebilmeli—sinyal olsun olmasın.

Çevrimdışı-öncelikli: önce yerel yaz, sonra senkronize et

Kullanıcı Savee dokunduğunda gideri cihazda hemen saklayın. Ağ çağrısına bağlı kılmayın. Bu tek karar çoğu hayal kırıklığını ortadan kaldırır ve kaybolan kayıtları önler.

Yerel depolama için, telefonda küçük şifreli bir veritabanı (ör. şifreli SQLite tabanlı bir mağaza) düşünün. İçermeli:

• Gider alanları (tutar, para birimi, tarih, kategori, notlar)
• Fiş meta verileri (dosya adı, durum, zaman damgaları)
• Bir senkronizasyon kuyruğu (ne yüklenmesi gerekiyor)

Kullanıcıyı şaşırtmayacak senkronizasyon kuralları

Senkronizasyon uygulamaları garipleşebilir. Bir kural seçin ve bunu iletişimde açık yapın.

• Last-write-wins en basitidir: en yeni düzenleme daha eski sürümün üzerine yazar. Gider notları için genelde yeterlidir çünkü insanlar nadiren aynı öğeyi iki cihazda aynı anda düzenler.
• Eğer sık çok cihazlı düzenleme bekliyorsanız (ör. paylaşılan hesaplar), hafif alan düzeyinde birleştirme düşünün: bir cihazdaki kategori değişikliği diğer cihazdaki not düzenlemesini silmemeli.

Ayrıca bir öğe bir cihazda silindiğinde diğerinde düzenlendiğinde ne olacağını kararlaştırın. Yaygın yol “soft delete” (silindi olarak işaretleme, senkronize etme, sonra temizleme).

Fiş resimleri için arka plan yüklemeleri

Fiş resimleri büyük dosyalardır ve genellikle ilk başarısız olan şeydir. Görselleri yerelde kaydedin, sonra çevrimiçi olduğunda arka planda yükleyin (tercihen Wi‑Fi’de olacak şekilde, kullanıcı onaylarsa hücresel de olabilir). Yüklemeler yeniden başlatılabilir olmalı ki kopuk bağlantı her şeyi sıfırlamasın.

Açık geri bildirim: kuyruğa alındı, senkronize ediliyor, başarısız

Kullanıcılara görünür, sakin durumlar gösterin:

• Queued (kaydedildi ve beklemede)
• Syncing…
• Failed bir Retry düğmesi ve isteğe bağlı “tümünü yeniden dene”

Bu, senkronizasyonu bir gizem olmaktan çıkarıp deneyimin öngörülebilir bir parçası yapar.

Aşırı Düşünmeden Teknoloji Yığını Seçimleri

Harika bir gider notları uygulamasını birçok farklı araçla inşa edebilirsiniz. Amaç “en iyi” yığını seçmek değil—ekibinizin gönderebileceği ve sürdürebileceği birini seçmektir.

Platform: iOS, Android veya Çapraz Platform

Ekip zaten Swift/SwiftUI veya Kotlin/Jetpack Compose biliyorsa, yerel uygulamalar genelde cilalı, güvenilir bir yakalama deneyimi için en hızlı yoldur (kamera, çevrimdışı depolama, paylaşım menüsü).

Her iki platforma da küçük bir ekiple ihtiyacınız varsa, bir çapraz platform seçeneğine karar verin:

• Flutter: güçlü performans, tutarlı UI, iyi kamera ve çevrimdışı paketleri.
• React Native: web/JS biliyorsanız hızlı yineleme, büyük ekosistem.

Pratik MVP kuralı: bir mobil mühendisiniz varsa çapraz-platform; ayrı iOS + Android yeteneğiniz varsa yerel seçin.

Uygulama mimarisi: tahmin edilebilir tutun

“Edit expense”, “attach receipt” ve “sync status” gibi özellikler spaghetti olmasın diye basit, tutarlı bir desen kullanın:

• MVVM (yerel ve Flutter’da yaygın) formlar ve durum için iyi çalışır.
• Redux tarzı durum (React Native’de yaygın) çevrimdışı + senkronizasyon çok durum üretiyorsa iyidir.

Aşırı mühendislik yapmayın: UI, durum ve veri katmanı arasında temiz bir ayrım genelde yeterlidir.

Backend: gerçekten ihtiyacınız olan kadar

Çoğu MVP için dört şey gerekir:

1. Auth (e-posta, Apple/Google sign-in)
2. Veritabanı (giderler, kategoriler, ayarlar)
3. Dosya depolama (fiş fotoğrafları)
4. Arama/dışa aktar (basit filtreleme ve CSV/PDF oluşturma)

Managed bir backend (Firebase, Supabase) kurulum süresini kısaltır. Özel bir backend (Node/Django/Rails) karmaşık raporlama veya sıkı uyumluluk bekliyorsanız daha fazla kontrol sağlar.

Hızlı ilerlemek ve tüm boru hattınızı yeniden kurmamak isterseniz, Koder.ai gibi bir platform da MVP aşamasında faydalı olabilir: temel akışları sohbet tabanlı bir iş akışıyla prototipleyebilir, sonra kaynak kodu dışa aktarabilirsiniz. React web panel + Go + PostgreSQL gibi yaygın MVP seçimleriyle uyumludur ve planlama modu, anlık görüntüler ve geri alma gibi özellikler sunar.

API şekli (sıkıcı ama faydalı tutun)

Uç noktaları temel nesneler etrafında tasarlayın:

• POST /expenses, PATCH /expenses/{id}
• POST /receipts (yükleme), bir giderle ilişkilendirme
• GET /expenses?from=&to=&category=
• POST /exports (indirilebilir bir dosya döner)

Maliyet ve karmaşıklık takasları

Çapraz-platform geliştirilmeyi hızlandırır ama kamera/OCR kenar durumları için ekstra çaba gerektirebilir. Managed backend'ler erken dönemde maliyeti düşürür; ölçeklenme ve net bir yol haritası varsa özel backend uzun vadede daha ucuz olabilir. Emin değilseniz managed ile başlayın ve ileride taşınma yolu bırakın (bkz. /blog/offline-sync-basics).

Güvenlik, Gizlilik ve İzinler

Bir gider notları uygulaması hızla kişisel ve iş hassasiyeti taşıyan verilerin saklandığı bir konteyner haline gelir. Güvenlik ve gizliliği “sonradan iyi olur” işi değil, temel ürün gereksinimi olarak ele alın.

Hangi veriler hassastır?

Banka bilgisi saklamıyor olsanız bile, harcama alışkanlıklarını veya iş faaliyetlerini ortaya çıkarabilecek bilgilerle uğraşırsınız:

• Fiş fotoğrafları (kısmi kart numaraları, mağaza adresleri, vergi kimlikleri içerebilir)
• Satıcı isimleri, kalemler ve toplamlar
• Tarihler, zaman damgaları ve (eklendiğinde) konum bağlamı
• “Müşteri yemeği” gibi notlar

Kullanıcıların beklediği temel korumalar

Basit, savunulabilir bir temel ile başlayın:

• Transitte şifreleme: tüm API çağrılarında TLS kullanın
• Dinlenirken şifreleme: mümkünse cihazda ve bulutta hassas veriyi şifreleyin
• En az ayrıcalık: fiş resimleri ve çözülmüş veriyi ayrı depolar/kovalar içinde katı kurallarla tutun

Üçüncü taraf OCR kullanıyorsanız, neyin yüklendiği, ne kadar saklandığı ve tedarikçilerin bunu model eğitimi için kullanıp kullanamayacağı konusunda açık olun.

İzinler: yalnızca gerektiğinde isteyin

İzinler bir güven anıdır. Noktada kullanımda isteyin, sade bir dille açıklayın:

• Kamera: kullanıcı “Scan receipt”a dokunduğunda
• Fotoğraflar/Medya kütüphanesi: kullanıcı “Galeriden yükle” seçtiğinde

Konumu varsayılan istemeyin; çoğu kullanıcı gider notları için bunu beklemez.

Hesap erişimi ve uygulama düzeyi kilit

Çoğu MVP için e-posta + magic link/OTP yeterlidir. Hedef kullanıcı kurumsa SSO sonradan eklenebilir.

Ayrıca uygulamayı açma veya fişleri görüntüleme için cihaz kilidi (Face ID/Touch ID/PIN) seçeneği düşünün—özellikle paylaşılan cihazlarda.

Saklama ve silme ürün özellikleri olarak

Gizlilik kontrollerini görünür yapın:

• Dışa aktar sonra sil: kullanıcıya bir gider raporu indirme ve altında yatan veriyi kaldırma imkânı verin
• “Hesabı sil” gerçekten fişleri, OCR metnini ve yedekleri belirli bir süre içinde kaldırmalı
• Opsiyonel saklama kuralları (örn. 90 gün veya 7 yıl sakla)

Açık ayarlar destek taleplerini azaltır ve kullanıcıların gerçek fişleri uygulamada saklamaya güvenmesini sağlar.

Kategoriler, Para Birimi ve Akıllı Öneriler

İyi bir organizasyon, hızlı not yığınını gerçekten raporlanabilir bir şeye dönüştürür. Genelde üç şeye dayanır: kullanımı zorlaştırmayan bir kategori modeli, seyahat için “yeterince iyi” para birimi yönetimi ve tekrarlı yazmayı ortadan kaldıran hafif öneriler.

Gelişebilen basit bir kategorilendirme modeli

Çoğu kişi için tanıdık, kısa bir liste ile başlayın (ör. Meals, Transport, Lodging, Office, Entertainment, Fees). Tercih edilmez seçim yükünü azaltmak için ~10–12 altında tutun.

Sonra özel kategoriler bir kaçış yolu olarak ekleyin. İki pratik kural:

• Kullanıcının özel kategorilerini yeniden adlandırıp silmesine izin verin.
• Sadece büyük/küçük harf farkı olan çoğaltmalara izin vermeyin.

Hafif kurallarla akıllı öneriler

Akıllı hissettirmek için “AI” gerekmez. Küçük bir kural katmanı oluşturun:

• Sık kullanılan satıcıları takip edip o satıcı için son kullanılan kategoriyi önerin
• Kategori seçicide son kullanılanları üstte gösterin
• Kullanıcı kategoriyi değiştirdiyse, bir kerelik “Bunu sonraki sefer için hatırlansın mı?” sorusu sorun

Bu, yakalamayı hızlandırır ama otomasyonu zorunlu kılmaz.

Çoklu para birimi temelleri, fazla karmaşık olmadan

Hem şunu saklayın:

• Orijinal tutar + orijinal para birimi (fişin gösterdiği)
• Dönüştürülmüş tutar + temel para birimi (raporların kullandığı)

Dönüştürme için günlük kur kullanmak (MVP için yeterli). Kullanılan kuru ve tarihi gösterin ki toplamlar gizemli olmasın.

Vergi/KDV alanları: kullanıcılarınız ihtiyaç duyuyorsa ekleyin

İş geri ödemelerine odaklanmıyorsanız KDV’yi opsiyonel tutun: “Vergi dahil mi?” gibi bir açma/kapama veya “Detay ekle” altında gizli bir “Vergi” alanı.

Gerçek sorulara uyan arama ve filtreler

“Geçen ay X için ne harcadım?” sorusuna cevap verebilmeli. Tarih aralığı, kategori, tutar ve satıcı filtreleri ile notlar ve satıcı isimleri üzerinde basit anahtar kelime araması destekleyin.

Dışa Aktarmalar ve Basit Gider Raporları

Giderleri yakalamak işin yarısıdır—nihayetinde muhasebeye teslim edilebilecek, geri ödeme portalına yüklenebilecek veya saklanabilecek bir şey üretmeniz gerekir. Dışa aktarmalar uygulamayı pratik bir araca dönüştürür.

Şimdi vs sonra desteklenecek dışa aktarma formatları

Oluşturması kolay ve yaygın kabul gören formatlarla başlayın:

• CSV tablolar ve muhasebe araçları için en evrensel seçenek.
• PDF özet temiz, yalnızca okunur bir rapor için; e-posta veya yükleme için uygundur.

Daha sonra araç entegrasyonları eklemeyi planlıyorsanız (ör. muhasebe platformları), dışa aktarma veri modelinizi girişlerin nasıl saklandığını değiştirmeden entegrasyon ekleyebilecek şekilde tasarlayın.

Basit bir “gider raporu” akışı

Rapor deneyimini öngörülebilir tutun:

1. Aralığı seç (bu ay, geçen ay, özel tarih)
2. Gözden geçir (kategoriye göre toplamlar, eksik fişler, kategorize edilmemiş öğeler)
3. Dışa aktar/paylaş (dosyaya kaydet, e-posta, paylaşma menüsü)

Bir uygulama proje/müşteri destekliyorsa isteğe bağlı filtre ekleyin ama zorunlu yapmayın.

Fişler: bağlantılar mı gömülü ekler mi

Raporla birlikte fişlerin nasıl iletileceğine karar verin:

• CSV + fiş bağlantıları: her kayıt için bir URL veya yerel dosya referansı içerir.
• Gömülü küçük resimler içeren PDF: denetçiler için daha iyi, dosya boyutu büyük.

Hangi yolu seçerseniz seçin, bir fişin eksik olduğunu açıkça gösterin.

Düzenli kalan dosya adlandırma kuralları

Tutarlı adlar kullanın:

• expenses_2025-01-01_to_2025-01-31_jordan.pdf
• expenses_2025-01_project-acme.csv

Denetime uygun alanlar

Hafif bir uygulama bile dışa aktarırken şu alanları içermeli:

• Oluşturulma zamanı ve düzenlenme zamanı
• Kaynak (manuel vs. OCR)
• Para birimi, kategori, satıcı (mevcutsa) ve notlar

Bu detaylar, “Bu ne zaman girildi ve kaynağı ne?” sorularını azaltır.

Gerçek Dünya Koşulları İçin Test

Bir gider notları uygulaması dağınık anlarda başarısız olur: kötü aydınlatma, sinyal yok ve yürürken tek elle kullanım. Testler sadece “mutlu yol” gösterilerine değil bu gerçek durumlardaki davranışa odaklanmalı.

Temel fonksiyonel testler

Çekirdek akışı (yakala → kaydet → senkronize et → dışa aktar) koruyan birkaç testle başlayın:

• Form doğrulama: zorunlu alanlar (tutar, tarih), makul sınırlar, negatif değerler, para birimi biçimlendirmesi ve “bilinmeyen satıcı” işleme.
• Çevrimdışı kuyruğu: bağlantı yokken gider oluştur/düzenle/sil ve bunların yerelde saklandığını ve UI'da hemen göründüğünü doğrula.
• Senkronizasyon yeniden denemeleri: senkron sırasında ağ kopması simülasyonu ve backoff, çakışma işleme (aynı öğe iki kez düzenlendi), “son senkron” durumunu doğrula.
• OCR geri dönüşü: OCR başarısız olduğunda kullanıcıların manuel olarak kaydetmeye devam edebildiğini ve kısmi OCR sonuçlarının düzenlenebilir olduğunu doğrula.

Kamera özelliklerini bozan cihaz ve ortam testleri

Birkaç gerçek cihazda manuel test yapın (sadece bir amiral gemisi değil):

• Kötü aydınlatma ve parlak fişlerde yansıma
• Titrek çekim (yürürken, tek elle), odak gecikmesi
• Uçak modu ve düşük sinyal alanları (Wi‑Fi ↔ hücresel geçişleri dahil)
• Düşük depolama uyarıları ve sınırlı bellek koşulları

Kullanıcıların hissettiği performans kontrolleri

Birkaç “hissedilen” zamanlamayı ölçün ve buildler arasında tutarlı tutun:

• Uygulamanın başlama süresi ve yakalama ekranına gelme
• Kamera başlatma süresi ve ilk net kareye ulaşma
• Savea dokunup girdiyi listede görme süresi (senkronizasyon arka planda olsa bile)

Çökme raporlama ve temel analiz

Cihaz-spesifik sorunları yakalamak için çökme raporlamasını erken kurun. Ana adımlar için hafif olay takibi ekleyin (aç capture, fiş çekildi, OCR başarılı/başarısız, sync başarılı/başarısız) ve hassas metin veya tam fiş resimlerini kaydetmeyin.

Kısa bir betada anketle test edin

Gerçekten seyahat eden veya gider gönderen 10–30 kişiyi davet edin. Geri bildirimi yapılandırılmış tutun:

• Son olarak hangi durumlarda yakalama yavaş veya kafa karıştırıcı oldu?
• Çevrimdışı modu güvendiler mi?
• Fiş yakalama veya OCR ne sıklıkla başarısız oldu?
• Ne dışa aktardılar ve dışa aktarılan rapor kullanılabilir miydi?

Lansman, İlk Açılış Deneyimi ve İterasyon Planı

Sorunsuz bir lansman her şeyin olması değil—ilk kullanım deneyiminin bir dakikadan kısa sürede uygulamanın değerini göstermesidir: bir gider kaydet, fiş ekle ve sonra bul.

Lansman kontrol listesi (neyle çıkmalı)

Mağaza varlığı ve uyumluluk detaylarını erken hazırlayın ki çıkış haftasında acele etmeyin:

• App store meta verileri: net başlık/alt başlık, anahtar kelimeli açıklama ve tek satırlık değer vaadi (örn. “Fişleri kaydet ve gider raporlarını hızlıca dışa aktar”).
• Ekran görüntüleri: önce yakalama akışını göster (tutar → kategori → fiş), sonra çevrimdışı mod, sonra dışa aktarım.
• Gizlilik detayları: ne topladığınızı açıklayın (e-posta, cihaz ID, analiz), hangi verinin cihazda kaldığını ve fiş fotoğraflarının nasıl işlendiğini.
• Destek temelleri: kısa SSS, iletişim e-postası ve basit “sorunu bildir” formu.

İlk Açılış (3–5 ekran, max)

Açılışı kısa ve eylem odaklı tutun:

1. Quick Capture göster (tutar, kategori, opsiyonel not).
2. Gerekli izinleri kullanım anında isteyin (kamera “Add receipt”te, hepsi önceden sormayın).
3. Kullanıcılara düzenleyebilecekleri örnek bir gider sunun ve sonra ilk gerçek giderlerini kaydetmeye teşvik edin.

Fiyatlandırma seçenekleri

Bir modeli seçin ve anlaşılır tutun:

• Ücretsiz katman: manuel giriş + sınırlı aylık dışa aktarma.
• Abonelik: limitsiz fiş/OCR ve bulut senkronizasyon.
• Ekip planları: paylaşılan çalışma alanları, onay akışı, yönetici kontrolleri.

(Koder.ai ile inşa ediyorsanız, bu katmanlar aşamalı yeteneklere kolayca uyar: MVP ile ücretsiz başlayın, gelişmiş özellikleri Pro/Business altında sınırlandırın, Enterprise seçeneklerini uyumluluk/özelleştirme için saklayın.)

Lansman sonrası gerçekten önemli metrikler

Kullanıcı değerine bağlı davranışı izleyin:

• Tutma: D1/D7/D30.
• Haftalık kaydedilen gider sayısı aktif kullanıcı başına.
• Dışa aktarma kullanımı: kaç kullanıcının rapor oluşturduğu ve sıklığı.

İterasyon yol haritası

Gerçek kullanım verisini önceliklendirerek ilerleyin:

• Kısayollar: widgetlar, “son gideri tekrarla”, hızlı kategori çipleri.
• Entegrasyonlar: muhasebe araçları, e-posta yönlendirme, paylaşılan sürücüler.
• Onay akışları: gönder → incele → geri ödeme.
• Otomasyon: akıllı kategori önerileri, kilometre, yinelenen giderler.