Veloria
موقع تسويقي ومسار تسجيل في قائمة الانتظار وصفحات امتثال لمتطلبات متاجر التطبيقات لشركة ناشئة في مجال صحة المرأة.
VELORIA
Your Pleasure, No Pain
- طرق التحقق
- 3
- تبعيات الإنتاج
- 4
- باقات الأسعار
- 3
- العميل
- Veloria
- القطاع
- صحة المرأة · FemTech
- المؤسِّسة
- Alexandra Prochshenko
- الحالة
- مكتمل
- المدة
- أبريل 2026 · نحو 3 أسابيع
- النطاق
- موقع تسويقي، مسار تسجيل في قائمة الانتظار وصفحات امتثال
01 نظرة عامة
من هو العميل؟
Veloria شركة ناشئة في مجال صحة المرأة تبني تطبيقًا للجوال للنساء اللواتي يعانين من التشنج المهبلي وألم الفرج وتشنج عضلات الحوض وألم الإيلاج والقلق المرتبط به، ويجمع بين جلسات صوتية يومية موجَّهة للعلاج بالتنويم الإيحائي وتمارين العلاج الطبيعي (تمارين التنفس والتوسيع التدريجي) وأسئلة للتأمل الذاتي، تحت شعار «your pleasure with no pain». يمتد الفريق بين فانكوفر وكالغاري وتورنتو ويضم أخصائيَّ علاج طبيعي متخصصًا في قاع الحوض. غطّى هذا التعاون جانب الويب من الإطلاق: الموقع العام الذي يشرح المنتج، ويجمع جمهور ما قبل الإطلاق، ويعرض الأسعار، ويستوفي المتطلبات القانونية ومتطلبات متاجر التطبيقات التي لا يستطيع تطبيق الجوال الإطلاق من دونها.
02 بيان المشكلة
ما المشكلة التي واجهوها؟
كانت Veloria تستعد لإطلاق تطبيق في فئة تكون فيها الثقة كل شيء ويصعب فيها الحديث عن الموضوع. وكانت تحتاج من الويب إلى ثلاثة أمور: موقع يخاطب موضوعًا طبيًا حسّاسًا بدفء ومصداقية معًا، وجمهور يتكوّن قبل وجود التطبيق ليستقبل إطلاقه، وعقبات الإطلاق غير البرّاقة التي لن تمرّرها Apple وGoogle.
الثقة قبل الاشتراك
تحتاج المرأة التي تبحث عن حلّ لهذه المشكلة إلى أن تشعر بأنها مفهومة قبل أن تفكر في تطبيق لهذه المشكلة. كان على الموقع أن يسمّي الحالات بوضوح وأن يضع وجوهًا حقيقية وراء المنتج، من دون أن ينزلق إلى البرود السريري أو إلى ليونة غير مستحقة.
لا جمهور قبل الإطلاق
لم يكن التطبيق قد أُطلق بعد، فكانت مهمة الموقع تحويل الاهتمام إلى قائمة انتظار يستطيع الفريق استهدافها تسويقيًا فعلًا، بموافقة سليمة، وتتدفق مباشرة إلى منصة البريد الإلكتروني الخاصة بهم بدل جدول بيانات يضطر أحدهم إلى تصديره.
مسار حذف الحساب مطلوب في متاجر التطبيقات
تشترط كلٌّ من Apple وGoogle مسار حذف حساب عامًا يعمل فعليًا قبل أن توافقا على تطبيق صحي. لا صفحة، لا إدراج في المتجر. ويجب أن يتعامل المسار مع حسابات Google وApple وحسابات البريد الإلكتروني العادية.
لا تسعير علني ولا صفحات قانونية
لم تكن أسعار الاشتراك منشورة في أي مكان، ولم تكن سياسة الخصوصية وشروط الخدمة التي يعتمد عليها تقديم التطبيق إلى المتجر موجودة بعد.
03 الحل
كيف حللناها؟
بنينا الموقع كتطبيق Next.js خفيف: صغير عن قصد، وسريع، ويضع المحتوى أولًا. أربع تبعيات إنتاج، ومحتوى ثابت داخل الشيفرة، ولا نظام إدارة محتوى ولا لوحة التحكم، فموقع ما قبل الإطلاق ومحتواه قلّما يتغيّر لن يستخدمهما.
تقود الصفحة الرئيسية الزائرة عبر المسار العاطفي للمنتج: قسم رئيسي (hero) بعنوان يظهر بتأثير الآلة الكاتبة، وقسم أعراض يسمّي ما قد تمرّ به، وقسم حلول يشرح مساري البرنامج وتمرين التأمل الذاتي «understanding your why»، وقسم «كيف يعمل» يعرض الروتين اليومي، وقسم الفريق الذي يعرّف بالمؤسِّسة والخلفيات السريرية. ويميل التصميم إلى النعومة: رسوم زهرية وألوان دافئة، بما يناسب النبرة المطمئنة التي يتطلبها الموضوع.
نموذج قائمة الانتظار مُعدّ للتسويق منذ اليوم الأول. تمرّ عمليات الإرسال عبر مسار API من جهة الخادم إلى Brevo ومعها الاسم الأول واسم العائلة والبريد الإلكتروني وموافقة صريحة على تلقي الرسائل التسويقية، ولا يُرسَل النموذج من دون هذه الموافقة. ويعمل التحقق من الصحة في الوقت الفعلي أثناء كتابة الزائر، وتُعرض الأخطاء القادمة من Brevo عرضًا سليمًا، وتُحدِّث التسجيلات المكرّرة جهة الاتصال الحالية بدل أن تفشل.
أكثر ما بُذل فيه من هندسة هو مسار حذف الحساب في /delete-me، المبني ليستوفي متطلبات Apple وGoogle. يتحقق المستخدم من ملكية الحساب بإحدى الطرق الثلاث الآتية: Google أو Apple أو رمز من ستة أرقام يصله بالبريد الإلكتروني عبر نقاط نهاية مخصصة في PocketBase، مع مهلة مدتها 60 ثانية لإعادة الإرسال، ثم يكتب تأكيدًا صريحًا قبل تنفيذ الحذف. وتكتمل مجموعة الامتثال بصفحتي سياسة الخصوصية والشروط.
- Site Next.js 16 الموقع التسويقي العام React 19Tailwind v4
- API Server API Route /api/waitlist → Brevo مشروط بالموافقةالمفتاح يبقى على الخادم
- PB PocketBase الواجهة الخلفية الحالية للتطبيق التحقق برمز البريد الإلكترونيمهلة 60 ث
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS v4
- PocketBase SDK
- Brevo API
- Server-side API Routes
الصفحات المنشورة: بُنيت وأُطلقت
04 الجدول الزمني للمشروع
أبرز المعالم والمدة
المرحلة 1 6–15 أبريل 2026
التصميم والصفحة الرئيسية
هيكل الموقع والتوجّه البصري والصفحة الرئيسية كاملة بأقسامها: القسم الرئيسي (hero) والأعراض والحلول و«كيف يعمل» والفريق والتواصل، إضافة إلى شريط التنقل والتذييل.
المرحلة 2 15–20 أبريل 2026
قائمة الانتظار والأسعار
تكامل Brevo مع مسار API من جهة الخادم، ونموذج مشروط بالموافقة مع التحقق من الصحة في الوقت الفعلي ومعالجة للأخطاء، وصفحة الخطط.
المرحلة 3 20–24 أبريل 2026
الامتثال والتحضير للإطلاق
سياسة الخصوصية والشروط، ومسار حذف الحساب بثلاث طرق للتحقق، مبنيًا على الواجهة الخلفية للتطبيق (PocketBase).
05 التحديات وحلولها
ما العقبات التي واجهتنا وكيف تجاوزناها؟
دفء من دون فقدان المصداقية
المشكلةالمواضيع الصحية بهذه الدرجة من الخصوصية يسهل الخطأ فيها في الاتجاهين: إن بالغ الموقع في الطابع السريري بدا باردًا، وإن بالغ في النعومة فقد مصداقيته.
الحلفصل بنيوي: نسمّي الحالات صراحةً في قسم الأعراض لتجد الزائرة وضعها بكلمات واضحة، ثم نؤسس الحل على مكوناته السريرية: العلاج بالتنويم الإيحائي، والعلاج الطبيعي، وأخصائي علاج طبيعي متخصص في قاع الحوض مذكور بالاسم، فيتحمّل الدفء والمصداقية أقسامًا مختلفة بدل أن يتنافسا في الجملة نفسها.
قائمة انتظار آمنة للاستخدام التجاري
المشكلةجمع عناوين البريد الإلكتروني لمنتج صحي يعني أن الموافقة لا يمكن افتراضها: خانة الموافقة وحدها لا تكفي ما لم تُفرض وتُسجَّل تسجيلًا سليمًا.
الحلالموافقة إلزامية ومخزَّنة كسمة في جهة الاتصال، والنموذج معطّل إلى أن تُحدَّد الخانة. وتمرير الإرسال عبر مسار API من جهة الخادم يُبقي بيانات الاعتماد سرّية ويمنحنا مكانًا لترجمة رموز أخطاء Brevo إلى رسائل يستطيع الزائر أن يتصرف وفقها.
كان على الحذف أن يعمل مع ثلاثة أنواع من المستخدمين
المشكلةبعض المستخدمين يسجّلون عبر Google وبعضهم عبر Apple وبعضهم بالبريد الإلكتروني العادي، ويحتاج كلٌّ منهم إلى إثبات ملكية مختلف قبل تنفيذ حذف حساب لا يمكن التراجع عنه.
الحليعيد مستخدمو OAuth المصادقة لدى مزوّد حساباتهم؛ أما مستخدمو البريد الإلكتروني فيحصلون على رمز لمرة واحدة مع مهلة لإعادة الإرسال تمنع تكرار الطلبات المتتالية. وتلتقي الطرق الثلاث عند خطوة التأكيد بالكتابة نفسها، لأن حذف حساب صحي ينبغي ألا يكون على بعد لمسة غير مقصودة.
إبقاء موقع ما قبل الإطلاق صغيرًا
المشكلةكان من السهل أن يُزوَّد موقع شركة ناشئة بنظام إدارة محتوى ولوحة التحكم ومكتبة مكوّنات، وكلها مرتفعة التكلفة في الاستضافة وفيها الكثير مما قد يتعطل.
الحللم يُنفَّذ شيء من ذلك. بضع صفحات، وأربع تبعيات إنتاج، ومحتوى ثابت داخل الشيفرة. وبالنسبة إلى موقع ما قبل الإطلاق قلّما يتغيّر محتواه، فهذا أقل تكلفة في التشغيل ولا يكاد يوجد فيه ما قد يتعطل.
06 قبل وبعد
مقارنة بين الوضع قبل المشروع وبعده
| قبل | بعد |
|---|---|
| الحضور على الويب: لا يوجد | موقع تسويقي متكامل بسرد مصمَّم لموضوع صحي حسّاس |
| بناء الجمهور: لا آلية لجمع بيانات الزوار | قائمة انتظار مشروطة بالموافقة تتدفق مباشرة إلى منصة التسويق عبر البريد الإلكتروني |
| الأسعار: غير معلنة | صفحة خطط بثلاث باقات: 9$ شهريًا، و24$ كل 3 أشهر، و54$ سنويًا |
| الجاهزية لمتاجر التطبيقات: متعطّلة، لا مسار للحذف ولا صفحات قانونية | مسار حذف متوافق مع المتطلبات (التحقق عبر Google وApple والبريد الإلكتروني) مع سياسة الخصوصية والشروط |
| أمان بيانات الاعتماد: — | جميع مفاتيح الجهات الخارجية على الخادم فقط |
07 فوائد العميل ونتائجه
ما القيمة التي حصل عليها العميل؟
- طرق التحقق
- 3
- Google · Apple · رمز البريد الإلكتروني
- باقات الأسعار
- 3
- $9 · $24 · $54 CAD
- تبعيات الإنتاج
- 4
- next · react · react-dom · pocketbase
- مهلة إعادة الإرسال
- 60 ث
- منع تكرار طلبات رموز البريد
يمكن للتسويق أن يبدأ قبل إطلاق التطبيق
كل زائر يجلبه الفريق إلى الموقع يمكن أن يتحول إلى جهة اتصال حاصلة على موافقة صحيحة في منصة البريد الإلكتروني الخاصة بالفريق نفسه، بلا تصدير ولا إدارة يدوية للقوائم. وهذا يعني أن الإطلاق يجد جمهورًا متفاعلًا بدل أن يبدأ من الصفر.
مسار متاجر التطبيقات لم يعد معطّلًا
مسار الحذف والصفحات القانونية من المتطلبات التي تؤخّر الإطلاق أسابيع حين تُكتشف في وقت متأخر؛ وهي هنا منجزة ومنشورة ومبنية على الواجهة الخلفية الحقيقية للتطبيق (PocketBase).
تكلفة التشغيل شبه معدومة
لا بنية تحتية تحتاج إلى مراقبة مستمرة ولا نظام إدارة محتوى يجب تأمينه، وهذا مناسب لشركة ناشئة ينبغي أن يتركّز اهتمامها الهندسي على التطبيق لا على الموقع.
واجهة عامة تتعامل مع موضوعها بجدية
في منتج يصل إليه الناس عبر بحث خاص كثيرًا ما يشوبه الحرج، يؤدي الموقع الذي يسمّي المشكلة بوضوح ويجيب عنها بمصداقية عملًا حقيقيًا في تحويل الزوار إلى مسجَّلين.
08 الدروس المستفادة
ماذا تعلّمنا من هذا المشروع؟
ابنِ بما يناسب مهمة الموقع الفعلية
موقع تسويقي لما قبل الإطلاق ومحتواه قلّما يتغيّر لا يحتاج إلى بنية ديناميكية: محتوى ثابت داخل الشيفرة بأربع تبعيات أفضل من نظام إدارة محتوى لن يستخدمه.
الموافقة ميزة في المنتج، لا مجرد خانة اختيار
ربط الموافقة بمنصة التسويق كبيانات، وجعل إرسال النموذج مشروطًا بها، يجعلان القائمة آمنة للاستخدام التجاري منذ أول تسجيل.
اعتنِ بالمخرج كما تعتني بالمدخل
يخدم مسار الحذف المستخدمين في أقل لحظاتهم سعادة، والجهات التنظيمية في أشد لحظاتها انتباهًا؛ وثلاث طرق للتحقق مع خطوة التأكيد بالكتابة هي القدر الصحيح من الهندسة لصفحة يتمنى الجميع ألا يزورها أحد.
المواضيع الحسّاسة تكافئ الصراحة
كان أهم قرار في كتابة نصوص الموقع هو تسمية الحالات بدل الالتفاف حولها؛ فحين يجد الزائر نفسه فيما يقرؤه يتحول إلى مسجَّل في القائمة.
صفحات مبنية · منشورة على الموقع الفعلي
المنتج
كل شاشة معروضة هنا لقطة حقيقية من الموقع المنشور. انقر على أي صورة لتكبيرها.
