«كم سيكلّف هذا؟» هو السؤال الأول لكل مؤسس تقريبًا، والإجابة الصادقة («يعتمد على أمور كثيرة») لا تفيد وحدها. يستبدلها هذا المقال بشيء يمكنك العمل به: العوامل القليلة التي تحرّك السعر فعلًا، وطريقة لتقدير منتجك الأولي بالساعات، والقرارات التي تجعله أرخص دون أن تجعله أسوأ.
ما هو المنتج الأولي (وما ليس هو)
المنتج الأولي القابل للتطبيق (MVP) هو أصغر شيء يتيح لمستخدمين حقيقيين الحصول على قيمة حقيقية، كي تعرف إن كانت الفكرة تنجح. إنه ليس الإصدار 1.0 بألوان أقل. واختبار كل ميزة بسيط: إن حذفناها، هل سنظل نتعلم ما نحتاج إلى تعلّمه؟
هذا التعريف مهم للتكلفة، لأن معظم تجاوزات الميزانية تأتي من بناء أشياء لا تجيب عن أي سؤال.
العوامل الخمسة التي تحدد التكلفة
1. عدد مسارات المستخدم المختلفة
السعر يتبع المسارات لا الصفحات. «التسجيل، وإنشاء مشروع، ودعوة زميل، والدفع» أربعة مسارات، وكل منها يحتاج إلى تصميم، وواجهة أمامية، وخلفية برمجية، ومعالجة للحالات الاستثنائية، واختبار. وقد يكون موقع تسويقي من عشر صفحات دون تسجيل دخول أرخص من تطبيق من ثلاث شاشات فيه حسابات للمستخدمين.
2. من هم المستخدمون
نوع واحد من المستخدمين هو الحالة الأرخص. أما طرفان (مشترون وبائعون، أو طلاب ومعلمون، أو عملاء ومدير) فيضاعفان النطاق تقريبًا: لوحات تحكم وصلاحيات وإشعارات وخطوات تعريف منفصلة لكل طرف.
3. التكاملات
المدفوعات، والبريد الإلكتروني، والخرائط، والتقويمات، وأنظمة CRM، ونماذج الذكاء الاصطناعي. كل تكامل يبدأ صغيرًا عادةً، لكن إتقانه مكلف: webhooks، وإعادة المحاولة، وحالات الفشل، وحسابات الاختبار، واليوم الذي يغيّر فيه المزوّد واجهته البرمجية. خصّص ميزانية لكل تكامل على حدة.
4. المحتوى والبيانات
من يكتب النصوص؟ هل هناك بيانات يجب استيرادها؟ هل سيحتاج أحد إلى لوحة إدارة لتعديل المحتوى بعد الإطلاق؟ «سنتدبّر المحتوى لاحقًا» هي أكثر الأسباب شيوعًا لتأجيل الإطلاق.
5. المنصة
تطبيق ويب متجاوب يصل إلى الجميع بقاعدة شيفرة واحدة. أما تطبيقات iOS وAndroid الأصلية فتضاعف العمل وتضيف مراجعة المتاجر. ولمعظم المنتجات الأولية، يكون تطبيق ويب سريع (قابل للتثبيت اختياريًا كتطبيق PWA) هو الخطوة الأولى الصحيحة.
قدّرها بنفسك، بالساعات
الساعات أنفع من الأسعار، لأن الأجور تتفاوت كثيرًا بحسب البلد والخبرة بينما يبقى العمل نفسه ثابتًا. إليك نطاقات نموذجية لشخص واحد متمرّس يجمع بين التطوير الشامل والتصميم؛ اضربها في الأجر الذي يُعرض عليك.
| بند العمل | الساعات المعتادة |
|---|---|
| الاستكشاف والنطاق ومسارات المستخدم | 8–20 |
| تصميم واجهة وتجربة الشاشات الأساسية | 20–60 |
| صفحة هبوط / موقع تسويقي | 20–50 |
| الحسابات: التسجيل وتسجيل الدخول واستعادة كلمة المرور | 10–25 |
| كل مسار أساسي للمستخدم (CRUD + واجهة) | 15–40 |
| المدفوعات (اشتراكات أو دفعة واحدة) | 15–35 |
| لوحة إدارة للمحتوى أو المستخدمين | 15–40 |
| كل تكامل مع طرف ثالث | 8–30 |
| إشعارات البريد الإلكتروني | 6–15 |
| ضمان الجودة والإصلاحات والإطلاق | 15–30 |
يقع منتج SaaS أولي نموذجي بطرف واحد (صفحة هبوط، وحسابات، ومساران أو ثلاثة أساسية، ومدفوعات، ولوحة إدارة بسيطة) في حدود 150 إلى 350 ساعة. أما سوق إلكتروني بنوعين من المستخدمين فيصل غالبًا إلى 300 إلى 600.
هذه النطاقات واسعة عن قصد. فالحد الأدنى يفترض قرارات واضحة ومحتوى جاهزًا، والحد الأعلى يفترض أن النطاق يتغيّر أثناء البناء.
أين تذهب الأموال فعلًا
- تغيير رأيك في منتصف البناء. ليس مشكلة في حد ذاته، فالتعلّم هو الهدف، لكن تغيير ما بُني بالفعل يكلّف أضعاف التغيير على الورق. امنح المسارات والمخططات الأولية وقتًا أطول، وسيصبح البناء أرخص.
- كل شيء مخصص. نظام تصميم مخصص، ومصادقة مخصصة، ونظام إدارة محتوى مخصص؛ نادرًا ما تكون هذه سبب نجاح المنتج الأولي. اللبنات المجرّبة (مزوّد مصادقة مستضاف، وStripe، ونظام إدارة محتوى بلا واجهة، أو Markdown بسيط) أسرع وأكثر موثوقية.
- حالات استثنائية لن يصادفها أحد بعد. تعدد العملات، وعشرة أدوار للمستخدمين، والعمل دون اتصال. دوّنها لوقت لاحق.
- غياب صاحب القرار لدى العميل. حين لا يستطيع أحد اتخاذ قرار خلال يوم، ينتظر المشروع، والانتظار يُحتسب أيضًا.
كيف تجعله أرخص دون أن تجعله أسوأ
- اكتب جملة واحدة تعرّف النجاح. مثلًا: «عشرة فرق مدفوعة تستخدمه أسبوعيًا بنهاية الشهر الثاني». وتُقاس كل ميزة عليها.
- اقتصر على نوع واحد من المستخدمين. أطلق جانب البائعين، وخدِّم المشترين يدويًا في البداية، أو العكس.
- ارتجل المكتب الخلفي. يمكن أن تكون لوحة الإدارة في الأشهر الأولى جدول بيانات وبضعة سكربتات.
- صمّم الشاشات الأساسية بإتقان، وهي فقط. تجربة مستخدم جيدة في الشاشات الثلاث التي يستخدمها الناس يوميًا أهم بكثير من صفحة إعدادات مصقولة.
- اختر تقنيات يستطيع المطوّر التالي العمل بها. TypeScript، وReact أو Next.js، وقاعدة بيانات مُدارة، ومستضيف قياسي؛ كلها تُبقي خياراتك مفتوحة.
سعر ثابت أم بالساعة؟
يصلح السعر الثابت حين يكون النطاق ثابتًا فعلًا: ملخّص واضح، وتصاميم مكتملة، وعدم وجود تكاملات مجهولة. أما الدفع حسب الوقت والجهد أو باشتراك أسبوعي فيناسب أكثر حين تتوقع أن تتعلم وتغيّر أشياء، وهو الحال غالبًا مع المنتج الأولي. وأحد الحلول الوسط الشائعة مرحلة استكشاف وتصميم بسعر ثابت، يتبعها بناء مقدَّر بحد أسبوعي أقصى.
قائمة سريعة قبل طلب عروض الأسعار
- جملة واحدة تصف المستخدم والمشكلة
- مقياس النجاح للأشهر الثلاثة الأولى
- قائمة مسارات المستخدم مرتبة حسب الأهمية
- التكاملات التي تعرف أنك تحتاجها
- من يوفّر المحتوى ومتى
- نطاق ميزانيتك وموعد الإطلاق
بكتابة هذه البنود الستة، تصبح العروض قابلة للمقارنة، وأدق بكثير. وإن أردت قالبًا لهذا المستند، فراجع ملخّص الموقع الذي يجلب عروض أسعار دقيقة.
الخلاصة
تكلفة المنتج الأولي تحددها المسارات وأنواع المستخدمين والتكاملات والمحتوى والمنصة، لا عدد الصفحات. قدّر بالساعات، واقتصر على نوع واحد من المستخدمين ومقياس نجاح واحد، واستخدم لبنات مجرّبة، واتخذ قراراتك بسرعة. هكذا تتحول الميزانية الصغيرة إلى شيء يستخدمه الناس فعلًا.
إن أردت رأيًا ثانيًا في نطاق مشروعك، تواصل معي؛ يسعدني أن ألقي نظرة عليه.
