10 يوليو 2025·8 دقيقة
كيفية إنشاء تطبيق جوال لتقسيم نفقات السفر
تعلم كيفية تخطيط وتصميم وبناء تطبيق لتقسيم نفقات السفر: الميزات الأساسية، نموذج البيانات، عملات متعددة، وضع عدم الاتصال، طرق التسوية، الاختبار والإطلاق.
تعلم كيفية تخطيط وتصميم وبناء تطبيق لتقسيم نفقات السفر: الميزات الأساسية، نموذج البيانات، عملات متعددة، وضع عدم الاتصال، طرق التسوية، الاختبار والإطلاق.
قبل أن ترسم الشاشات أو تناقش التقنية، حدد بوضوح مؤلم من يخدمه التطبيق وما اللحظات التي يجب أن يحسّنها. يبدو تقسيم النفقات "بسيطًا" حتى تبدأ رحلة حقيقية وتدخل عملات مختلطة، ونصف مدفوعات، وشخص يفقد إيصالًا.
تقع معظم تطبيقات تقسيم نفقات السفر ضمن مجموعات مستخدمين متكررة. اختر مجموعة أساسية أولاً (يمكنك التوسيع لاحقًا):
لكل مجموعة توقعات مختلفة. قد يريد الأصدقاء السرعة والنبرة الخفيفة؛ أما الفرق فقد تطالب بالتدقيق والأذونات وسجلات قابلة للتصدير.
وثق أوضاع المستخدمين الفوضوية التي يشتكون منها:
حوّل هذه إلى سيناريوهات يمكنك اختبارها مع أشخاص حقيقيين (حتى 5–10 مقابلات).
ضع أهدافًا قابلة للقياس للنسخة الأولى:
هذه المقالة هي خريطة طريق عملية شاملة — من الفكرة وتحديد MVP مرورًا بحالات الحافة، تدفق تجربة المستخدم، المنطق، وأخيرًا الاختبار والإطلاق. إذا بدأت بالمستخدمين والمشاكل الصحيحة، تصبح كل قرار لاحق أسهل.
الـMVP لتطبيق تقسيم نفقات السفر ليس "تطبيقًا أصغر"؛ إنه إصدار يحل بشكل موثوق الوظيفة الوحيدة التي يحتاجها المستخدم في الرحلة: تسجيل الإنفاق المشترك وإظهار من يدين بماذا—بدون مجادلات.
ابقِ النطاق ضيقًا ومركزًا على النتيجة. يمكن لإصدار قوي أولًا أن ينجح ببعض الإمكانيات البسيطة:
إذا تمكنت من تنفيذ هذه الأشياء الخمس بسلاسة، فلدیک تطبيق لتقسيم النفقات يسمح للمستخدمين بإنهاء رحلة.
العديد من الميزات تبدو "ضرورية" لكنها يمكن تأجيلها حتى تتحقق صحة التدفق الأساسي:
ينبغي أن يفضل الـMVP السرعة والوضوح على الاكتمال.
اكتب قصص المستخدم بلغة يومية حتى يتمكن أي شخص في الفريق من الحكم على ما إذا كان التطبيق يُلبي الحاجة:
لكل قصة، حدد فحوصات ملموسة. مثال على "تقسيم العشاء":
هذه الطريقة تمنع توسع النطاق بينما تبني تطبيقًا موثوقًا.
ينجح تطبيق تقسيم النفقات عندما يسمح لمجموعة بتسجيل الإنفاق بسرعة ويثق الناس في الحسابات. قبل إضافة "ميزات لطيفة"، تأكد أن مجموعة الميزات الأساسية تغطي كيفية سير الرحلات الحقيقية: عدة أشخاص، العديد من المشتريات الصغيرة، ولحظات متكررة من "سنجمعها لاحقًا".
يجب أن يتمكن المستخدمون من إنشاء رحلات متعددة (مثلاً "لشبونة 2026") ودعوة الآخرين برابط بسيط أو رمز. بمجرد انضمام شخص ما، يصبح عضوًا في الرحلة ويمكن إضافته للمصاريف.
اجعل إدارة الأعضاء خفيفة الوزن: إعادة تسمية الأعضاء، إزالة من غادر مبكرًا، وخيار تعيين أدوار (مسؤول مقابل عضو) إذا رغبت في مزيد من التحكم.
كل مصروف يحتاج إلى هيكل يكفي ليظل مفيدًا بعد أسابيع:
سجل سريع أهم من بيانات مثالية. الإعدادات الافتراضية الذكية (آخر دافع، آخر مشاركين) تقلل النقرات.
التقسيم المتساوي هو الافتراضي، لكن الرحلات تحتاج مرونة بسرعة. ادعم:
يجب أن يجيب التطبيق دائمًا: "من يدين لمن وبكم؟" قدم إجماليات لكل شخص، إجمالي الرحلة، وعرض رصيد واضح يجمع الديون تلقائيًا (حتى لا يلاحق المستخدمون مدفوعات صغيرة متعددة).
دع المستخدمين يسجلون السدادات: علم بأنها مدفوعة، خزن المبلغ/التاريخ، وخيارًا طريقة الدفع (نقدًا، تحويل بنكي، باي بال). للسكون النفسي، اسمح بإرفاق دليل (لقطة شاشة أو ملاحظة)، لكن اجعلها اختيارية للحفاظ على سرعة التسوية.
العملات المتعددة هي النقطة التي يصبح فيها التطبيق ساحرًا أو مصدر مشاحنات. يمكنك منع معظم لحظات "انتظِ، دفعت أكثر" بأن تكون صريحًا بشأن العملة التي يمثل كل رقم وكيفية تحويلها.
عامل كل مصروف على أنه له عملة المعاملة (ما دُفع فعليًا في المتجر) وعملة منزل الرحلة (ما يستخدمه الفريق لمقارنة الإجماليات).
مثال: عشاء بقيمة €60 (عملة المعاملة)، لكن عملة المنزل هي USD، لذا يعرض التطبيق €60 → $65.40 (محولًا) بينما يحتفظ بالأصل €60 للشفافية.
عادة لديك خياران جيدان:
أيا كانت الاستراتيجية، اعرض السعر والطابع الزمني في تفاصيل المصروف (مثلاً: “1 EUR = 1.09 USD • 2025-12-26”). إذا دعمت التعديلات، دع المستخدمين يثبتون سعرًا لكل مصروف.
التقريب ليس تفصيلًا—إنها سياسة. استخدم قواعد متسقة:
ادعم:
نموذجها كـ بنود منفصلة (الأفضل للوضوح) أو تعديلات مرتبطة بالمصروف. هذا يساعد عندما يشارك البعض فقط في الإكرامية، أو عندما تنطبق خصومات على عناصر محددة (مثلاً "الأطفال يأكلون مجانًا").
يفوز تطبيق سفر أو يخسر بالسرعة. يسجل الناس التكاليف في التاكسي، الطوابير، أو مطاعم صاخبة—يجب أن يشعر تدفقك كما لو أنك تكتب ملاحظة، لا تملأ نموذجًا.
ابدأ بمجموعة صغيرة من الشاشات التي يمكن للمستخدم تعلمها خلال رحلة واحدة:
صمم شاشة "إضافة مصروف" حول إعدادات افتراضية ذكية:
قاعدة جيدة: يجب أن يكون المستخدم قادرًا على حفظ مصروف شائع في 10–15 ثانية.
تجنب التسميات الغامضة. "دُفع بواسطة" و "مطلوب من" تقللان الأخطاء مقارنةً بـ "من/إلى". أظهر صف تأكيد مدمج قبل الحفظ: المبلغ، الدافع، ومن شمل.
إذا بدا شيء غير اعتيادي (مثلاً شخص واحد فقط مدين)، قدّم تلميحًا لطيفًا: "هل تريد تقسيمه مع أليكس فقط؟"
يجب أن تدعم تفاصيل الرحلة فحوصات سريعة: فلاتر (حسب الشخص، الفئة، التاريخ) وعرض لكل شخص حتى يرى أحدهم "كم أدين؟" بدون حساب يدوي. خلاصة النشاط تبني الثقة، خصوصًا عند التعديلات.
استخدم تباين قابل للقراءة، أهداف نقر كبيرة، وإشارات واضحة لحالة الاتصال (مثلاً "محفوظ على الجهاز—سيتم المزامنة لاحقًا"). ظروف السفر غير متوقعة؛ واجهة المستخدم لا ينبغي أن تكون كذلك.
تعيش أو تموت تطبيقات تقسيم النفقات بسرعة دخول المجموعة إلى نفس الرحلة. قرارات الحساب والدعوة يجب أن تقلل الاحتكاك، لا تضيفه.
لـMVP، عادة تريد أبسط خيار يبدو موثوقًا:
حل عملي: Apple/Google + رابط سحري. من لا يريد حسابًا يمكنه الانضمام عبر الرابط، بينما يمكن للمستخدمين العاديين ربط تسجيل حقيقي لاحقًا.
ابدأ بـ رابط دعوة قابل للمشاركة يُدخل الشخص مباشرةً في الرحلة. أضف رمز QR للحظات الجماعية (منصة القطار، تسجيل الوصول بالنزل). دعوات قائمة جهات الاتصال لطيفة لكنها تضيف مطالبات أذونات وحالات حافة—غالبًا ليست ضرورية مبكرًا.
اجعل الروابط آمنة زمنيًا:
تتضمن العديد من المجموعات شخصًا لن يثبت التطبيق أو يرفض التسجيل. قرر مسبقًا إذا كنت تدعم:
قاعدة MVP شائعة: يمكن للضيوف العرض وإضافة مصاريف فقط عبر جلسة الرابط، لكن لا يمكنهم حذف بنود أو تغيير إعدادات الرحلة.
تحتاج لقواعد واضحة حول من يستطيع تعديل ماذا:
هذا يمنع التعديلات العرضية (أو المتعمدة) مع الحفاظ على سرعة التدفق.
المجموعات الحقيقية تتحرك سريعًا. عالج التعديلات بسلوك متوقع:
الهدف ليس نظام تحكم بالإصدارات مثالي—بل منع المشاحنات والحفاظ على سير الرحلة.
نموذج بيانات نظيف يجعل التطبيق متوقعًا: كل شاشة، حساب، تصدير، وميزة مزامنة تعتمد عليه. لا تحتاج لعشرات الجداول—فقط اللبنات الصحيحة وقواعد واضحة.
عمليًا، عادة ما يحتاج التطبيق إلى:
التعديلات هي المكان الذي تبلبل فيه التطبيقات. نهجان شائعان:
وسط جيد: اسمح بالتحرير، لكن احتفظ بسجل خفيف للحقول التي تؤثر على المال (المبلغ، العملة، الدافع، التقسيمات).
احسب الأرصدة لكل رحلة كالتالي:
ثم "تسوَّى" الأرصدة عبر التصفية: طابق الأشخاص الذين يدينون مع من لهم حق لإنتاج أقل عدد من التحويلات.
أعضاء الرحلة: ألكس (A)، بلير (B)، كيسي (C). كل التقسيمات متساوية بين المشاركين.
عشاء $60 دفعه A (A,B,C) → كل واحد يدين $20
تاكسي $30 دفعه B (B,C) → كل واحد يدين $15
متحف $45 دفعه C (A,C) → كل واحد يدين $22.50
بقالة $90 دفعه A (A,B,C) → كل واحد يدين $30
النتائج الصافية:
التسويات (بعد التصفية): B → A $35.00، C → A $42.50.
عامل الإيصالات كمرفقات مرتبطة بالمصروف: خزن عنوان/مفتاح الصورة، صورة مصغرة, uploaded_by, created_at, وبيانات OCR اختيارية (التاجر، المبلغ المكتشف، الثقة).
اجعل Expense قابلًا للاستخدام حتى لو كانت الصورة ما زالت تُرفع (أو عند عدم الاتصال) بفصل سجل المرفق عن الحقول الأساسية للمصروف.
خياراتك التقنية يجب أن تخدم المنتج: محفظة رحلة مشتركة سريعة الاستخدام على الطريق، تعمل باتصال متقطع، وتحافظ على أرصدة متسقة.
إذا أردت الانتقال بسرعة من المواصفات إلى تطبيق يعمل، أدوات تضغط التخطيط والتنفيذ تفيد كثيرًا. على سبيل المثال، Koder.ai هي منصة vibe-coding حيث يمكنك وصف التدفقات (رحلات، مصاريف، أرصدة، تسوية) في محادثة، التكرار في وضع التخطيط، وتوليد ستاك تطبيق حقيقي (React للويب، Go + PostgreSQL للباك اند، وFlutter للموبايل). ليست بديلاً عن قرارات المنتج الجيدة—لكن يمكنها تقليل الوقت بين "اتفقنا على الـMVP" و"لدينا شيء قابل للاختبار"، خصوصًا مع لقطات واسترجاع للتغييرات.
إذا أردت أفضل تكامل مع الكاميرا والتخزين دون اتصال وتكاملات نظام التشغيل، فـNative iOS (Swift) وAndroid (Kotlin) خيارات قوية—بتكلفة وجود قاعدتي كود.
لأغلب الفرق، العبور عبر المنصات (Flutter أو React Native) هو حل عملي لتطبيق تقسيم النفقات: طبقة واجهة موحدة، تكرار سريع، وأداء جيد.
نهج الويب-أول (تطبيق ويب سريع الاستجابة) يمكنه التحقق من ميزات الميزانية الجماعية بسرعة، لكن دون اتصال والتقاط الإيصالات عادة ما يكونان أقل سلاسة.
حتى محفظة مشتركة بسيطة تستفيد من باك اند لـ:
تتبع هذا كميزة جوهرية. استخدم قاعدة بيانات محلية (SQLite/Realm) وصمم:
اجعل النهايات بسيطة ومتوقعة:
/trips, /trips/{id}/members/trips/{id}/expenses/trips/{id}/balances/trips/{id}/settlementsهذا الهيكل يتطابق بسلاسة مع خوارزمية تقسيم المصاريف وميزات لاحقة مثل التسوية وتتبع العملات المتعددة.
Mobile App (UI)
-> Local DB + Sync Queue
-> API Client
-> Backend (Auth, Trips, Expenses, Balances)
-> Database
-> File Storage (receipts)
-> Notifications
احتفظ بهذا المخطط مرئيًا أثناء التطوير—سيمنع "الحلول السريعة" التي تعقّد الـMVP.
الإيصالات هي الفرق بين "نعتقد أن الحساب صحيح" و"نعلم أنه صحيح". تقلل النزاعات بعد يوم سفر طويل—خصوصًا عندما يدفع الناس نقدًا، يتشاركون بطاقات، أو يشترون بعملات مختلفة.
اجعل إضافة إيصال جزءًا من إضافة المصروف، لا مهمة منفصلة. يجب أن يكون التدفق: افتح الكاميرا → التقط → قص/تدوير سريع → إرفاق بالمصروف.
بعض التفاصيل العملية تهم:
OCR مفيد، لكن فقط إذا كان موثوقًا. استخدمه لاقتراح حقول مثل المبلغ الإجمالي واسم التاجر، ثم تطلب تأكيد المستخدم قبل الحفظ.
نمط جيد: اعرض القيم المستخرجة كـ "شرائح" قابلة للتحرير (مثلاً "المجموع: 42.80"، "التاجر: Café Rio"), ودع المستخدم يصححها بسرعة. إذا فشل OCR، يجب أن يتمكن المستخدم من إتمام الإدخال في ثوان.
املأ التاريخ/الوقت تلقائيًا من الجهاز واقترح موقعًا (المدينة أو المكان) إن توفر. اسمح دائمًا بالتعديل—فالمستخدمين غالبًا ما يسجلون المصاريف لاحقًا أو في يوم مختلف.
استخدم الإشعارات للأحداث التي تغيّر ما يجب أن يفعله الآخرون:
قد تحتوي الإيصالات على تفاصيل بطاقات، عناوين فنادق، أو عناصر شخصية. فكر بتبديل بسيط لكل مصروف: مشاركة الإيصال مع المشاركين، أو إخفاء الصورة مع مشاركة الأرقام فقط. هذا يبقي الثقة عالية دون منع المجموعة من تتبع الإجماليات.
تقسيم ممتاز لا يشعر بالانتهاء حتى يعرف الناس كيف يعيدون أموال بعضهم البعض—ويستطيعون إثبات ذلك لاحقًا. هنا يتحول التطبيق من حسابات إلى إغلاق.
لديك خياران صالحان:
إذا اخترت الروابط، اجعلها معيارية ومراعية لكل منطقة (دون وعد بالتوافر). خيارات شائعة:
دع المستخدمين يسجلون مدفوعات متعددة لكل شخص، بما في ذلك مبالغ جزئية. مثال: "سام دفع لجوردان $20 نقدًا" زائد "سام دفع $15 عبر تحويل بنكي" حتى يصل الرصيد إلى صفر. أظهر دائمًا:
قدم تصديرات للسداد وسجلات:
تضمن العملة، أسعار الصرف (إن استُخدمت)، ومن دفع.
يجب أن يكون الإغلاق متعمدًا:
يجب أن تبقى الرحلات المؤرشفة قابلة للبحث والمشاركة، لكن محمية من التعديلات العرضية ما لم يُعدّ المالك فتحها.
تتعامل تطبيقات تقسيم النفقات مع بيانات أكثر حساسية مما يتوقع الناس: من سافر مع من، أين ذهبوا، كم أنفقوا، وغالبًا صور إيصالات قد تتضمن أرقام هواتف أو تفاصيل بطاقات أو عناوين. بناء الثقة مبكرًا يقلل التسرب ومطالبات الدعم لاحقًا.
احمِ البيانات أثناء النقل والتخزين على الأجهزة والخوادم:
قد تلتقط الإيصالات أرقام هواتف، أرقام ولاء، توقيعات، أو أرقام بطاقات جزئية. قدم أدوات تحكم بسيطة:
قد يتوقع المستخدمون حذف الرحلة بعد التسوية:
تتبع صحة المنتج مع احترام الخصوصية. ركز على استخدام الميزات (مثلاً "أضاف مصروف"، "أنشأ رحلة"، "صدر") بدلًا من التفاصيل الشخصية أو محتوى الإيصالات. تجنّب جمع الموقع الدقيق إلا إذا كان ميزة جوهرية وبتفعيل صريح.
يمكن استغلال الدعوات والملاحظات المشتركة. أضف حدودًا لمعدل الدعوات، تحقق للحسابات الجديدة، وتدفقًا بسيطًا للحظر/الإبلاغ. بالنسبة للمحتوى المشترك، طبق حماية أساسية (حدود نوع الملف، حدود الحجم، وفحص) لتقليل التحميلات الضارة.
إطلاق تطبيق تقسيم نفقات السفر يتعلق أكثر بالثقة: إن كانت الحسابات خاطئة (أو اختفت البيانات)، لن يعود المستخدمون. عامل الاختبار والإطلاق كميزات منتج.
بِنِ اختبار وحدات حول خوارزمية تقسيم المصاريف حتى يكون كل تغيير آمنًا. غطِّ:
ضمّن حالات قبيحة: عناصر مجانية، عمليات استرداد/مصاريف سالبة، إدخالات مكررة، وتعديلات بعد التسوية.
تظهر معظم الأخطاء في الأفعال اليومية، لا في الحسابات. أضف اختبارات تكامل لـ:
شغّل بيتا صغير مع مجموعات تسافر. تحقق من:
حضّر أصول متجر التطبيقات، توجيه للمستخدم، ومركز مساعدة خفيف (حتى صفحة /help). أضف بريد دعم واختصارًا داخل التطبيق "إرسال ملاحظات".
بعد الإطلاق، راقب التفعيل (أول رحلة مُنشأة)، الاحتفاظ (إعادة فتح الرحلة)، ولحظة "التسوية". أعط أولوية للإصلاحات التي تقلل معدلات الإقلاع: مطالبات العملة المربكة، بطء إضافة المصروف، وفشل الدعوات—ثم كرر بإصدارات صغيرة وقابلة للقياس.
إذا كنت تبني بسرعة وتختبر كثيرًا، فكر في أدوات تدعم التكرار الآمن—لقطات واسترجاع (مثل ما توفره Koder.ai) قد تكون مفيدة خاصة عند نشر تغييرات متكررة على منطق حساس مثل الأرصدة والتسويات.
ابدأ باختيار المجموعة الأساسية (أصدقاء، أزواج، عائلات، أو فرق) وقم بإجراء مقابلات مع 5–10 أشخاص. اجمع أكثر السيناريوهات فوضويةً (عملات مختلطة، استثناءات، فواتير مدفوعة جزئيًا، إيصالات مفقودة) وحولها إلى حالات اختبار لتجربة المستخدم والحسابات.
يمكن أن ينجح MVP عملي بخمسة تدفقات أساسية:
إذا كانت هذه الإجراءات سريعة وموثوقة، يمكن للمستخدمين إنهاء رحلة من البداية للنهاية.
اجّلنَ أي شيء لا يساعد مباشرةً المستخدمين على تسجيل النفقات وبناء ثقة في "من يدين بما"، مثل:
تحقق من السرعة والدقة أولاً؛ أضف الأتمتة بعد إثبات التدفق الأساسي.
ادعم طرق التقسيم التي يستخدمها الناس في الرحلات الحقيقية:
حافظ على واجهة بسيطة باستخدام إعدادات افتراضية ذكية وتذكر آخر طريقة مستخدمة.
خزن كلا الحقلين:
أظهر المبلغ الأصلي والقيمة المحوَّلة، وبيّن سعر الصرف والطابع الزمني. اختر استراتيجية واحدة—سعر ثابت وقت الإدخال (مستقر) أو تحديث يومي (ديناميكي)—واجعلها واضحة لكل مصروف.
حدد سياسة تقريب وطبقها باستمرار:
الاتسConsistency أهم من القاعدة نفسها.
صمم الإدخال ليُستخدم بيد واحدة وبمستوى انتباه منخفض:
استهدف حفظ المصروفات الشائعة في ~10–15 ثانية.
استخدم أقل عائق لإنضمام المجموعة مع شعور موثوق:
للسيطرة، اجعل القواعد متوقعة:
وأضف إمكانية إبطال/إعادة توليد الروابط إذا نُشرت عن طريق الخطأ.
احسب لكل رحلة كالتالي:
للتسويات، قم بعملية تصفية (netting) لمطابقة المدينين مع الدائنين لإنتاج أقل عدد من التحويلات وسجل "أ دفع ب $X" لتقليل الأرصدة.
عاملها كميزة أساسية، لا ملحقًا:
يجب ألا يفقد المستخدمون الإدخالات لمجرد انقطاع الاتصال.