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

CareConnect is a childcare marketplace with three sides — mothers booking care, babysitters offering it, and admins moderating the platform. I designed and built all three as separate Flutter apps over one shared backend.CareConnect سوقٌ لرعاية الأطفال بثلاثة أطراف — أمّهاتٌ يحجزن الرعاية، وجليساتٌ يعرضنها، ومشرفون يديرون المنصّة. صمّمتُ وبنيتُ الثلاثة جميعاً كتطبيقات Flutter منفصلة على خادمٍ مشترك واحد.

Roleالدور

Designer + developer (solo)مصمّمة + مطوّرة (منفردة)

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

2024

Platformالمنصّة

3× Flutter · iOS + Android

Audiencesالجماهير

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

Backendالخادم

Supabase · Postgres · RLS

Scopeالنطاق

SRS → Figma → Flutterوثيقة متطلبات ← Figma ← Flutter

You can't solve childcare with a single app. Mothers need quick, vetted matches. Babysitters need a schedule and reliable payment visibility. Admins need control — who is verified, who is flagged, and how to intervene without breaking the platform.لا يمكن حلّ رعاية الأطفال بتطبيقٍ واحد. الأمّهات يحتجن تطابقاً سريعاً ومُدقَّقاً. والجليسات يحتجن جدولاً ووضوحاً موثوقاً في الدفع. والمشرفون يحتاجون تحكّماً — مَن مُوثَّق، ومَن مُبلَّغ عنه، وكيف يتدخّلون دون كسر المنصّة.

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

I started with an IEEE 830 software requirements spec — every entity, every relation, every user flow — before any screen was designed. Writing it forced the core insight: a mother is shopping, a babysitter is selling time, and an admin is moderating. Three fundamentally different tasks that produce three fundamentally different information architectures.بدأتُ بوثيقة متطلبات برمجية IEEE 830 — كلّ كيان، وكلّ علاقة، وكلّ تدفّق مستخدم — قبل تصميم أي شاشة. فرضت كتابتها الاستنتاج الجوهري: الأمّ تتسوّق، والجليسة تبيع وقتاً، والمشرف يُدير. ثلاث مهامّ مختلفة جوهرياً تُنتج ثلاث هندسات معلوماتٍ مختلفة جوهرياً.

The user types I defined in the IEEE 830 spec became three personas — each with a different primary task, a one-line story, and the frustration that shaped its app.فئات المستخدمين التي عرّفتها في وثيقة IEEE 830 صارت ثلاثة personas — لكلٍّ مهمةٌ أساسية مختلفة، وقصةٌ من سطر، والإحباط الذي شكّل تطبيقها.

The strategic bet was that a marketplace's hardest problem is keeping three audiences and one backend coherent — so the schema and permission model had to lead, and the UI follow.كان الرهان الاستراتيجي أن أصعب مشكلة في سوقٍ هي إبقاء ثلاثة جماهير وخادمٍ واحد متماسكين — فكان على المخطّط ونموذج الصلاحيات أن يقودا، والواجهة أن تتبع.

Goalالهدف

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

Hypothesisالفرضية

Three focused apps beat one role-switching appثلاثة تطبيقات مركّزة تتفوّق على تطبيقٍ واحد بتبديل الأدوار

Priorityالأولوية

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

Tradeoffالمفاضلة

Higher build cost for honest, focused surfacesكلفة بناءٍ أعلى مقابل واجهاتٍ أمينة ومركّزة

The decision to build three separate apps instead of one with role-switching is a design decision before it's an engineering one. I designed each app in its own Figma file, with its own navigation and vocabulary.قرار بناء ثلاثة تطبيقات منفصلة بدل واحدٍ بتبديل الأدوار قرارٌ تصميمي قبل أن يكون هندسياً. صمّمتُ كلّ تطبيقٍ في ملف Figma خاصٍّ به، بتنقّله ومفرداته.

01 / 04

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

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

Every read and write goes through Supabase RLS. A mother can only see active babysitters within her search radius. A babysitter can only see and modify her own profile and bookings. An admin sees everything — but every admin action is logged. The role enforcement lives in the database, not the client.كلّ قراءةٍ وكتابة تمرّ عبر Supabase RLS. الأمّ ترى فقط الجليسات النشطات ضمن نطاق بحثها. والجليسة ترى وتُعدّل فقط ملفّها وحجوزاتها. والمشرف يرى كل شيء — لكن كلّ إجراء مشرفٍ مُسجَّل. فرضُ الأدوار يعيش في قاعدة البيانات، لا في العميل.

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

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

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

Profile · Scheduleملف · جدول

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

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

Authالمصادقة

Supabase Auth

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

Postgres CDC

Policiesالسياسات

RLS · RBAC

Three apps are tempting to think of as three projects. In practice the apps are the easy part; the hard part is keeping a schema and permission model consistent across three distinct experiences without forking into three copies of the same code.من المُغري التفكير في ثلاثة تطبيقات كثلاثة مشاريع. عملياً، التطبيقات هي الجزء السهل؛ والصعب هو إبقاء المخطّط ونموذج الصلاحيات متّسقَين عبر ثلاث تجارب متمايزة دون التشعّب إلى ثلاث نسخٍ من الكود نفسه.

CareConnect shipped as three focused apps on a single Supabase backend, with access control enforced in the database rather than trusted to the client — so each side's data boundaries are provable in SQL, and every admin action is auditable.أُطلق CareConnect كثلاثة تطبيقات مركّزة على خادم Supabase واحد، بتحكّمٍ بالوصول مفروضٍ في قاعدة البيانات بدل ائتمان العميل عليه — فحدود بيانات كل طرفٍ قابلة للإثبات بـSQL، وكلّ إجراء مشرفٍ قابل للتدقيق.

The three-app decision wasn't an engineering call; it was a UX call that engineering had to honour. The spec-first habit isn't academic — it's the cheapest insurance against drift between three apps and one backend.قرار التطبيقات الثلاثة لم يكن قراراً هندسياً؛ بل قرار تجربةٍ كان على الهندسة احترامه. وعادة المواصفة-أولاً ليست أكاديمية — بل هي أرخص تأمينٍ ضدّ التباعد بين ثلاثة تطبيقات وخادمٍ واحد.

Because trust runs across all three sides, I'd run a usability study per app around its primary task — a mother finding and booking vetted care, a babysitter accepting a booking, a moderator verifying and flagging — then cluster the findings in an affinity diagram and prioritize the fixes that unblock the marketplace loop first.لأن الثقة تسري عبر الأطراف الثلاثة، سأُجري دراسة قابلية استخدامٍ لكل تطبيقٍ حول مهمّته الأساسية — أمٌّ تجد وتحجز رعايةً مُدقَّقة، وجليسةٌ تقبل حجزاً، ومشرفةٌ توثّق وتُبلّغ — ثم أعنقد النتائج في مخطّط تقارب وأرتّب الإصلاحات التي تفكّ حلقة السوق أولاً.

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

The lesson that stuck: most of a multi-sided product's difficulty is information architecture and access control, not screen count. Writing the spec first felt slow and turned out to be the fastest path — it's now my default for anything with more than one type of user.الدرس الذي علق: معظم صعوبة منتجٍ متعدّد الأطراف هندسة معلوماتٍ وتحكّمٌ بالوصول، لا عدد الشاشات. بدا كتابة المواصفة أولاً بطيئاً وتبيّن أنه أسرع طريق — وصار خياري الافتراضي لأي شيءٍ بأكثر من نوع مستخدمٍ واحد.

Next time I'd invest earlier in a shared component layer across the three apps, so visual consistency is enforced by code and not just by discipline.في المرة القادمة سأستثمر مبكراً في طبقة مكوّناتٍ مشتركة عبر التطبيقات الثلاثة، كي يُفرَض الاتّساق البصري بالكود لا بالانضباط وحده.