אפליקציית שירות On-Demand לשרברבים וחשמלאים
מוקד שירות מטפל ב-50 בקשות בשעה, בעלי המקצוע פזורים ברחבי העיר, ולקוחות ממשיכים להתקשר ולשאול: "איפה בעל המקצוע?" ללא אפליקציה ניידת, זה כאוס. בעל המקצוע הממוצע מאבד 20% מזמנו על שיחות חוזרות, והמוקדנים מבזבזים עד 10 דקות על תיאום כל בקשה. אוטומציה עם אפליקציה ניידת יכולה לצמצם את זמן ההקצאה ל-30 שניות ולהעלות את שיעור השלמת הבקשות ב-40%. תרחיש טיפוסי: לקוח מזמין שרברב דרך אתר, בעל המקצוע נקרא בטלפון, והסטטוסים לא מסונכרנים. התוצאה—בעל המקצוע מגיע והלקוח כבר עזב, או שני בעלי מקצוע ניגשים לאותו כתובת. מיקום גיאוגרפי בזמן אמת של בעלי המקצוע, התראות Push על שינויי סטטוס, וצ'אט משולב—המודולים האלה חוזרים על עצמם בפרויקטים שונים אך דורשים התאמה מדויקת לכל עסק. אנו מפתחים אפליקציות turnkey: מחברים את הלקוח לבעל המקצוע תוך דקות, מבטיחים שקיפות סטטוס, ומאפשרים תשלום מקוון. עלות פיתוח MVP טיפוסית נעה בין $30,000 ל-$60,000, בעוד אוטומציה יכולה לחסוך ללקוחות עד $500,000 בשנה בעלויות מוקד.
מה באמת נשבר במהלך הפיתוח
נקודת הכאב הגדולה ביותר היא מפה חיה עם בעלי מקצוע. אם כל בעל מקצוע שולח location כל 3 שניות דרך REST, עם 50 עובדים בו-זמנית, השרת מקבל 1000 בקשות בדקה רק עבור עדכוני מיקום. פתרון: ערוץ WebSocket (ב-Flutter—החבילה web_socket_channel 2.x) בתוספת הגבלת קצב בצד השרת. הלקוח מקבל עדכוני דלתא, לא את הרשימה המלאה. למפה אנו משתמשים ב-flutter_map עם TileLayer מ-OpenStreetMap או Google Maps SDK, בהתאם לתקציב הרישיון. השוואת גישות:
| גישה | זמן השהיה בעדכון | עומס על השרת | דוגמת שימוש |
|---|---|---|---|
| סקירת REST כל 3 שניות | ~3 שניות | 1000 בקשות/דקה עבור 50 בעלי מקצוע | מיושן |
| WebSocket push | <200 אלפיות השנייה | 50 הודעות/דקה (דלתא) | הפרויקט הטיפוסי שלנו |
WebSocket מספק זמן השהיה נמוך פי 10 ומפחית את עומס השרת פי 20.
איך לסנכרן סטטוסי בקשות בזמן אמת?
הנושא השני הוא מכונת המצבים של הבקשה. גרף טיפוסי: created → assigned → accepted → in_progress → completed | cancelled. אם לא אוכפים מעברים בצד השרת ומסנכרנים אותם עם המצב המקומי (באמצעות Riverpod StateNotifier או BLoC), הלקוח רואה "בעל המקצוע בדרך" גם לאחר ביטול—כי הודעת ה-push הגיעה מאוחר יותר מאשר המשתמש רענן את המסך ידנית. אנו פותרים זאת באמצעות FCM data messages במקום notification messages: האפליקציה מחליטה מה להציג בהתבסס על המצב הנוכחי.
נקודה נוספת: דירוגים וביקורות לא נפתחים עד שהבקשה הושלמה. אם לא מוסיפים בדיקת סטטוס בצד השרת לפני רישום ביקורת, בעלי מקצוע מקבלים דירוגים על ביקורים שנכשלו—ראיתי את זה בכמה פרויקטים.
טכנולוגיות וארכיטקטורה
Flutter + Dart היא הבחירה העיקרית שלנו לרוחב-פלטפורמות: קוד אחד מכסה iOS ואנדרואיד, עם קריאות native דרך MethodChannel למיקום גיאוגרפי ברקע (background_locator_2) וטיפול בשיחות נכנסות דרך VOIP (CallKit ב-iOS, ConnectionService באנדרואיד). הצ'אט המובנה משתמש ב-Firebase Realtime Database או WebSocket מותאם אישית, עם קבצי מדיה (תמונות של התקלה) דרך Firebase Storage או S3 עם כתובות presigned.
מבחינה ארכיטקטונית: Clean Architecture עם שכבות domain / data / presentation. Repositories מבודדים את הלוגיקה ממקורות הנתונים—קל להחליף את Firebase ב-API מותאם אישית ללא שכתוב ה-UI. GetIt כ-service locator ל-DI, Dio עם interceptors ל-REST, hive לשמירת בקשות במצב לא מקוון.
אינטגרציות מרכזיות:
- Google Maps SDK / Yandex MapKit — מסלול מבעל המקצוע ללקוח
- Firebase Cloud Messaging — התראות על שינויי סטטוס
- Stripe / CloudPayments / YooKassa — תשלום עם סיום
- Twilio או Vonage — מיסוך מספרים לשיחות
- OneSignal — הודעות שיווקיות וקמפיינים לשימור
לפי App Store Review Guidelines, האפליקציה חייבת לבצע את הפונקציה המוצהרת שלה, ולכן מיקום גיאוגרפי ברקע משמש רק במהלך הזמנה פעילה.
למה לבחור ב-Flutter?
Flutter מקצר את זמן הפיתוח ב-30% בהשוואה לגישות native וב-20% בהשוואה ל-React Native (בהתבסס על המדידות שלנו בחמישה פרויקטים). קוד יחיד מפשט את התחזוקה, וערוצי native (MethodChannel) מספקים גישה מלאה ל-API של iOS/אנדרואיד. עבור אפליקציה עם מפות, מיקום גיאוגרפי והתראות push, זו הבחירה האופטימלית.
אישור בעלי מקצוע בנפרד
אימות אינו רק טופס עם שדות. הוא דורש העלאת מסמכים (דרכון, רישיון), מיתון ידני, או אינטגרציה עם שירות אימות (למשל, Sber ID לעצמאים). ב-Flutter: image_picker + העלאת multipart dio, סטטוס אימות דרך polling או WebSocket. עד שהחשבון מאומת, דגל is_verified: false חוסם קבלת בקשות ברמת ה-middleware של ה-API.
מה כלול באפליקציית השירות On-Demand
- אפליקציה ניידת ללקוחות (iOS + אנדרואיד)
- אפליקציית בעל מקצוע עם ממשק נפרד
- פאנל ניהול (web) למוקדנים
- צ'אט בין לקוח לבעל מקצוע
- התראות Push (FCM / APNs)
- אינטגרציה עם מערכת תשלומים
- תיעוד (מפרטי API, הוראות פריסה)
- תמיכה לאחר השקה (חודשיים בחינם)
תהליך
- בדיקת דרישות — קביעת מודל מונטיזציה (עמלה לכל בקשה או מנוי לבעל מקצוע), גיאוגרפיה (עיר אחת או ארצי), צורך בלוח מחוונים web למוקדן.
- עיצוב — ERD, דיאגרמת מכונת מצבים לבקשות, חוזי API (OpenAPI 3.0).
- UI/UX — אב-טיפוס ב-Figma, זרימות נפרדות ללקוח ולבעל מקצוע.
- פיתוח — ספרינטים של שבועיים, CI/CD דרך Fastlane + GitHub Actions.
- בדיקות — בדיקות אינטגרציה עם
flutter_test, QA ידני על מכשירים אמיתיים. - פרסום — App Store + Google Play, הגדרת ASO, צילומי מסך ותיאורים.
לוחות זמנים וניסיון
| שלב | משך |
|---|---|
| MVP (לקוח + בעל מקצוע, תכונות ליבה) | 10–16 שבועות |
| פלטפורמה מלאה עם פאנל ניהול | 20–28 שבועות |
אנו מפתחים אפליקציות ניידות כבר למעלה מ-7 שנים והשקנו 15+ מוצרים בענף השירותים. עם ניסיון של למעלה מ-7 שנים ו-15+ פרויקטים שהושלמו, יש לנו את המומחיות לבנות אפליקציות שירות חזקות. עם שיעור שביעות רצון של 95% ודירוג פרויקטים ממוצע של 4.8 כוכבים, אנו מבטיחים איכות. העלות מחושבת לאחר ניתוח המפרט הטכני—יותר מדי תלוי במספר קטגוריות בעלי המקצוע ובכיסוי הגיאוגרפי.
טעויות יקרות טיפוסיות
- יישום מיקום גיאוגרפי ללא
background_locator—בעל המקצוע "נעלם" מהמפה כשהאפליקציה ממוזערת באנדרואיד 12+ עקב Doze Mode. - אחסון אסימוני FCM במסד נתונים מקומי ללא TTL—אחרי 3 חודשים, 30% מהאסימונים פגים והודעות push מפסיקות להישלח.
- אי הפרדת ערוצי FCM ללקוח ולבעל מקצוע באפליקציה אחת—שניהם מקבלים התראות זה של זה כשהתפקידים מתחלפים.