איך מפתחים אפליקציה לעסק: מהשאלה אם צריך בכלל ועד תחזוקה אחרי ההשקה

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

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

האם העסק שלכם צריך אפליקציה בכלל

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

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

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

אילו סוגי אפליקציות יש לעסקים

כשאומרים ״אפליקציה לעסק״ מתכוונים לאחד מארבעה דברים, ולעתים קרובות לשניים מהם יחד. כדאי לקרוא להם בשם כבר בבריף, כי כל אחד נבנה אחרת ובודקים אותו אחרת.

אפליקציה ללקוחות

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

אפליקציה פנימית לצוות

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

מערכת ניהול ולוח בקרה

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

פלטפורמת SaaS

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

שלבי פיתוח אפליקציה: מה קורה בכל שלב ומה מקבלים

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

1. אפיון ודרישות

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

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

2. תרשימי זרימה ואב טיפוס

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

את שלבי המחקר, התרשימים והסקיצות אפשר לראות בתיק עיצוב המוצר של Névé, שמראה איך האפליקציה הבדויה של הקליניקה עוצבה, מה נבדק ומה השתנה אחרי הבדיקות.

3. עיצוב ומערכת עיצוב

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

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

4. פיתוח: צד המשתמש, שרת, מערכת ניהול וחיבורים

הפיתוח מתחלק לארבעה חלקים, וכדאי שההצעה תפרט כל אחד:

• צד המשתמש (Front end): המסכים שהלקוח או העובד רואה, בווב, בנייטיב או בשניהם. כאן נכנסים גם עברית ו־RTL, נגישות ומהירות.
• שרת ומסד נתונים (Back end): איפה הנתונים נשמרים, מי רשאי לגשת למה, כניסה ואימות משתמשים, גיבויים ולוגים.
• מערכת ניהול: המסוף שבו הצוות מנהל לקוחות, הזמנות ותוכן בלי לפנות למפתח. בלעדיה כל שינוי קטן הופך לבקשת שירות.
• חיבורים: סליקה, יומן, CRM, הנהלת חשבונות, הודעות SMS, מייל ווואטסאפ. חלקם דורשים מנוי לשירות חיצוני, וחלקם תלויים באישור של הספק השני.

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

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

5. בדיקות

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

6. הגשה לחנויות

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

7. השקה

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

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

8. תחזוקה ועדכונים

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

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

להתחיל קטן: גרסה ראשונה ולא הכול בבת אחת

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

1. רשמו את כל הרעיונות לרשימה אחת.
2. סמנו את הפעולה שבלעדיה אין סיבה לאפליקציה (למשל קביעת תור).
3. הוסיפו רק את מה שהפעולה הזו צריכה כדי לעבוד: כניסה, תשלום אם יש, התראה, ומסך ניהול לצוות.
4. כל השאר עובר לרשימת ״אחרי ההשקה״, עם סדר עדיפויות.
5. אחרי כמה שבועות של שימוש, מחליטים לפי מה שקרה בפועל מה נכנס בגרסה הבאה.

על הגישה הזו, איך מגדירים גרסה ראשונה ומה מודדים אחריה, כתבנו במדריך לפיתוח MVP.

App Store ו־Google Play: חשבונות, עלויות ובדיקה

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

• אפל: לפי עמוד ההרשמה של Apple Developer Program, התוכנית עולה 99 דולר לשנת חברות (המחיר יכול להשתנות לפי אזור). ארגון נרשם כישות משפטית עם מספר D-U-N-S, ומי שרושם אותו צריך סמכות לחייב את הארגון בהסכמים. גם שם עסקי שאינו ישות משפטית לא מתקבל.
• גוגל: לפי עמוד ההרשמה ל־Play Console, יש דמי הרשמה חד־פעמיים של 25 דולר, ואפשר לפתוח חשבון אישי או חשבון ארגוני.
• בדיקה סגורה בחשבון אישי: חשבון מפתח אישי חדש בגוגל צריך, לפי דרישות הבדיקה של Google Play, לפחות 12 בודקים שהצטרפו ברציפות במשך 14 ימים לפני שאפשר להפיץ לכולם. זו עוד סיבה לפתוח חשבון ארגוני על שם העסק.

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

פרטיות, מידע אישי ומחיקת חשבון

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

• מדיניות פרטיות: לפי סעיף 5.1.1(i) בהנחיות של אפל, כל אפליקציה צריכה קישור למדיניות פרטיות גם בדף שלה בחנות וגם בתוך האפליקציה, שמסבירה איזה מידע נאסף, למה, עם מי הוא משותף, כמה זמן נשמר ואיך מבקשים למחוק אותו.
• מחיקת חשבון: אפל דורשת בסעיף 5.1.1(v) שאפליקציה שמאפשרת לפתוח חשבון תאפשר גם למחוק אותו מתוך האפליקציה. גוגל דורשת, לפי מדיניות מחיקת החשבון של Google Play, גם מסלול מחיקה בתוך האפליקציה וגם קישור בווב שדרכו אפשר לבקש מחיקה של החשבון והמידע.
• מינימום מידע: לאסוף רק את מה שהאפליקציה באמת צריכה. כל שדה נוסף הוא עוד מידע שצריך לשמור, לאבטח ולהסביר.
• הרשאות וגישה: מי בצוות רואה מה, מי יכול לייצא רשימת לקוחות, ואיפה נשמר תיעוד של מי ניגש למה.
• איפה המידע יושב: באיזה שירות ענן, באיזה אזור, ומי מחזיק את הגישה לחשבון הזה.

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

של מי הקוד, החשבונות והנתונים

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

• הקוד נשמר במאגר (למשל GitHub) שנמצא בחשבון של העסק, ואתם בעלי ההרשאה הגבוהה בו.
• חשבונות המפתח באפל ובגוגל פתוחים על שם העסק, לא על שם הספק. העברת אפליקציה בין חשבונות אפשרית אבל מסורבלת.
• חשבון הענן, הדומיין, שירות המייל ושירותי ההודעות רשומים על שמכם, ואתם משלמים עליהם ישירות או שיש לכם גישה מלאה.
• החוזה קובע שזכויות הקוד וקובצי העיצוב עוברות אליכם בסיום התשלום, ומפרט רכיבים של צד שלישי ורישיונות.
• יש תיעוד בסיסי: איך מריצים את המערכת, איך מעלים גרסה, ואילו שירותים חיצוניים היא צריכה, כך שמפתח אחר יוכל להמשיך.

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

טעויות נפוצות בפיתוח אפליקציה לעסק

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

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

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

כמה זה עולה וכמה זמן זה לוקח

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

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

דוגמה: אפליקציית זימון תורים לקליניקה

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

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

זה בדיוק מה שהדוגמה של Névé מראה, ואת המקרה הזה פירטנו לעומק במדריך לאפליקציית זימון תורים לקליניקות.

איך בוחרים חברה או סטודיו לפיתוח אפליקציה, ומה לשאול

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

1. מה נכלל באפיון, והאם מקבלים מסמך אפיון ורשימת מסכים לפני שמתחייבים לכל הפרויקט.
2. האם יש אב טיפוס לחיץ לפני הפיתוח.
3. נייטיב, ווב או שניהם, ולמה דווקא זה עבור העסק שלכם.
4. אילו חיבורים למערכות נכללים, בשם, ומה קורה אם ספק חיצוני משנה משהו.
5. האם מערכת הניהול כלולה, ומה הצוות יוכל לשנות בה בלי מפתח.
6. כל כמה זמן תקבלו גרסת בדיקה, ואיך נראית בדיקת הקבלה.
7. של מי הקוד, המאגר, חשבונות החנויות וחשבון הענן.
8. מה כלול בתחזוקה, מה זמן התגובה לתקלה, ומה עולה בשנה השנייה.
9. מי בפועל כותב את הקוד: הצוות של הספק או קבלן משנה.
10. לוח זמנים עם תאריכים, ומה קורה אם החלטות או תוכן מתעכבים אצלכם.

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

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

מה Libra בונה כאן

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

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

עוד בנושא אפליקציות ומערכות

• אפליקציה או אתר: מתי העסק באמת צריך אפליקציה, ומתי אתר או PWA מספיקים השוואהאתר רספונסיבי, אפליקציית ווב שמתקינים (PWA), אפליקציה חוצת פלטפורמות או נייטיב: טבלת השוואה, עמלות החנויות, התראות באייפון, ומתי באמת צריך אפליקציה.
• כמה עולה לפתח אפליקציה לעסק: טווחי מחיר, מה קובע אותם ומה עולה כל שנהטווחי מחיר לפיתוח אפליקציה בישראל: אפליקציית ווב, אפליקציה עם מערכת ניהול, נייטיב, פלטפורמה ו-MVP. מה מייקר, מה עולה כל שנה ואיך קוראים הצעת מחיר.
• פיתוח MVP: איך בוחרים מה נכנס לגרסה הראשונה, כמה זמן זה לוקח ומה מודדיםמה זה MVP ומה הוא לא, איך בוחרים תהליך מרכזי אחד, מה משאירים בחוץ, קוד או נו־קוד, לוח זמנים, מה מודדים אחרי ההשקה, ודף עבודה להגדרת ההיקף.
• פיתוח מערכת ניהול לעסק: מתי לבנות, מה נכנס בה ואיך מגדירים דרישותמה זו מערכת ניהול בהתאמה אישית, מתי כלי מדף עם חיבורים מספיק, אילו מודולים יש בה, הרשאות, חיבורים, בעלות על הנתונים, אבטחה, ורשימת דרישות מוכנה.
• אפליקציה לזימון תורים לקליניקה: יומן, תזכורות, מקדמות ופרטיותאיך בונים זימון תורים לקליניקה: ווב או אפליקציה, לוגיקת יומן של מטפלים, חדרים ומשכי טיפול, תזכורות בוואטסאפ, מקדמות וביטולים, פרטיות מידע רפואי ורשימת בדיקה.

שאלון קצר

מה מתאים לכם?

מה הכי קרוב למה שאתם צריכים?

להבין אם צריך אפליקציה בכלללדעת כמה זה יעלהגרסה ראשונה קטנהמערכת ניהול לצוות

שאלות נפוצות

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

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

כמה זמן לוקח לפתח אפליקציה?

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

האם כל עסק צריך אפליקציה?

לא. אפליקציה מצדיקה את עצמה כשלקוחות או עובדים חוזרים אליה לעתים קרובות לאותה פעולה. אם הצורך הוא להופיע ולקבל פניות, אתר עדיף, ואם הבעיה אצל הצוות, לרוב צריך מערכת ניהול.

כמה עולה לפרסם אפליקציה ב־App Store וב־Google Play?

Apple Developer Program עולה 99 דולר לשנה, ו־Google Play Console גובה דמי הרשמה חד־פעמיים של 25 דולר. אפליקציית ווב או מיני־אפליקציה בטלגרם לא דורשות את החשבונות האלה.

האם האפליקציה חייבת לאפשר מחיקת חשבון?

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

של מי הקוד של האפליקציה?

זה נקבע בחוזה, ולכן כדאי לוודא בכתב שהקוד, המאגר, חשבונות החנויות וחשבון הענן רשומים על שם העסק ועוברים אליכם בסיום התשלום.

מה זה אפיון אפליקציה?

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

להתחיל

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

שלחו בריף קצר: שלוש שאלות חובה, והשאר רק אם בא לכם. חוזרים במייל עם כיוון, מחיר ותאריך כתובים.

לשלוח בריף←השירות: פיתוח אפליקציות ומערכות←