قصتنا

خمسة عشر عاماً مع المشكلة نفسها

لم يولد ListoMax من دراسة سوق. وُلد من متجر فارغ كان يجب ملؤه، ومن ليالٍ قضيتها في نسخ بطاقات المنتجات ولصقها.

2011 — متجر يجب ملؤه

كان لدي متجر PrestaShop وأسبوع واحد لملئه. مئتا منتج يجب إنشاؤها، معظمها متوفر بعدة ألوان وعدة مقاسات. كان على كل تنويع أن يصبح بطاقة مستقلة بذاتها، بمرجعها وصورها ووصفها.

بعد يومين، كانت الحسبة واضحة: بهذه الوتيرة سأحتاج إلى شهر كامل. فتوقفت عن الإدخال وكتبت أداة تقوم بذلك نيابة عني. بدائية، وغير جميلة، دون واجهة تستحق هذا الاسم — لكنها كانت تولّد البطاقات وترسلها إلى المتجر. وكفى أسبوع واحد.

ما علّمتني إياه تلك الأداة الأولى

أن المشكلة لم تكن في الإدخال بحد ذاته، بل في التكرار: المنتج نفسه يُكتب اثنتي عشرة مرة لاثني عشر لوناً، ثم مرة أخرى لكل متجر تبيع فيه. عمل بلا أي قيمة مضافة، يلتهم الساعات التي يجب أن تقضيها في البيع.

وأن الأدوات الموجودة كانت تخطئ الهدف. أدوات استيراد CSV المدمجة في منصات CMS تتعامل جيداً مع الكميات الكبيرة والمنظمة، لكنها تفترض أن الملف موجود مسبقاً ونظيف. لا تساعدك على إنشاء التنويعات، ولا على ملء اثنتي عشرة بطاقة انطلاقاً من واحدة، ولا على تغذية متجرين في آن واحد.

وأن الصعوبة الحقيقية لم تكن في الفكرة، بل في تفاصيل كل منصة CMS. منتج مُصنّف في فئة فرعية لا يظهر في أي مكان لأن الفئة الأم لم تُربط. نسبة ضريبة غير موجودة في المتجر فيُنشر المنتج دون ضريبة. تعديل محفوظ لا يصل أبداً إلى الموقع. كل فخ من هذه الفخاخ كلّفني ساعات.

2026 — ListoMax

ListoMax هو فكرة 2011 نفسها وقد اكتملت حتى النهاية. ميزة السلسلة هي امتدادها المباشر: املأ نموذجاً واحداً، واحصل على عدد من البطاقات الكاملة يساوي عدد التنويعات التي أدخلتها.

وكل ما عدا ذلك بُني حولها، وفق ما تتطلبه المتاجر الحقيقية. فئات أم يجب ربطها ليظهر المنتج في التصفح. نسب ضريبة يجب قراءتها من المتجر لا تخمينها. متغيرات يجب ألا تنكسر عند إعادة النشر. صور يجب رفعها فعلاً. سجل يجب الاحتفاظ به لتتمكن من التراجع.

كل ميزة يتم التحقق منها على متاجر حقيقية قبل إطلاقها: PrestaShop 8، وPrestaShop 9، وWooCommerce. بعد كل عملية نشر، يقرأ البرنامج البطاقة من المتجر للتحقق من أنه استلم ما أُرسل. يتطلب ذلك وقتاً أطول في البناء، لكنه الطريقة الوحيدة للتأكد من أن كل شيء يعمل.

المبدأ الذي يقود التطوير

لا فشل صامت. أبداً.

العميل الذي يستخدم ListoMax لا يستطيع فتح وحدة تحكم المطوّر ليفهم ما حدث. إذا فشل شيء ما، يجب أن يراه على الشاشة، وأن يعرف أي منتج تأثر ولماذا. الخطأ الذي تراه يمكن إصلاحه، أما الخطأ الصامت فيُضيّع البيانات دون أن يلاحظ أحد.

لهذا المبدأ نتائج ملموسة. التعديل الذي تعذّر حفظه يجب أن يُعلن ذلك. نسبة الضريبة التي لم يُعثر عليها يجب أن توقف النشر بدلاً من تمريره بنسبة خاطئة. الصورة التي لم تُرفع يجب أن تظهر في قائمة الأخطاء، لا أن تختفي في الهواء.

إنه نوع من التفاصيل لا تراه أبداً في صفحة تسويقية. ومع ذلك، هو ما يصنع الفرق بين أداة تواصل استخدامها وأداة تتخلى عنها بعد ثلاثة أسابيع.

مشروع مستقل

لا تنشر ListoMax شركة تبيع عشرة برامج أخرى. إنه مشروع مستقل، يطوّره ويدعمه الشخص نفسه. عندما تكتب إلى الدعم، فهو من يجيبك.

ما يعنيه ذلك لك: ملاحظاتك تؤثر مباشرة فيما سيُبنى لاحقاً. الميزة التي يطلبها عدة مستخدمين تقفز إلى أعلى القائمة. والخلل المُبلّغ عنه يُصلح في الإصدار التالي، لا بعد عامين.

وما يعنيه أيضاً: المواعيد تعتمد على شخص واحد. نفضّل أن نخبرك بذلك مسبقاً على أن تكتشفه لاحقاً.

سؤال، أو ملاحظة، أو احتياج خاص؟ اكتب إلى support@listomax.io. ملاحظاتك تؤثر مباشرة فيما سيُبنى لاحقاً.
ما القادم

ما هو مخطط له

لا مواعيد موعودة: المواعيد تعتمد على شخص واحد، ونفضّل أن نُطلق شيئاً مُختبَراً على أن نُطلق شيئاً سريعاً.

قيد التنفيذ

Shopify وBigCommerce

الموصّلان جاهزان. سيُفعّلان بعد التحقق منهما على متاجر حقيقية، وفق البروتوكول نفسه المتبع مع PrestaShop وWooCommerce.

مخطط له

نسخة macOS

مخطط لها بعد نسخة Windows. إن كنت تعمل على Mac، فأخبرنا: عدد الطلبات يحدد الأولوية.

قيد الدراسة

نسخة Linux

قيد الدراسة بعد macOS، إن وُجد طلب عليها. راسلنا إن كنت معنياً.

المشكلة نفسها التي تواجهها

إن سبق لك أن قضيت يوماً كاملاً في إنشاء بطاقات المنتجات يدوياً، فأنت تعرف تماماً ما نتحدث عنه.