CareConnect: one backend, three audiences.CareConnect: خادم واحد، ثلاثة جماهير.

The three sides are mothers booking care, babysitters offering it, and admins keeping the platform honest. I designed all three apps and led the build, with the babysitter app developed together with a collaborator.الأطراف الثلاثة هي أمّهات يحجزن الرعاية، وجليسات يعرضنها، ومشرفون يحفظون نزاهة المنصّة. صمّمتُ التطبيقات الثلاثة وقدتُ البناء، وطُوّر تطبيق الجليسة بالتعاون مع زميل.

Roleالدور

Designed all three, led the buildصمّمتُ الثلاثة، وقدتُ البناء

Timelineالإطار الزمني

2024

Platformالمنصّة

3× Flutter · iOS + Android

Audiencesالجماهير

Mother · Babysitter · Adminأمّ · جليسة · مشرف

Backendالخادم

Supabase · Postgres · RLS

Scopeالنطاق

Requirements, Figma, Flutterمتطلبات، وFigma، وFlutter

Childcare doesn't fit in one app. A mother wants a vetted match quickly. A babysitter wants a schedule she can rely on and clarity about what she'll be paid. An admin wants control over who's verified, who's been flagged, and how to step in without breaking anything.رعاية الأطفال لا تتّسع لتطبيق واحد. الأمّ تريد تطابقاً مُدقَّقاً بسرعة. والجليسة تريد جدولاً تعتمد عليه ووضوحاً في ما ستُقبضه. والمشرف يريد تحكّماً بمن هو موثَّق، ومن أُبلغ عنه، وكيف يتدخّل دون أن يكسر شيئاً.

Each side only trusts the platform if the other two are being held to rules they can't see but can feel. That makes trust an information-architecture and permissions problem long before it becomes a UI one.كل طرف لا يثق بالمنصّة إلا إن كان الطرفان الآخران مُلزَمَين بقواعد لا يرونها لكن يشعرون بها. وهذا يجعل الثقة مشكلة هندسة معلومات وصلاحيات قبل أن تصبح مشكلة واجهة بزمن طويل.

I started with an IEEE 830 requirements document covering every entity, relation and user flow, before a single screen got designed. Writing it produced the insight the whole product rests on: a mother is shopping, a babysitter is selling her time, and an admin is moderating. Three different tasks, which means three different information architectures.بدأتُ بوثيقة متطلبات IEEE 830 تغطّي كل كيان وعلاقة وتدفّق مستخدم، قبل أن تُصمَّم شاشة واحدة. وأنتجت كتابتها الاستنتاج الذي يقوم عليه المنتج كله: الأمّ تتسوّق، والجليسة تبيع وقتها، والمشرف يُدير. ثلاث مهامّ مختلفة، وهذا يعني ثلاث هندسات معلومات مختلفة.

The user types from the requirements document became three personas, each with a different primary task and the frustration that shaped its app.فئات المستخدمين من وثيقة المتطلبات صارت ثلاثة personas، لكل واحد مهمّة أساسية مختلفة والإحباط الذي شكّل تطبيقه.

My bet was that the hardest problem in a marketplace is keeping three audiences and one backend coherent. So the schema and the permission model led, and the interface followed.كان رهاني أن أصعب مشكلة في سوق هي إبقاء ثلاثة جماهير وخادم واحد متماسكين. فقاد المخطّط ونموذج الصلاحيات، وتبعت الواجهة.

Goalالهدف

Trust across all three sides of the marketplaceالثقة عبر أطراف السوق الثلاثة

Hypothesisالفرضية

Three focused apps beat one app with a role switchثلاثة تطبيقات مركّزة تتفوّق على تطبيق فيه مبدّل أدوار

Priorityالأولوية

Data model and access rules ahead of UIنموذج البيانات وقواعد الوصول قبل الواجهة

Tradeoffالمفاضلة

A costlier build for surfaces that stay honestبناء أكلف مقابل واجهات تبقى أمينة

Choosing three separate apps over one with a role switch is a design decision before it's an engineering one. Each app got its own Figma file, its own navigation and its own vocabulary.اختيار ثلاثة تطبيقات منفصلة بدل واحد فيه مبدّل أدوار قرار تصميمي قبل أن يكون هندسياً. ولكل تطبيق ملف Figma خاص به، وتنقّله ومفرداته.

01 / 04

A friendly face to startوجه ودود للبداية

The mascot and a calm sky-blue palette set a reassuring tone rather than a clinical one, and the whole app works in Arabic and English.الشخصية ولوحة زرقاء هادئة تضبطان نبرة مُطمئنة لا سريرية، والتطبيق كله يعمل بالعربية والإنجليزية.

Every read and write goes through Supabase row-level security. A mother sees active babysitters inside her search radius. A babysitter sees and edits her own profile and bookings. An admin sees everything, and everything an admin does is written to a log. The role enforcement lives in the database, so the client never has to be trusted with it.كل قراءة وكتابة تمرّ عبر أمان مستوى الصف في Supabase. الأمّ ترى الجليسات النشطات داخل نطاق بحثها. والجليسة ترى وتحرّر ملفها وحجوزاتها. والمشرف يرى كل شيء، وكل ما يفعله المشرف يُكتب في سجلّ. وفرض الأدوار يعيش في قاعدة البيانات، فلا يُضطرّ أحد لائتمان العميل عليه.

Mother appتطبيق الأمّ

Discover · Book · Payاكتشاف · حجز · دفع

Babysitter appتطبيق الجليسة

Profile · Scheduleملف · جدول

Admin appتطبيق المشرف

Moderate · Auditإدارة · تدقيق

Authالمصادقة

Supabase Auth

Realtimeالزمن الحقيقي

Postgres CDC

Policiesالسياسات

RLS · RBAC

It's tempting to treat three apps as three projects. The apps turned out to be the easy part. The hard part was holding one schema and one permission model steady across three quite different experiences without ending up with three copies of the same code.من المغري أن تتعامل مع ثلاثة تطبيقات كثلاثة مشاريع. تبيّن أن التطبيقات هي الجزء السهل. والصعب كان تثبيت مخطّط واحد ونموذج صلاحيات واحد عبر ثلاث تجارب مختلفة تماماً دون أن تنتهي بثلاث نسخ من الكود نفسه.

CareConnect shipped as three focused apps on one Supabase backend, with access decided in the database rather than trusted to the client. Each side's data boundary can be demonstrated in SQL, and every admin action leaves a record.أُطلق CareConnect كثلاثة تطبيقات مركّزة على خادم Supabase واحد، والوصول فيه يُقرَّر في قاعدة البيانات بدل أن يُؤتمَن عليه العميل. وحدّ بيانات كل طرف يمكن إظهاره بـSQL، وكل إجراء مشرف يترك سجلاً.

The three-app split was a UX call that engineering then had to honour. And writing the spec first was the cheapest insurance I could buy against three apps and one backend drifting apart.كان فصل التطبيقات الثلاثة قراراً في التجربة كان على الهندسة بعده أن تحترمه. وكتابة المواصفة أولاً كانت أرخص تأمين أستطيع شراءه ضدّ تباعد ثلاثة تطبيقات وخادم واحد.

Since trust has to hold across all three sides, I'd run a usability study per app around its main task: a mother finding and booking vetted care, a babysitter accepting a booking, a moderator verifying and flagging. Then I'd cluster the findings and fix whatever blocks the marketplace loop first.بما أن الثقة يجب أن تصمد عبر الأطراف الثلاثة، سأُجري دراسة قابلية استخدام لكل تطبيق حول مهمّته الرئيسية: أمّ تجد وتحجز رعاية مُدقَّقة، وجليسة تقبل حجزاً، ومشرفة توثّق وتُبلّغ. ثم أعنقد النتائج وأُصلح ما يعيق حلقة السوق أولاً.

• P0The trust signals in the mother's app, the verification badges and what they actually mean, have to be unmistakable, or she won't book at all.إشارات الثقة في تطبيق الأمّ، شارات التوثيق ومعناها الفعلي، يجب أن تكون لا تُخطئ، وإلا فلن تحجز أصلاً.
• P1The babysitter's schedule and the context of a booking have to be readable at a glance before she accepts it.جدول الجليسة وسياق الحجز يجب أن يُقرآ بلمحة قبل أن تقبله.
• P2The admin's moderation actions should be quick and obviously reversible, with the log one tap away.إجراءات الإدارة لدى المشرف ينبغي أن تكون سريعة وقابلة للتراجع بوضوح، والسجلّ على بُعد نقرة.

What stuck with me is that most of the difficulty in a multi-sided product is information architecture and access control, not how many screens there are. Writing the spec first felt slow and turned out to be the fastest route. It's my default now for anything with more than one kind of user.ما بقي معي أن معظم الصعوبة في منتج متعدّد الأطراف هندسة معلومات وتحكّم بالوصول، لا عدد الشاشات. بدت كتابة المواصفة أولاً بطيئة وتبيّن أنها أسرع طريق. وهي الآن خياري الافتراضي لأي شيء فيه أكثر من نوع مستخدم.

Next time I'd build a shared component layer across the three apps much earlier, so visual consistency is held by code instead of by discipline.في المرة القادمة سأبني طبقة مكوّنات مشتركة عبر التطبيقات الثلاثة أبكر بكثير، ليحفظ الكودُ الاتّساق البصري بدل الانضباط.