פיתוח אפליקציות מובייל למשלוחי מזון

אנחנו צוות פיתוח מובייל עם ניסיון רב בפודטק. במהלך הזמן הזה, סיפקנו 20+ פרויקטים — מאפליקציות למסעדה בודדת ועד אגרגטורים בקנה מידה מלא עם מאות סניפים. לפי הנתונים שלנו, 70% מהמשתמשים מצפים למעקב בזמן אמת, והיעדרו מעלה את עומס התמיכה ב-30–40%. אנו מטמיעים את הניואנסים הללו בארכיטקטורה מהיום הראשון.

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

קבלו הערכת פרויקט תוך 2–3 ימים. שוחחו על המשימה שלכם עם המהנדסים שלנו — הם יעזרו לכם לבחור את הארכיטקטורה האופטימלית.

ארכיטקטורה ומודולים מרכזיים

איזו ארכיטקטורה מתאימה לעסק שלכם?

אנו מפתחים שלוש גישות ארכיטקטוניות כדי להתאים לכל תקציב.

אגרגטור (כמו Delivery Club) — מסעדות רבות, מאגר שליחים משותף, הלקוח בוחר מתוך מספר סניפים. שיגור מורכב, API להטמעת מסעדות, צי שליחים עצמי או מיקור חוץ. לוח זמנים לפיתוח: מ-5 חודשים.

משלוח עצמי של מסעדה — מסעדה אחת או רשת, שליחים עצמיים. פשוט יותר ארכיטקטונית, אבל נדרש פאנל ניהול למנהל המסעדה. MVP: מ-8 שבועות.

פלטפורמת White-label — אותה ארכיטקטורה כמו האגרגטור, אבל מותאמת למסעדה ספציפית או לרשת קטנה. דרך ביניים.

תפריט ועגלה

תפריט מסעדה הוא לא רק רשימת מנות. קטגוריות, תת-קטגוריות, פריטים עם אפשרויות (גודל פיצה, מידת עשייה, תוספות). מבנה הנתונים חייב לתמוך במודיפיירים: "הוסף גבינה +$1–1", "בחר רוטב" (בחירה יחידה חובה), "הסר בצל" (אופציונלי). מספר המודיפיירים למנה יכול להגיע ל-10, והמרה לאחר בחירת פריטים היא 65%.

{
  "id": 42,
  "name": "Пицца Маргарита",
  "base_price": 590,
  "modifier_groups": [
    {
      "id": 1,
      "name": "Размер",
      "required": true,
      "min_select": 1,
      "max_select": 1,
      "options": [
        {"id": 11, "name": "25 см", "price_delta": 0},
        {"id": 12, "name": "35 см", "price_delta": 150}
      ]
    },
    {
      "id": 2,
      "name": "Дополнительно",
      "required": false,
      "max_select": 3,
      "options": [
        {"id": 21, "name": "Двойной сыр", "price_delta": 80},
        {"id": 22, "name": "Острый перец", "price_delta": 0}
      ]
    }
  ]
}

לוגיקת עגלה בצד הלקוח: כל שורת פריט מאחסנת את ה-{ "id": 42, "name": "Пицца Маргарита", "base_price": 590, "modifier_groups": [ { "id": 1, "name": "Размер", "required": true, "min_select": 1, "max_select": 1, "options": [ {"id": 11, "name": "25 см", "price_delta": 0}, {"id": 12, "name": "35 см", "price_delta": 150} ] }, { "id": 2, "name": "Дополнительно", "required": false, "max_select": 3, "options": [ {"id": 21, "name": "Двойной сыр", "price_delta": 80}, {"id": 22, "name": "Острый перец", "price_delta": 0} ] } ] } הבסיסי בתוספת product_id שנבחרו. המחיר מחושב בצד הלקוח לתצוגה, ובצד השרת להזמנה הסופית. העגלה נשמרת מקומית כשהאפליקציה נסגרת.

למה חשוב אימות צד-שרת של אזורי משלוח?

מסעדה לא מספקת לכל מקום, והמחירים משתנים לפי אזור. אזורים מוגדרים על ידי פוליגונים — לא עיגולים פשוטים. כשהמשתמש מזין כתובת למשלוח, אנו בודקים אם היא נופלת בתוך פוליגון: בדיקה בצד הלקוח (באמצעות Google Maps modifier_ids או פורט של turf.js ב-Dart/Swift/Kotlin) לחוויית משתמש מהירה, ובדיקה בצד השרת כסמכות סופית בעת יצירת ההזמנה.

PostGIS על השרת: containsLocation(point, polygon) — אמין ומדויק. PostGIS טוב פי 10 מספריות גיאו בצד הלקוח ומבטיח עקביות בנתונים.

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

זמן הזמנה וסטטוסים

המשתמש רוצה לדעת: "מתי זה יהיה מוכן ומתי זה יגיע?" זמן ההכנה הוא פרמטר של המסעדה שיכול להשתנות לפי עומס. המנהל מגדיר את הזמן הנוכחי בפאנל הבקרה. זמן המשלוח מוערך לפי מרחק ומהירות שליח. זמן משלוח ממוצע באזור הוא 15–30 דקות. תצוגה סופית: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat)) (בישול 25 + משלוח 20). הימנעו מהבטחת זמן מדויק ללא אינטגרציה עם מערכת שיגור אמיתית.

התראות Push בכל מעבר סטטוס. Firebase Cloud Messaging — "~45 минут" התראות לעיבוד ברקע, data לתצוגה. ב-iOS — notification עם קטגוריה UNNotificationContent, באנדרואיד — ORDER_UPDATE ייעודי.

איך מעקב שליחים מפחית את עומס התמיכה?

ללא מעקב בזמן אמת, משתמשים מתקשרים לתמיכה — כל שיחה עולה למסעדה בממוצע $1–1. אפליקציה עם מפה ואנימציה מפחיתה את עומס מוקד הטלפוני ב-30–40% ומעלה את ה-NPS ב-15 נקודות.

שער תשלום

תשלומים מקוונים (CloudPayments / YooKassa / Tinkoff Acquiring) + מזומן במשלוח + Apple Pay / Google Pay. אישור מראש (hold) הוא נוהג סטנדרטי למשלוחים: הסכום מוקפא בעת יצירת ההזמנה, ונקלט בעת האישור. אם המסעדה לא מקבלת את ההזמנה, ההקפאה משתחררת אוטומטית. קודי קידום ומערכת נאמנות — מודול נפרד. מיושם בשלב אישור ההזמנה, ההנחה מחושבת בצד השרת.

אפליקציית ניהול למסעדה

בלעדיה, המערכת לא יכולה לפעול בייצור. סט מסכים מינימלי:

• הזמנות נוכחיות (רשימה עם טיימרים, סטטוסים)
• ניהול רשימת השבתה (כפתור "פריט אזל")
• זמן הכנה נוכחי (שדה קלט, מיושם מיד)
• שעות פעילות

זה יכול להיות פאנל ווב — לא בהכרח אפליקציית מובייל לשלב הראשון.

איך אנחנו מפתחים? תוכנית שלב-אחר-שלב

1. ניתוח — לימוד תהליכים עסקיים, אזורי משלוח, דרישות תפריט. תיעוד במפרט טכני.
2. עיצוב — יצירת ארכיטקטורה (ERD, דיאגרמות זרימה), הגדרת מחסן הטכנולוגיות.
3. עיצוב UI/UX — הפקת מוקאפים בהתאם להנחיות הפלטפורמה.
4. פיתוח — ספרינטים של שבועיים, דמואים יומיים ללקוח.
5. בדיקות — יחידה, אינטגרציה, UI, בדיקות עומס (עד 1000 הזמנות/דקה).
6. פריסה — פרסום ב-App Store וב-Google Play, הגדרת CI/CD.
7. תמיכה — תיקוני באגים, שיפורים במסגרת אחריות.

מה כלול

עם סיום הפרויקט, אנו מספקים:

• קוד מקור של האפליקציה (iOS/Android/Flutter)
• תיעוד API (Swagger/OpenAPI)
• הוראות פריסת Backend
• גישה ל-App Store Connect ול-Google Play Console
• פאנל ניהול למסעדה
• הדרכת צוות (2–3 שעות)
• אחריות קוד ל-3 חודשים

קבלו ייעוץ לפרויקט שלכם. צרו קשר עם המהנדסים שלנו — נדון בפרטים.