تتحدد تكلفة إنشاء تطبيق متجر إلكتروني بنطاق التطبيق وربطه بمتجرك الحالي وما ستدفعه لتشغيله. تبدأ باقات تطبيقات الجوال لدى تكنوستاك من 20,000 ريال قبل الضريبة حيث تنطبق، كما في أكتوبر 2026؛ وهذا سعر بداية لنطاق محدد، ويحتاج تطبيق المتجر الكامل إلى عرض يؤكد وظائفه وتكاملاته. افصل ميزانية إنشاء المتجر عن التطبيق، ثم قارن تكلفة البناء والتشغيل خلال مدة واحدة.
إذا كان متجرك يعمل بالفعل، ابدأ برابطه وقائمة بالأنظمة التي تدير المنتجات والطلبات. أما إذا كنت تبدأ من الصفر، فجهّز قرار المتجر أولًا بالاستعانة بـميزانية المتجر قبل إضافة قناة الجوال. يساعدك هذا الفصل على معرفة ما ستعيد استخدامه وما ستطلب تطويره، ويمنع احتساب لوحة إدارة جديدة لمجرد أن عرض التطبيق لم يذكر لوحة متجرك الحالية.
اطلب التطبيق عندما تستطيع تسمية مهمة متكررة تريد تسهيلها للعميل، وتحديد من سيشغّل هذه القناة بعد إطلاقها. قد تكون المهمة إعادة طلب منتجات معتادة أو متابعة طلب قائم. اكتب كيف ينجز العميل هذه المهمة اليوم، وما الخطوات التي تريد تقليلها، ثم اختبر الفكرة مع مستخدمين قبل اعتماد قائمة طويلة من الخصائص.
راجع أولًا مسار الشراء من موقعك على الهاتف. جرّب البحث عن منتج، واختيار المقاس، وإدخال العنوان، وإكمال الطلب. إذا وجدت سعر توصيل غير واضح أو منتجًا غير متاح، حدّد مسؤول إصلاح المشكلة في المتجر قبل نقل المسار إلى تطبيق. وجود أيقونة على الهاتف لا يعالج نقص بيانات المنتج أو تأخر فريقك في تجهيز الطلبات.
جهّز أيضًا خطة تشغيل واقعية: من يراجع ظهور المنتجات؟ من يرسل الإشعارات؟ ومن يتابع أعطال الطلب؟ لا تجعل عدد التنزيلات وحده معيار قبول المشروع. اختر مهمة قابلة للفحص، وسجّل طريقة قياسها والفترة التي ستراجعها. يمكنك تأجيل التطبيق إذا لم تتضح فائدته أو لم تتوفر ميزانية صيانته، مع مواصلة تحسين المتجر الذي يستخدمه عملاؤك بالفعل.
ابدأ بفحص خيار المنصة التي تستخدمها، ثم اطلب تطويرًا مخصصًا للمتطلبات التي تحتاجها فعلًا ولا يغطيها الخيار المتاح. كما في أكتوبر 2026، تعرض سلة صانع تطبيقات للمتاجر مرتبطًا بإدارة المتجر. افحص أهلية اشتراكك والخصائص والتكاليف الحالية قبل الشراء، ولا تعتبر وجود متجر على سلة اشتراكًا تلقائيًا في تطبيقه.
وتوضح وثائق تطبيق الجوال لدى زد، كما في أكتوبر 2026، إمكانية إدارة محتوى التطبيق والمنتجات والطلبات من لوحة تحكم زد نفسها. اطلب عرضًا يحدد باقة التطبيق وما يشمله الاشتراك، ثم جرّب احتياجاتك المحددة. افحص خصوصًا القسائم وحسابات العملاء والإضافات التي تعتمد عليها، بدل الاكتفاء بأن صفحة المنتج تقول إن المنصة توفر تطبيقًا.
أما شوبيفاي (Shopify)، فتشرح وثائقه للمتاجر داخل تطبيقات الجوال، كما في أكتوبر 2026، استخدام Storefront API للمنتجات والسلة، وCheckout Kit لإظهار إتمام الشراء. هذه أدوات لبناء الربط، ولا تثبت أن اشتراك متجرك يتضمن تصميم تطبيقك وتسليمه. اطلب من المطوّر عرض المسار الذي سيستخدمه وتحديد العمل المتبقي. قارن الخيارات بتجربة طلب فعلية وبنفس المتطلبات، دون افتراض أن الخيار المخصص أفضل لكل متجر.
تعرض باقات تطبيقات الجوال لدى تكنوستاك، كما في أكتوبر 2026، أسعار بداية قدرها 20,000 و40,000 و70,000 ريال للمشروع، قبل الضريبة حيث تنطبق. تشمل الباقات iOS وAndroid بالعربية والإنجليزية، لكن لكل باقة حدودًا للشاشات والأدوار والتكاملات. لا تمثل هذه الأرقام ثلاث باقات متجر جاهزة بكل وظائف التجارة؛ يحدد العرض مدى ملاءمة النطاق لمتجرك.
راجع تكلفة إنشاء تطبيق متجر إلكتروني مع تفاصيل خدمة الجوال، واستخدم حدود باقات التطبيق عند إعداد الموجز لفهم السؤال الذي يجب أن تجيب عنه قبل اختيار الباقة. وجود نموذج طلب ضمن نطاق ما لا يعني وجود كتالوج وسلة ومخزون ومرتجعات بلا حدود. اطلب تسمية كل وظيفة مطلوبة، وما إذا كانت موجودة في منصتك أو تحتاج إلى بناء وربط.
افصل حسابات المطوّر والاستضافة ورسوم مزودي الدفع والرسائل والصيانة المستمرة عن سعر التطوير، وفق النطاق المنشور. واطلب تحديد أي عمل خارج حدود الباقة قبل الالتزام. يمكنك مراجعة مرجع أسعار الخدمات المنشورة عند مقارنة البنود، مع الاحتفاظ بتاريخ العرض ومدة صلاحيته. السعر النهائي ونطاق التسليم يثبتان في عرض مشروعك، ولا يستنتجان من عدد الشاشات وحده.
اطلب تفصيل العمل بحسب ما سيستلمه فريقك وكيف سيفحصه. اكتب احتياجاتك في جدول واحد وأرسله لكل مورد، ثم ضع إجاباتهم بجانب بعضها. اترك البند غير المسعّر واضحًا بوصفه معلقًا؛ وجود خانة فارغة لا يعني أن الخدمة مجانية أو مشمولة في بند آخر.
| بند العمل | ما الذي تحدده قبل التسعير؟ | دليل التسليم المقترح |
|---|---|---|
| تصميم التطبيق | الشاشات واللغات وحالات الخطأ | نموذج تفاعلي للمسار المتفق عليه |
| الكتالوج | مصدر المنتجات والصور والخيارات | منتج تجريبي يظهر بالبيانات الصحيحة |
| السلة والطلب | الخصومات والتوصيل وطريقة الدفع | طلب مطابق في التطبيق والمتجر |
| الحسابات | الدخول والبيانات التي يحتاجها العميل | فحص الصلاحيات والمسارات المتفق عليها |
| الربط | كل نظام وواجهة وصاحب مسؤولية | سجل اختبار لكل اتصال |
| الإصدار | الحسابات والمواد والأجهزة | نسخة معتمدة وقائمة تقديم |
| التشغيل | الرسوم والصيانة وتغييرات الموردين | اتفاق منفصل بمسؤوليات واضحة |
اطلب وصفًا لما يعنيه تعديل التصميم وما يحدث إذا أضفت طريقة شحن جديدة بعد الاعتماد. حدّد من يقدّم النص العربي وصور المنتجات، ومن يراجع شروط البيع الظاهرة. وإذا احتاج المورد إلى وصول تقني، اتفق على الصلاحيات المطلوبة وطريقة سحبها عند انتهاء العمل. هذا تنظيم مقترح لمشروعك، وليس توسيعًا تلقائيًا لأي باقة منشورة.
اختر مصدرًا مرجعيًا لكل نوع من البيانات، ثم اطلب اختبارًا يثبت أن التطبيق يعرض الحالة التي يعتمدها ذلك المصدر. قد تدير المنتجات في منصة المتجر والمخزون في نظام آخر؛ اكتب العلاقة قبل تسعير الربط. حدّد أيضًا من يتدخل عند فشل تحديث، وكيف يرى فريق التشغيل الخطأ بدل أن يكتشفه من شكوى عميل.
استخدم طلبًا تجريبيًا افتراضيًا لتوثيق المسار: يختار العميل المنتج في التطبيق، ويرسل الطلب إلى المتجر، ثم يعرض التطبيق حالة الطلب التي أكدها النظام. افحص تطابق المنتج والكمية والإجمالي ومعرّف الطلب بين الجانبين. لا تعتبر الضغط على زر الشراء إثباتًا لنجاح الدفع؛ اطلب اختبار الحالة التي يعيدها المزود وفق طريقة الربط المختارة.
أضف حالات فشل إلى الاختبار: انتهاء المخزون أثناء الشراء، أو انقطاع الاتصال بعد إرسال الطلب، أو إعادة المحاولة. اطلب من المطوّر شرح النتيجة المطلوبة لكل حالة وطريقة منع تكرار الطلب نفسه. وفي حالة الإلغاء أو الاسترجاع، حدّد النظام الذي يبدأ التغيير وكيف يعرضه التطبيق. هذه متطلبات يمكنك الاتفاق عليها؛ لا نفترض أن كل منصة أو إضافة تدعمها بالطريقة نفسها.
احتفظ بسجل يربط المتطلب بنتيجة الاختبار وصاحب الإصلاح. إذا غابت واجهة برمجية ضرورية، اطلب تسعير البديل قبل بدء التنفيذ، وراجع إن كان يؤثر في قرار اختيار التطبيق. اجمع هذه الملاحظات في ملحق الربط حتى لا يتحول بند قصير باسم «تكامل المتجر» إلى توقعات مختلفة عند التسليم.
مثال افتراضي لمسار الاختبار: طابق الطلب بين التطبيق والمتجر، ثم اعرض الحالة التي يؤكدها النظام.
اختبر رحلة العميل كاملة على الأجهزة المتفق عليها، مع نجاح الدفع وإلغائه وفشله. اطلب توثيق ما يظهر للعميل وما يسجله المتجر في كل حالة، وحدّد المسؤول عن متابعة موافقات مزود الدفع ورسومه. استخدم حسابات الاختبار المناسبة قبل الانتقال إلى التشغيل، وتجنب تسجيل بيانات حساسة في صور التوثيق أو تقارير الأعطال.
اكتب أنواع الإشعارات المطلوبة بدل عبارة «إشعارات غير محدودة». قد تريد رسالة عن حالة الطلب أو تنبيهًا تسويقيًا أو رابطًا يفتح منتجًا بعينه. اطلب توضيح مصدر كل رسالة، ومن يوافق عليها، وما يحدث إذا فتح العميل رابط منتج انتهى عرضه. افحص سلوك التطبيق عند رفض الإذن بالإشعارات، حتى يبقى الوصول إلى الطلب ممكنًا من داخله.
راجع العربية أثناء النموذج الأولي ثم أثناء الاختبار، خصوصًا أسماء المنتجات الطويلة والأسعار والعناوين المختلطة بالعربية واللاتينية. جرّب تكبير النص ولوحة مفاتيح الهاتف، وافحص اتجاه الأيقونات وترتيب خطوات الشراء. اطلب تسجيل العيوب مع صورة وخطوات إعادة إنتاجها. لا تؤجل هذه المراجعة إلى يوم تقديم التطبيق، لأن اعتماد التصميم قبل فحص اللغة قد يضيف عملًا يحتاج إلى اتفاق جديد.
اجمع التكاليف المتكررة في ورقة مستقلة، مع الجهة التي تصدر الفاتورة وموعد التجديد. اذكر اشتراك المتجر أو صانع التطبيق، وحسابات النشر، والاستضافة حيث تلزم، ورسوم الخدمات الخارجية، وأعمال الصيانة التي اتفقت عليها. ثم قارن العروض خلال الفترة نفسها، مع فصل مبالغ التأسيس عن المبالغ المتكررة وأي استخدام متغير.
بحسب نطاق تكنوستاك المنشور كما في أكتوبر 2026، تشمل باقة التطبيق المركّز إصلاح عيوب النطاق المسلّم لمدة 3 أشهر، وتشمل الباقتان الأخريان 6 أشهر. تبقى الصيانة المستمرة والميزات الجديدة منفصلة، مع تفاصيل تحديثات التوافق المذكورة في كل باقة. راجع فصل صيانة التطبيق عن إصلاح عيوب التسليم قبل أن تفسّر عبارة الدعم بوصفها تطويرًا مفتوحًا.
اسأل من يمتلك الحسابات والكود ومفاتيح التوقيع، ومن يستطيع إصدار تحديث إذا غاب المورد. اطلب قائمة تسليم وصلاحيات ومسؤول اتصال، ودوّن كيف تبلغ عن عطل يمنع الشراء. وحدّد طريقة تقدير تكلفة أي تغيير لاحق وموافقته قبل تنفيذه. بهذه التفاصيل تستطيع الاستمرار في تشغيل التطبيق دون الاعتماد على اتفاق شفهي لا يحدد من يتصرف عند المشكلة.
ورقة مقارنة مقترحة: افصل التكاليف الأولية والمتكررة، وتحقق من البنود المشمولة حتى لا تحسب العمل نفسه مرتين.
أعد موجزًا قصيرًا يصف متجرك الحالي والمهمة المطلوبة داخل التطبيق والوظائف التي تؤجلها. أرفق مصادر البيانات والواجهات المتاحة، واطلب تجربة ربط محددة إن بقي جزء أساسي غير معروف. ناقش جدول التسليم بعد فحص هذه المدخلات، وافصل وقت تنفيذ المورد عن مراجعات متاجر التطبيقات والجهات الخارجية؛ لا تعتمد موعدًا مضمونًا دون معرفة تلك الاعتماديات.
قبل التوقيع، راجع هذه القائمة مع فريقك:
- هل يوضح العرض ما ستستخدمه من المتجر الحالي وما ستبنيه؟
- هل سمّيت مسار شراء يمكن اختباره وحالات الفشل التي تهمك؟
- هل تشمل مراجعة التصميم العربية والأجهزة واللغات المتفق عليها؟
- هل تعرف الرسوم المتكررة والمستثنيات وصاحب كل حساب؟
- هل ربطت قبول التسليم بنتائج اختبار وملفات تستطيع استلامها؟
الخلاصة العملية: اختر أصغر نطاق يثبت فائدة التطبيق ويعمل مع متجرك، ثم اعتمد ميزانية تغطي بناءه وتشغيله خلال فترة واضحة. إذا بقي الربط أو بند متكرر مجهولًا، اطلب الإجابة قبل الموافقة. أرسل رابط المتجر ووصف المهمة إلى جلسة تحديد نطاق تطبيق متجرك، لنراجع المتطلبات ونجهز عرضًا يمكنك مقارنته على أساس واضح.
