جاءتنا مؤسِّسة مقيمة في دبي ذات خلفية سريرية ومعها ملف Figma، وقائمة بـ١٢ عيادة شريكة، ونافذة من ٦ أسابيع قبل عرضٍ تقديمي لإحدى شركات التأمين الصحي الإقليمية. وكانت قد تلقَّت عرضين من شركتين أكبر بمدة تتراوح بين ٤ و٦ أشهر.
إطلاق نسخة MVP لإدارة العيادات متعددة المستأجرين — تسجيل المرضى، والوصفات الإلكترونية، وحجز المواعيد عبر Cal.com، ووصول الموظفين بحسب الأدوار، والفوترة الأساسية — قبل يوم العرض. معيار النجاح: استخدام فعلي في عيادتين حقيقيتين، ومسار كامل للمريض من البداية إلى النهاية، ودون أي أعطال حرجة في العرض.
ضغطنا عملية البناء برفض المزايا التي لن تُستخدم في يوم العرض. لا تطبيق جوّال — فالعرض سيتم على جهاز لوحي على أي حال. ولا نظام تصميم مخصص — اعتمدنا قاعدة مبسّطة من shadcn/ui ووجّهنا الجهد بدلًا من ذلك إلى مسار نموذج المريض.
اخترنا Supabase بدلًا من إعداد مخصص لـPostgres مع المصادقة؛ فمرونة المصادقة التي كنا سنخسرها لا تستحق الأسبوعين اللازمين للبناء. ودمجنا Cal.com عبر واجهته البرمجية العامة ونظام الـwebhook الخاص به — فبناء تقويم من الصفر لم يكن ممكنًا خلال ٣٨ يومًا، وكانت واجهة Cal.com جيدة بما يكفي لتوافق المؤسِّسة على وضعها بعلامتها التجارية.
انخرطنا مع فريقها في قناة Slack خاصة منذ اليوم الأول. عروض أسبوعية كل يوم جمعة. وسياسة لفرز الأعطال: كل ما يعيق إجراءً يخص المريض يُصلَح في اليوم نفسه؛ وما عداه ينتظر حتى يوم الاثنين.
- تم الإطلاق في يوم العرض. ووقَّعت شركة التأمين على مرحلة تجريبية بعد أسبوعين.
- ٣٨ يومًا من الانطلاق إلى الاستخدام الفعلي في عيادتين في دبي وواحدة في الشارقة.
- يكتمل مسار تسجيل المريض في ٧٣ ثانية كوسيط زمني.
- صفر أعطال حرجة خلال أول ٣٠ يومًا بعد الإطلاق.
«شعرنا أن فريق أبتولوجي شريك مؤسِّس لنا، لا مجرد مورّد.»
كنا سندفع بقوة أكبر نحو مراجعة الامتثال للوصفات الإلكترونية في وقت أبكر. فقد رصدنا أحد متطلبات DHA لمعالجة البيانات في الأسبوع الخامس، وكان يجب أن يُكتَشف في الأسبوع الأول. لم يكن له أثر على الإنتاج، لكنه سبّب عطلة نهاية أسبوع مرهقة.