מה אנחנו שולחים החוצה.

01תקציר ושינוי גבולות

בתוך MVP / לא בתוך MVP

02סטאק וארכיטקטורה

קוד-בייס אחד ב-TypeScript. אפליקציות נייטיב אמיתיות דרך Expo. בקאנד מנוהל ב-Supabase. דו-פלטפורמי מהשורה הראשונה; את צינור הבנייה של iOS בלבד נריץ לפיילוט הראשון.

מה במכוון לא בסטאק

• Redux, MobX (יותר מדי — TanStack Query + zustand מספיקים).
• Firebase (נתונים יחסיים, RLS וג׳וינים מתאימים יותר ל-Postgres).
• בקאנד מותאם / שרת Node (Edge Functions של Supabase מטפלים בצרכי השרת הספורים).
• מודולים נייטיב מחוץ ל-Expo prebuild (יאט את זרימת EAS).
• OneSignal / ספק פוש חיצוני (expo-notifications מספיק).

03מודל הנתונים ובידוד משפחה

הכל מתויג למשפחה. מדיניות Row-Level Security של Postgres אוכפת זאת ברמת השרת — אי-אפשר לשכוח שכבת הגנה בלקוח. משתמש רואה רק שורות ש-family_id שלהן שייך למשפחות שהוא חבר בהן.

טבלאות (MVP פיילוט)

users              id (uuid, = auth.users.id) · phone · display_name · preferred_lang · created_at · last_seen_at
families           id · display_name · default_split_jsonb · timezone · currency · created_by · created_at
family_members     family_id · user_id · role ('parent_a'|'parent_b') · joined_at  · (PK: family_id, user_id)
invites            id · family_id · phone · code · invited_by · expires_at · used_at
children           id · family_id · display_name · birthdate · framework · notes · created_at
expenses           id · family_id · title · category · child_ids[] · amount_minor · currency
                   · paid_by_user_id · requested_from_user_id
                   · split_type ('equal'|'percent'|'fixed') · share_paid_by_minor · share_other_minor
                   · due_date · status · receipt_path · created_by · created_at · updated_at
expense_events     id · expense_id · actor_user_id · action · comment · created_at
notifications      id · user_id · type · entity_table · entity_id · body_he · body_en · read_at · created_at

מכונת מצבים — הוצאה

כל מעבר רושם שורה ב-expense_events עם הפועל והערה. 4 מצבי-העל של הדאשבורד נגזרים: פתוח / ממתין_לך / ממתין_לצד / נסגר.

מדיניות RLS (Postgres)

-- helper: families the auth user belongs to
create function patia.my_family_ids() returns setof uuid
  language sql security definer stable as $$
  select family_id from family_members where user_id = auth.uid();
$$;

-- every table follows this shape
alter table expenses enable row level security;

create policy "read own family" on expenses
  for select using (family_id in (select patia.my_family_ids()));
create policy "write own family" on expenses
  for insert with check (family_id in (select patia.my_family_ids()));
create policy "update own family" on expenses
  for update using  (family_id in (select patia.my_family_ids()))
                with check (family_id in (select patia.my_family_ids()));
create policy "delete own family (creator only)" on expenses
  for delete using (family_id in (select patia.my_family_ids())
                    and created_by = auth.uid());

04מודולי MVP פיילוט

המוצר הקטן ביותר שמוכיח את רעיון יחידת-העבודה. חמישה מודולים, מקצה לקצה.

05מפת דרכים שלבית — מתוכננת, לא מותנית

‏MVP פיילוט הוא ההתחלה של בנייה שלבית, לא הימור חד-פעמי. השלבים למטה מחויבים במפת הדרכים; מה שמותנה הוא הקצב, הנגזר מהפאנל של הפיילוט. לכל שלב יש טריגר "מוכן כאשר" ברור, כדי שלא נשלח עוד מוצר לתוך ואקום של משוב.

פירוט פר שלב (שלב 2 ואילך)

06בקלוג V2 / V3

07התראות (MVP פיילוט)

שעות שקט (22:00–07:00 שעון ישראל) דלוקות כברירת מחדל, יהיו ניתנות לכיבוי מ-V2. עברית קודם; טקסט אנגלי משמש כש-preferred_lang הוא en.

08בעלות על מידע ומחיקה

הורים גרושים יכולים להישבר שוב. הורה יכול לדרוש לעזוב את פטיה בזמן שההורה השני עדיין נשען על הרשומה המשותפת. המדיניות למטה מאזנת בין פרטיות אישית לבין שלמות הרשומה המשותפת, ומתוכננת להיות בלתי-ניתנת לנשק: הורה אחד לא יכול להשתמש ב"מחק את החשבון שלי" כדי למחוק את היסטוריית המציאות המוסכמת של ההורה השני.

שלוש קטגוריות, שלושה מחזורי חיים

זרימת היציאה (≥ 7 מסכים, בכוונה לא חלקה)

1. הגדרות → מחיקת חשבון פטיה. הסבר פשוט בעברית למה קורה לשלוש הקטגוריות.
2. חבילת ייצוא חובה: PDF + JSON של כל רשומה שנגעו בה. לוקחים את העותק שלהם של ההיסטוריה.
3. אנונימיזציה אופציונלית: החלפת שם התצוגה ב-UI של ההורה הנשאר ל"הורה לשעבר" (אחרת השם המקורי נשאר).
4. תקופת התקררות: 7 ימים שבהם החשבון מושעה (לא נמחק). הקלקה אחת לביטול.
5. ביום 8: מחיקה קשיחה של קטגוריות אישי + סולו. הרשומות המשותפות נשמרות. הטוקנים מבוטלים. ההתראות נפסקות. שורת auth נמחקת.

מקרי קצה

• ‎שני ההורים מבקשים מחיקה: המשפחה נמחקת כליל, כולל רשומות משותפות. תקופת התקררות של 7 ימים; שני הצדדים חייבים להישאר במצב "ביקש מחיקה" כדי שהשעון ירוץ.
• ‎הפעלה מחדש: הורה שמחק וחוזר מאוחר יותר מתחיל חשבון חדש. ההיסטוריה המשותפת שהשאיר היא לקריאה בלבד עבורו, ולא יוכל ליצור רשומות חדשות במשפחה ההיא בלי הזמנה חדשה.
• ‎מעצר משפטי: אם אחד הצדדים מסמן רשומה כ"עשויה להיות נחוצה בבית משפט", היא לא נמחקת בשום זרימת מחיקה ונשמרת עד שהשניים משחררים, או 7 שנים.

09מדידה ויעדים

מה לוגים (PostHog או Supabase analytics)

• פאנל: התקנה → OTP → משפחה → הזמנה → הצטרפות → הוצאה ראשונה → סגירה ראשונה.
• חותמות זמן פר אירוע, בלי PII מעבר ל-user_id ול-family_id. קבלות לא נכנסות ללוג בשום צורה.

יעדי פיילוט — 10 משפחות, 21 יום, נעולים לפני גיוס

פאנל קשיח עם ספי המשך / עצירה. קובעים את המספרים עכשיו, רושמים, ומחויבים לפעול לפיהם — להרוג או לפבט, לא "בוא ניתן עוד חודש".

חוק ההחלטה

• ‎כל חמשת ספי ההמשך נחצו → בונים את Phase 2 (יומן והחלפות) כמתוכנן.
• ‎3–4 ספים נחצו, 1–2 כישלונות מבודדים → מתקנים את הצעד שכשל (נוסח הזמנה, UX של הוצאה, פתיחת מחלוקת וכו׳) ומריצים שוב עם משפחות חדשות. לא מתקדמים ל-Phase 2.
• ‎≤ 2 ספים נחצו, או ששני ההורים לא פעילים ביותר מ-6/10 משפחות → השערת יחידת-העבודה לא נוחתת. פותחים מחדש את האידאציה לפני עוד קוד.

סיגנלים איכותיים (ראיונות, NPS, "וואטסאפ נרגע") מועילים אבל לעולם לא מכריעים לבד. הפאנל מחליט.

10תוכנית פריסה (iOS תחילה, בשלבים)

הנתיב ל"בכף היד"

1. ריפו: Nirkoso/patia ב-GitHub (פרטי).
2. Expo + Supabase מוקמים; אימות + משפחה + ילדים + הוצאות + דאשבורד מול Supabase Cloud.
3. ‎eas build --platform ios --profile preview מה-Mac → עולה ל-App Store Connect.
4. להוסיף אותך (ואת משתמשי הפיילוט) כבודקים פנימיים ב-TestFlight → התקנה דרך אפליקציית TestFlight.
5. לחזור על המחזור. EAS Update שולח שינויי JS בלבד OTA בלי בנייה חדשה.

Apple — מה מצפים

• TestFlight פנימי (עד 100 בודקים): בלי סקירה, מיידי. זה נתיב הפיילוט.
• TestFlight חיצוני: סקירה קלה בבנייה הראשונה (~24 שעות).
• סקירת פרודקשן ב-App Store: 24–72 שעות בדרך כלל.
• חובה לפרודקשן: privacy manifest, מחיקת חשבון בתוך האפליקציה, טקסט הרשאת פוש, מחרוזת ATT (גם אם לא בשימוש).

Google Play — מסלול מקביל בהמשך

• ‎$25 חד-פעמי. נפתח כשנהיה מוכנים לפיילוט אנדרואיד.
• בדיקה סגורה (חשבונות אישיים פוסט-2023): 12+ בודקים שאישרו, 14 ימים רצופים, לפני שאפשר לבקש גישה לפרודקשן. אי-אפשר לדלג.
• סקירת פרודקשן: 1–3 ימים, לפעמים 7+ לאפליקציות חדשות.
• EAS Build בונה AAB; שליחה בפקודה אחת.

11שאלות פתוחות

• סימן מסחר / דומיין .il — האם "פטיה" / "Patia" פנוי? בדיקה מהירה לפני יצירת רשומת App Store.
• ‎Sign-in-with-Apple — נדרש אם יש Social sign-in אחר (Google/Facebook וכו׳). OTP במייל דרך Supabase לא נחשב "Social", אז אפשר לדלג בפיילוט. אישור שזה עדיין תקף כשנוסיף OTP בטלפון ב-Phase 1.5.
• אזור אירוח — Supabase EU (Frankfurt) לעומת US East. EU מומלץ להורים בישראל ולעמדת GDPR בעתיד.
• ספק טלמטריה — PostHog Cloud EU לעומת לוגים של Supabase. ל-PostHog פאנלים טובים יותר OOTB.
• דיווח קריסות — Sentry בחינם לנייד, אישור?
• מגשר פיילוט — האם מפנה 3–5 זוגות לבדיקה הסגורה? מתי?