Serbest Çalışanlar İçin Proje, Fatura ve Geri Bildirim Web Uygulaması Nasıl Oluşturulur

Ne inşa ediyorsunuz ve kimin için

Bir serbest çalışanın bir müşteri projesini baştan sona yönetebileceği tek bir yer inşa ediyorsunuz: işi takip etmek, faturaları göndermek ve geri bildirim toplamak—e-posta zincirleri, tablolar ve sohbet arasında bağlam kaybetmeden.

Çözmeye çalıştığınız temel sorun

Serbest çalışma, bilgiler dağınık olduğunda bozulur. Bir proje “tamam”lanmış olabilir ama fatura edilmeyebilir, bir fatura gönderilmiş olabilir ama takip edilmeyebilir ve geri bildirim uzun bir e-posta dizisinde kaybolabilir. Bu uygulamanın amacı basit: proje durumu, faturalama ve müşteri onaylarını bağlı tutarak hiçbir şeyin gözden kaçmamasını sağlamak.

Birincil kullanıcılar (ve ihtiyaçları)

Bireysel serbest çalışanlar hız ve netlik ister: hafif bir gösterge paneli, hızlı fatura oluşturma ve güncellemeleri paylaşmak ve onay talep etmek için temiz bir yol.

Küçük stüdyolar (2–10 kişi) ortak görünürlük ister: görevin sahibi kim, ne engellenmiş ve hangi faturalar gecikmiş.

Tekrarlı müşteriler güven ister: ilerlemeyi görebilecekleri, teslimleri inceleyebilecekleri ve yapılandırılmış şekilde geri bildirim bırakabilecekleri bir portal.

Başarı nasıl görünür (ölçebileceğiniz metrikler)

Birkaç ölçülebilir sonuç seçin ve onlara doğru çalışın:

• Daha hızlı faturalama: “iş tamamlandı” ile “fatura gönderildi” arasındaki süre
• Daha az kaçırılan ödeme: hatırlatmalardan sonra gecikmiş faturaların azalması
• Daha net geri bildirim: teslim başına daha az revizyon döngüsü, daha hızlı onaylar
• Daha az idari iş: daha az manuel durum güncellemesi ve takip e-postası

MVP ve sonrası (kapsam şişmesini önleyin)

MVP için, bir oturumda değer yaratan iş akışına odaklanın:

Proje oluştur → müşteri ekle → bir kilometre taşı/teslim kaydet → geri bildirim iste → fatura oluştur → ödeme durumunu takip et.

“İyi olur” özellikleri daha sonra bırakın: zaman takibi, gider yönetimi, çok dövizli vergiler, derin analizler, entegrasyonlar ve özel marka. MVP eksiksiz hissettirmeli, kalabalık değil.

Serbest Çalışan Takipçisi MVP Özellik Kontrol Listesi

Bir serbest çalışan web uygulaması MVP'si temel döngüyü kapsamalı: işi takip et → fatura kes → geri bildirim topla → ödeme al. İlk sürümü haftalık kullanacağınız özelliklere odaklayın, sunumda etkileyici görünenlere değil.

Projeler (proje takibi)

Proje görünümünüz üç soruyu bir bakışta yanıtlamalı: neler aktif, sırada ne var ve ne risk altında.

• Durumlar: taslak, aktif, engellendi, teslim edildi, tamamlandı (artı “arsivlendi”)
• Kilometre taşları: sahip, son tarih ve tamamlama onayıyla basit liste
• Son tarihler: proje ve kilometre taşına göre, “gecikmiş” vurgusu
• Teslimler: kilometre taşına bağlı dosya/bağlantılar (ör. Figma URL'si, Google Drive linki)
• Notlar: hafif bir koşu kaydı (karar notları uzun açıklamalardan iyidir)

Faturalar (fatura yönetimi)

Faturalama sistemi muhasebe yazılımına dönüşmeden gerçek dünya faturalamasını desteklemeli.

• Kalemler: açıklama, miktar, oran, ara toplam
• Vergiler ve indirimler: fatura başına isteğe bağlı (yüzde veya sabit)
• Para birimi: müşteri veya fatura bazında ayarlanır
• Ödeme durumu: taslak → gönderildi → ödendi → gecikmiş (ve “iptal”)
• PDF + e-posta gönderimi: temiz bir PDF oluşturun ve ne zaman gönderildiğini takip edin

Müşteri geri bildirim portalı (yorumlar ve onaylar)

Müşteri geri bildirimi projelerin takıldığı yer—onun yapılandırılmış olmasını sağlayın.

• Yorumlar: teslim başına, @bahsetmeler (isteğe bağlı)
• Onaylar: “onaylandı” vs “değişiklik gerekli”, zaman damgalı
• Ekler: yükle veya referans bağlantıları (ekran görüntüleri, dokümanlar)
• Revizyon talepleri: kısa form: ne değişmeli, öncelik, son tarih

İyi olur (MVP stabilse)

Zaman takibi, giderler, yeniden kullanılabilir şablonlar (projeler/faturalar) ve markalı müşteri portalı harika sonraki adımlar—ancak önce temel hızlı, güvenilir ve kullanımı kolay olmalı.

Kullanıcı Yolculukları ve Ekran Haritası

İyi bir serbest çalışan takipçisi “açık” hissi verir çünkü ana yolculuklar öngörülebilirdir. Ekranları tasarlamadan önce uygulamanızın uçtan uca desteklemesi gereken birkaç akışı haritalayın—sonra sadece o akışların gerektirdiklerini inşa edin.

Temel yolculuklar (uçtan uca)

Ürününüzün vaat ettiği mutlu yolu ile başlayın:

• Proje oluştur → müşteriyi davet et → işi takip et → fatura kes → geri bildirim topla

Bunu basit bir storyboard olarak yazın:

1. Serbest çalışan bir proje oluşturur, kapsam, oran ve son tarihleri belirler.
2. Serbest çalışan müşteriyi e-posta ile davet eder.
3. Müşteri daveti kabul eder ve sadece o projeyi görür.
4. Serbest çalışan güncellemeleri kaydeder (kilometre taşları, dosyalar/bağlantılar, notlar).
5. Serbest çalışan sabit fiyat veya kilometre taşı teslimine göre fatura oluşturur.
6. Müşteri faturayı inceler, öder (veya çevrimdışı bir ödemeyi onaylar), ardından teslim edilen öğeler hakkında geri bildirim ve onay bırakır.

Bu akışı oluşturduktan sonra, (davet yeniden gönder, bir satırı netleştir, revizyon iste) gibi destekleyici anları fark edersiniz ve onlar için düzene ihtiyaç duyduğunuzda fazla özellik inşa etmeden çözebilirsiniz.

Ekran haritası (minimum set)

MVP için ekranları odaklı ve yeniden kullanılabilir tutun:

• Gösterge Paneli: aktif projeler, ödenmemiş faturalar ve geri bildirim bekleyen öğelerin listesi.
• Proje detayı: güncelleme, dosyalar/bağlantılar, faturalar ve geri bildirim bölümleriyle genel bakış.
• Fatura düzenleyici: fatura oluştur/düzenle, kalemler, vergiler/indirimler, müşteriye gönder.
• Fatura görünümü: müşteri dostu inceleme, ödeme durumu ve makbuz.
• Geri bildirim dizisi: teslimle bağlantılı yorumlar, onaylar ve revizyon talepleri.

Roller, izinler ve herkesin ne gördüğü

Erişim kurallarını erken tanımlayın ki sonra yeniden tasarlamak zorunda kalmayın:

• Serbest çalışan: projelerine, faturalarına ve ayarlarına tam erişim.
• Müşteri: sadece davet edildiği projeleri, ilgili faturaları ve geri bildirim dizilerini görebilir.

Daha sonra işbirlikçileri eklerseniz, onları “müşteri ama daha fazlası” yerine ayrı bir rol olarak ele alın.

Tutarlı kalan navigasyon

Uygulama boyunca tek bir birincil navigasyon deseni kullanın: Projeler, Faturalar, Geri Bildirim, Hesap. Bir projenin içinde sabit alt gezinme (Özet / Güncellemeler / Faturalar / Geri Bildirim) tutun ki kullanıcılar nerede olduklarını ve nasıl geri döneceklerini her zaman bilsin.

Veri Modeli: Projeler, Faturalar, Müşteriler ve Geri Bildirim

Açık bir veri modeli uygulamanızı öngörülebilir kılar: toplamlar tutar, durumlar mantıklı olur ve sık sorulan sorulara (“Ne gecikmiş?”, “Hangi projeler onay bekliyor?”) karmaşık çözümler olmadan cevap verebilirsiniz.

Temel varlıklar (isimler)

Başlangıç için küçük bir tablo/collection setiyle başlayın ve her şeyi bunların üzerine asın:

• User: oturum açan hesap (serbest çalışan, ekip üyesi, müşteri).
• Client: çalıştığınız şirket/kişi (genellikle bir veya daha fazla müşteri kullanıcısına bağlı).
• Project: işin, kapsamın, takvimin ve faturalamanın konteyneri.
• Milestone: isteğe bağlı, aşamalı teslim ve kısmi faturalama için kullanışlı.
• Invoice: fatura.
• Payment: aldığınız (veya almaya çalıştığınız) ödeme.
• Feedback: teslime bağlı yorumlar, onaylar ve revizyon notları.
• File: yüklenen varlıklar (briefler, taslaklar, ekler).

İlişkiler (nasıl bağlanırlar)

İlişkileri basit ve tutarlı tutun:

• Client birden çok Project sahibi olur
• Project birden çok Milestone içerir
• Project birden çok Invoice içerir
• Invoice birden çok Payment içerir (kısmi ödemeler, tekrar denemeler, iadeler)
• Project (veya Milestone) birden çok Feedback öğesi içerir
• Feedback bir File referans edebilir (ekler)

Başta planlanacak alanlar

UI'nın kullanıcıları yönlendirebilmesi için açık durum alanları kullanın:

• Tarihler: start_date, due_date, issued_at, paid_at
• Durumlar: project_status (active/on-hold/done), invoice_status (draft/sent/overdue/paid), feedback_status (open/needs-changes/approved)
• Para: subtotal, tax_total, discount_total, total (metin notlarından yeniden hesaplamaktan kaçının)
• Her yerde denetim alanları: created_at, updated_at ve isteğe bağlı deleted_at (soft-delete için)

Dosyalar: ikili veriyi başka yerde saklayın

Dosya ikililerini nesne depolamada (ör. S3 uyumlu) saklayın ve veritabanında yalnızca referans tutun:

• file_id, owner_id, project_id
• storage_key (yol), original_name, mime_type, size
• isteğe bağlı checksum ve uploaded_at

Bu veritabanınızı hafif tutar ve indirmeleri, önizlemeleri ve izinleri kontrol etmeyi kolaylaştırır.

Mimari ve Teknoloji Yığını (Basit ama Ölçeklenebilir)

MVP için amaç hız ve netlik: bir kod tabanı, bir veritabanı, tek dağıtım. Yine de daha fazla kullanıcı, ekip üyesi ve entegrasyon eklediğinizde sizi köşeye sıkıştırmayacak şekilde tasarlayabilirsiniz.

Önce monolit, sonra servisler

Serbest çalışan takipçisi MVP'si için modüler monolit genellikle en iyi uzlaşıdır. Tüm backend'i (auth, projeler, faturalar, geri bildirim, bildirimler) tek bir yerde tutun, ama endişeleri modüller veya paketler halinde ayırın. Bunun faydaları:

• Daha hızlı geliştirme (daha az hareketli parça)
• Daha kolay hata ayıklama (isteği izlemek için tek yer)
• Gelecekte temiz bir ayırma (modüller gerektiğinde servislere dönüşebilir)

Daha sonra ayrı servisler gerekirse (örn. ödeme webhook'ları, e-posta/kuyruk işleme, analiz), gerçek kullanım verisi elde ettiğinizde onları dışarı çekebilirsiniz.

Yaygın yığın seçenekleri

Ekiplerin güvenle yayınlayabileceği bir yığın seçin. Tipik, kanıtlanmış kombinasyonlar:

• Ön uç: React veya Vue (her iki framework de pano tarzı uygulamalar için iyi)
• Arka uç: Node.js (Express/Nest), Django veya Rails
• Veritabanı: PostgreSQL

React/Vue müşteri portal deneyimini (yorumlar, dosya yükleri, onay durumları) iyi yönetirken, Node/Django/Rails kimlik doğrulama, arka plan işleri ve yönetici iş akışları için olgun kütüphaneler sunar.

Daha da hızlı gitmek isterseniz—özellikle bu gibi bir MVP için—Koder.ai gibi platformlar, yapılandırılmış bir sohbet özetiyle çalışan bir React ön yüzü ve Go + PostgreSQL backend üretebilir. Bu, proje→fatura→onay iş akışlarını hızlıca doğrulamak istediğinizde ve kaynak kodu dışa aktararak sahiplenmek istediğinizde faydalıdır.

Neden PostgreSQL uygun

Postgres bu ürün için varsayılan olarak iyi çünkü verileriniz doğal olarak ilişkisel:

• Müşterilerin projeleri vardır; projelerin faturaları vardır; faturaların kalemleri vardır; geri bildirim teslimlere bağlanır
• Raporlama istersiniz (aylık gelir, bekleyen faturalar, müşteri aktivitesi)
• Bütünlükten fayda sağlarsınız (yabancı anahtarlar, kısıtlamalar) böylece yetim faturalar veya uyumsuz toplamlar önlenir

Gerekirse esnek alanları (fatura meta verileri gibi) JSON sütunlarıyla saklayabilirsiniz.

Ortamlar ve temel CI hattı

Baştan üç ortam planlayın:

• Local: örnek verilerle ve basit bir posta “havuzu” ile
• Staging: üretime benzer ortamda müşteri önizlemeleri için
• Production: erişimi kilitli, yedeklemeler, izleme

Dağıtımda testler, linting ve migrationları çalıştıran basit bir CI hattı ekleyin. Minimal otomasyon bile faturalama ve geri bildirim akışlarında hızlı iterasyon yaparken hataları azaltır.

Giriş, Hesaplar ve İzinler

Bir serbest çalışan takipçisi karmaşık kimlik yönetimine ihtiyaç duymaz, ancak kimin giriş yapabildiği, ne görebildiği ve hesapların nasıl güvenli tutulduğu konusunda öngörülebilir sınırlar gerekir.

Kimlik doğrulama seçenekleri (başlamak için birini seçin)

Çoğu MVP e-posta + parola ile iyi işler çünkü tanıdık ve desteklemesi kolaydır. İlk günden bir “şifremi unuttum” akışı ekleyin.

Şifre destek taleplerini azaltmak isterseniz, sihirli linkler (e-posta tabanlı giriş linkleri) güçlü bir alternatiftir. Nadiren gelen müşteriler için sürtünmeyi azaltır.

OAuth (Google/Microsoft) kayıt sürtünmesini azaltır, ama kurulum karmaşıklığı ve kenar durumları ekler. Birçok ekip MVP'yi e-posta/parola veya sihirli linklerle çıkarır, sonra OAuth ekler.

Roller ve ne yapabilirler

Rolleri basit ve açık tutun:

• Serbest çalışan (sahip): tam erişim—projeleri oluşturur, faturaları gönderir, müşterileri davet eder, ayarları yönetir.
• Ekip üyesi (isteğe bağlı): projelere/faturalara yardımcı olabilir ama faturalama ayarlarını değiştiremeyebilir veya çalışma alanını silemeyebilir.
• Müşteri (kısıtlı): sadece kendine davet edilmiş projeleri, faturaları, dosyaları ve geri bildirim dizilerini görebilir.

Pratik bir model “çalışma alanı → projeler → izinler” şeklindedir; her müşteri hesabı belirli projelere (veya bir müşteri kaydına) bağlanır ve asla global erişime sahip olmaz.

Atlanmaması gereken güvenlik temelleri

Güvenliği pratik ve tutarlı tutun:

• Parolalar modern bir algoritma ile hashlenmeli (örn. bcrypt/argon2)
• Giriş, şifre sıfırlama ve davet uç noktalarında hız sınırlama
• Güvenli oturumlar (secure cookie, CSRF koruması gerekiyorsa, şifre değişiminde oturum iptali)

Veri gizliliği sınırları

“Müşteri izolasyonunu” pazarlık konusu yapmayın: projeleri/faturaları/geri bildirimleri getiren her sorgu, kimlik doğrulaması yapılmış kullanıcının rolü ve veriye ilişkisi ile sınırlandırılmalı. Yalnızca UI'ya güvenmeyin—bunu backend yetkilendirme katmanında zorunlu kılın.

Serbest Çalışanlar ve Müşteriler İçin İyi İşleyen UX Desenleri

İyi UX çoğunlukla idari işleri azaltmak ve bir sonraki eylemi açık hale getirmektir. Serbest çalışanlar hız ister (bağlam değiştirmeden bilgi yakalamak). Müşteriler ne istendiğini ve sonraki adımın ne olduğunu bilmek ister.

“Bugün ne yapmalıyım?” sorusunu yanıtlayan gösterge paneli

Gösterge panelini bir karar ekranı olarak ele alın, raporlama ekranı değil. Birkaç kart gösterin:

• Yaklaşan son tarihler (önümüzdeki 7–14 gün), projeye tek tıkla erişimle
• Ödenmemiş faturalar durum etiketleriyle (“gönderildi”, “görüldü”, “gecikmiş”) ve “müştiriye hatırlatma” eylemi
• Son geri bildirim böylece bağlam taze iken hızlıca yanıt verilebilir

Okunaklı tutun: her kartı 3–5 öğe ile sınırlayın ve geri kalanı için “Tümünü görüntüle” sunun.

Proje sayfaları: görev yönetimi ağır olmadan zaman çizelgesi + aktivite

Çoğu serbest çalışan tam bir görev sistemine ihtiyaç duymaz. Proje sayfası iyi çalışırsa:

• Kilometre taşları birincil yapı (her biri son tarih ve durumla)
• Hafif görevler sadece bir kilometre taşının içinde (isteğe bağlı, basit onay kutuları)
• Dosyalar kilometre taşına göre gruplanmış, “son sürüm” göstergesi
• Aktivite günlüğü (fatura gönderildi, yorum eklendi, dosya yüklendi) böylece “bunu zaten yaptık mı?” karışıklığı ortadan kalkar

Müşteri portalı: tek, açık yol

Müşteriler yalnızca önemli olanı görmeli: geçerli kilometre taşı, son teslim ve açık eylem çağrıları: Onayla, Yorum Yap, Değişiklik İste, Öde. Navigasyon yükünden kaçının—az sekme, az karar.

Kısa formlar: varsayılanlar, şablonlar ve otomatik doldurma

Her ek alan sizi yavaşlatır. Fatura şablonları, varsayılan ödeme koşulları ve müşteri/proje bilgileriyle otomatik doldurma kullanın. Akıllı varsayılanlar ("Net 7", son kullanılan para birimi, kaydedilmiş fatura adresi) sunun; kullanıcı düzenleyebilsin.

Faturalama Sistemini Kurmak

Faturalama basit bir form gibi hissetmeli ama güvenilir bir kayıt gibi davranmalı. Amacınız serbest çalışanların doğru faturaları hızlı göndermesine yardımcı olmak ve müşterilere ne ödemeleri gerektiğini net göstermek.

Fatura düzenleyici (ne yakalanmalı)

Ortak durumları destekleyen bir düzenleyiciyle başlayın:

• Kalemler: açıklama, miktar, oran, tutar
• Vergiler: fatura başına (örn. KDV) veya satır bazında esneklik gerekiyorsa
• İndirimler: sabit tutar veya yüzde
• Notlar: nazik bağlam (“Ana sayfa metni için hızlı geri bildiriminiz için teşekkürler.”)
• Ödeme koşulları: son tarih, “Net 7/14/30” veya “teslimde ödenir”

Hesaplamaları otomatik ve şeffaf yapın: ara toplam, vergi, indirim, toplam gösterilsin. Yuvarlama tutarlı olsun (para birimi kuralları önemli) ve sürpriz olmaması için fatura başına para birimini kilitleyin.

PDF oluşturma ve gönderme

Çoğu müşteri hala PDF bekler. İki teslim seçeneği sunun:

1. PDF oluşturun ve fatura görünümünü yansıtsın (aynı toplamlar, aynı metin).
2. E-posta ile gönderin veya okunabilir, salt okunur bir paylaşılabilir fatura bağlantısı sağlayın.

E-postaları gönderiyor olsanız bile paylaşılabilir bağlantıyı saklayın. Bu “Yeniden gönderebilir misiniz?” sorularını azaltır ve tek bir doğruluk kaynağı sağlar.

Durumlar ve yaşam döngüsü

Fatura durumunu basit bir durum makinesi gibi ele alın:

• Taslak: düzenlenebilir, müşteriye görünmez
• Gönderildi: e-posta/bağlantı ile iletildi
• Görüldü: müşteri fatura bağlantısını açtı
• Ödendi: ödeme onayı sonrası
• Gecikmiş: son tarih geçti ve ödenmedi
• İptal: silinmeden iptal edildi

Faturaları silmekten kaçının; iptal etmek denetim izini korur ve numaralandırmada boşluk oluşmasını engeller.

Gelecek geliştirmeler (ilk gün inşa etmeyin)

Tekrarlayan faturalar (aylık retainerlar) ve yapılandırılabilir gecikme ücreti kuralları için yer bırakın. Veritabanınızı bu özellikleri sonradan eklerken çekiştirmeyecek şekilde tasarlayın.

Ödemeler ve Güvenilir Ödeme Alma

Ödeme almak uygulamanın değerini kanıtladığı andır. Ödemeleri bir düğmeden ziyade bir iş akışı (fatura → ödeme → makbuz) olarak ele alın ve rakamlara güvenebilmeniz için tasarlayın.

Sağlayıcı seçin ve destekleyeceğiniz yöntemleri belirleyin

Başlangıçta serbest çalışanlarınızın bulunduğu yer ve müşterilerin ödeme tercihleri ile uyumlu tek bir ana sağlayıcı seçin. Birçok MVP için kart ödemeleri ve banka transferi seçenekleri uygundur.

Desteklediğiniz yöntemleri açıkça belirtin:

• Kartlar (hızlı, en yüksek tamamlanma oranı)
• Banka transferi (daha düşük ücret, daha yavaş, büyük müşterilerde yaygın)
• Manuel/çevrimdışı (nakit, çek, “sistem dışında transfer ile ödendi”)

Platform ücreti almayı planlıyorsanız, sağlayıcının modelinizi desteklediğinden emin olun (örn. pazar yeri/bağlı hesaplar vs tek işletme hesabı).

Ödeme durumunu güvenli saklayın (ön yüz tek kaynak olmasın)

Bir ödeme oluşturulduğunda sağlayıcının kimlik bilgilerini sizde saklayın ve nihai durum için sağlayıcı webhook'larını kaynak kabul edin.

En azından kaydedin:

• Fatura ID → sağlayıcı ödeme ID(leri)
• Tutar, para birimi ve zaman damgaları
• Ödeme durumu (pending, succeeded, failed, refunded, partially_paid)
• Denetim ve mutabakat için ham webhook olay günlüğü

Bu, kullanıcı checkout sırasında sekmeyi kapatsa bile fatura toplamlarını gerçek para hareketleriyle eşlemenizi sağlar.

Gerçek dünya kenar durumlarını yönetin

Ödemeler genellikle demodaki gibi davranmaz:

• Kısmi ödemeler: kalan bakiyeyi izleyin ve fatura tam olarak ödenene kadar açık tutun
• Başarısız ödemeler: net bir sonraki adım gösterin (kartı tekrar dene, banka transferi kullan, destekle iletişime geç)
• İadeler: iade edilen miktarı kaydedin ve faturanın yeniden açılıp açılmayacağını belirtin

Çevrimdışı ödemeleri kolaylaştırın (raporlama bozulmadan)

Bazı müşteriler uygulama dışında ödeyecektir. Faturada net banka bilgileri/verileri verin ve “Ödendi olarak işaretle” akışı sağlayın:

• tarih, tutar, yöntem, referans notu isteyin
• İsteğe bağlı olarak bunu yalnızca serbest çalışana (veya yönetime) sınırlayın
• Kim yaptı ve ne zaman yaptığını gösteren bir denetim izi tutun

Bu kombinasyon uygulamanızı müşteri dostu tutar ve raporlama için güvenilir kalır.

Müşteri Geri Bildirim Akışı (Yorumlar, Onaylar, Revizyonlar)

İyi bir geri bildirim akışı projelerin e-posta zincirlerine, “hangi sürüm bu?” karışıklığına veya belirsiz onaylara saplanmasını önler. Amacınız müşterilerin yorum yapmasını kolaylaştırmak, serbest çalışanların yanıtlamasını kolaylaştırmak ve nihai kararı kaybetmeyi zorlaştırmaktır.

Geri bildirim formatları (basit başlayın)

Çoğu MVP iki temel formatı desteklemeli:

• Teslime bağlı dizili yorumlar (örn. “Ana sayfa taslağı”) böylece konuşmalar düzenli kalır
• Kontrol listesi onayları somut onay öğeleri için (örn. “Metin onaylandı”, “Fiyat tablosu doğru”, “Mobil düzen onaylandı”)

İhtiyaç varsa açıklamalı dosya notları (PDF/resim üzerine pin yorumları) daha sonra ekleyin: güçlü ama UI ve depolama karmaşıklığı ekler—faz 2 için daha uygundur.

Onaylar ve revizyon talepleri

Geri bildirimi sadece mesaj değil bir eylem olarak ele alın. UI'da “yorum” ile ayrıştırın:

• Değişiklik iste (bir revizyon öğesi oluşturur ve teslimatı incelemede tutar)
• Onayla (teslimatı onaylanmış olarak kilitler ve yeniden açılmadıkça düzenlemeleri durdurur)

Bu “Güzel görünüyor!” türü belirsizlikleri engeller. Müşterinin net bir onay butonu olmalı ve serbest çalışanlar tam olarak neyin engellediğini görmelidir.

Sürümleme: ne değiştiğini bilin

Her teslimatın sürümleri (v1, v2, v3…) olmalı, hatta sadece bir dosya yükü veya bağlantı saklansın:

• Yeni bir sürüm gönderildiğinde mevcut kontrol listesi durumunun anlık görüntüsünü alın
• Çözülmemiş yorumları taşıyın (veya açıkça çözülmelerini isteyin)
• Müşterilerin daha hızlı incelemesi için kısa bir “Ne değişti” notu ekleyin

Yardımcı bildirimler (spam olmasın)

Eylem gerektiren olaylar için uyarılar gönderin:

• Bahsetmeler (@client, @freelancer) → anlık bildirim
• Onay istekleri → e-posta + uygulama içi rozet
• Yeni yorumlar → toplu e-posta (örn. her 15 dakikada) spamı önlemek için

Karar izini tutun

Her onay veya büyük değişiklik için kaydedin:

• Onaylayan/değişiklik isteyen kişi
• Ne onaylandı (teslimat + sürüm)
• Ne zaman gerçekleşti

Bu iz, zaman çizelgesi kaymaları veya kapsam sorguları durumunda her iki tarafı da korur ve devri kolaylaştırır.

Bildirimler, Hatırlatmalar ve Zamanlama

Bildirimler bir serbest çalışan takipçisini ya yardımcı ya da gürültülü yapar. Amaç basit: doğru kişiye doğru zamanda bir sonraki eylemi yüzeyleştirmek—uygulamayı bir e-posta topuna çevirmeden.

Önemli hatırlatma türleri

Başlangıç için üç yüksek-sinyalli hatırlatmayla başlayın:

• Yaklaşan son tarih: “Fatura #104 üç gün içinde vadesi doluyor” veya “Kilometre taşı incelemesi yarın.”
• Gecikmiş fatura: vade geçtikten sonra kademeli şekilde daha net çağrılarla yükseltin
• Bekleyen onay: teslimatı bloklayan geri bildirim veya onay için müşterilere hatırlatma

Kopyayı spesifik tutun (müşteri adı, proje, son tarih) ki kullanıcılar uygulamayı açmadan ne olduğunu anlasın.

Kanallar: önce e-posta, sonra uygulama içi

MVP için e-posta öncelikli olsun çünkü açık bir sekme gerektirmez. Uygulama içi bildirimleri ikinci adım olarak ekleyin: küçük bir zil ikonu, okunmamış sayısı ve basit bir liste görünümü (“Tümü” ve “Okunmamış”). Uygulama içi durum farkındalığı için iyidir; e-posta zaman duyarlı hatırlatmalar için daha iyidir.

Sıklık kontrolleri ve vazgeçme seçenekleri

Kullanıcılara erken kontrol verin:

• Hatırlatma türüne göre (son tarihler vs onaylar)
• Sıklık seçenekleri (anında, günlük özet, haftalık)
• Net bir vazgeçme

Varsayılanlar temkinli olsun: bir yaklaşan hatırlatma (örn. vade öncesi 3 gün) ve bir gecikme takip hatırlatması (örn. vade sonrası 3 gün) genellikle yeterlidir.

Toplama ve akıllı kurallarla spam'den kaçının

Mümkünse günlük özet gönderin: aynı gün birden fazla öğe tetiklenirse tek bir e-postada toplayın. Sessiz saatler ve “bu öğe için tekrar X'e kadar hatırlatma” gibi kurallar ekleyin. Zamanlama olay odaklı olmalı (fatura vadesi, geri bildirim iste zaman damgası) ki hatırlatmalar zaman çizelmesi değiştiğinde doğru kalsın.

Güvenlik, Güvenilirlik ve Yayın Kontrol Listesi

Bir serbest çalışan takipçisi kişisel veriler, para ve müşteri konuşmalarıyla ilgilenir—bu yüzden birkaç pratik önlem uzun vadede işe yarar. Kurumsal karmaşıklığa gerek yok ama tutarlı temeller şart.

Gönderimle birlikte sunulması gereken güvenlik temelleri

Her yerde girdi doğrulaması ile başlayın: formlar, sorgu parametreleri, dosya yüklemeler ve webhook yükleri. Tip, uzunluk ve izin verilen değerleri sunucuda doğrulayın, UI doğrulamanız olsa bile.

Yaygın web sorunlarına karşı koruyun:

• CSRF koruması (özellikle cookie tabanlı oturum kullanıyorsanız)
• XSS koruması: kullanıcı içeriğini kaçırma ve zengin metni (yorumlar/geri bildirim) göstermeden önce temizleme
• Güvenli başlıklar: Content Security Policy (CSP), HSTS ve frame-ancestors gibi ayarlarla clickjacking riskini azaltma

Ayrıca sırları (API anahtarları, webhook imza sırları) repodan uzak tutun ve gerektiğinde döndürün.

Yedekler ve veri dışa aktarma

İki tür güvenilirlik planlayın: kendi kurtarma süreciniz ve kullanıcı taşınabilirliği.

• Otomatik veritabanı yedekleri ve test edilmiş geri yükleme süreci
• Basit dışa aktarımlar: proje listeleri ve fatura tabloları için CSV, faturalar/makbuzlar için PDF

Dışa aktarmalar destek ve güven inşa eder.

Büyüdükçe akıcı kalan performans

Panolar hız kaybedebilir. Tablolar için sayfalandırma kullanın (projeler, faturalar, müşteriler, geri bildirim dizileri), yaygın filtrelerde indexler (client_id, project_id, status, created_at) ekleyin ve özet widget'lar için hafif cache kullanın (örn. “ödenmemiş faturalar”).

Yayın kontrol listesi (göz ardı edilen ama gerekli)

Duyurudan önce izleme (uptime checks), hata takibi (backend + frontend) ve basit bir destek yolu ile /help benzeri bir sayfa ekleyin.

Koder.ai gibi bir platform kullanıyorsanız, dağıtım/barındırma, anlık görüntüler ve geri alma gibi özellikler yayın riskini azaltabilir—özellikle faturalama ve müşteri portalı akışlarında hızlı iterasyon yapıyorsanız. Son olarak, iş tarafını anlamayı kolaylaştırmak için uygulamanızdan ve pazarlama sayfalarından /pricing bağlantısı vermeyi düşünün.