"אנחנו צריכים אפליקציה" הוא לרוב המשפט הראשון בפגישה, והוא לרוב לא השאלה. אפליקציה היא אחת משלוש דרכים להגיש מוצר למשתמש, ולכל אחת מהן יש מקרים שבהם היא הבחירה הנכונה ומקרים שבהם היא בזבוז. המדריך הזה לא ממליץ על כלי ולא על פלטפורמה; הוא נותן את השאלות שמחליטות בין השלוש — ואת התנאים שבהם עוברים מאחת לשנייה. את הבחירה בטכנולוגיית האפליקציה עצמה (React Native, Flutter, Native) עושים רק אחרי שהוחלט שבכלל צריך אפליקציה, וזה נושא למדריך אחר.
מה המשתמש צריך לבצע? פעולה, תדירות ומכשיר
לפני שמשווים חלופות, מתארים את השימוש בשלושה משתנים. התיאור הזה — ולא העדפה של מישהו בחדר — הוא שמכריע ברוב המקרים:
| משתנה | השאלה | לאן זה מטה |
|---|---|---|
| פעולה | מה המשתמש עושה בפועל — קורא, ממלא, מצלם, משלם, מנווט, מתקשר? | פעולות שדורשות חומרה (מצלמה ברצף, מיקום ברקע, בלוטות', סריקה) מטות לאפליקציה; קריאה, מילוי ותשלום עובדים בדפדפן |
| תדירות | כמה פעמים ביום / בשבוע / בשנה אותו משתמש חוזר? | כמה פעמים ביום — אייקון על המסך שווה את ההתקנה; כמה פעמים בשנה — אף אחד לא יתקין |
| מכשיר ותנאים | טלפון אישי, טאבלט במחסן, מחשב במשרד? יש רשת תמיד? מי מחליט מה מותקן? | עבודה בלי רשת ומכשירים מנוהלים מטים לאפליקציה; מחשב במשרד ומשתמשים חיצוניים מטים לדפדפן |
שלוש חלופות: יכולות ומגבלות לפי שימוש
אפליקציה מהחנויות
אפליקציה מותקנת נותנת את הגישה המלאה ביותר למכשיר: חיישנים, מיקום ברקע, התראות שמגיעות גם כשהאפליקציה סגורה, עבודה בלי רשת עם סנכרון אחר כך, ואייקון על המסך שמזכיר למשתמש שהמוצר קיים. המחיר הוא לא רק פיתוח לשתי פלטפורמות — זה גם תהליך: החנויות בודקות כל גרסה, ועדכון מגיע למשתמש רק כשהוא מעדכן. אפל גם מציבה סף תוכן: הנחיות הבדיקה של App Store (סעיף 4.2, "Minimum Functionality") דורשות שאפליקציה תציע יכולות וחוויה שמעבר לאתר ארוז מחדש, ועלולות לדחות אפליקציה שהיא בעיקר תוכן שיווקי או אתר בתוך מעטפת. כלומר: אפליקציה שהיא רק האתר שלכם עם אייקון — לא רק מיותרת, גם עלולה לא להתקבל.
- מתאימה כש: הפעולה חוזרת הרבה; דרושים חיישנים או עבודה ברקע; צריך לעבוד בלי רשת; ההתראות הן חלק מהשירות ולא תזכורת שיווקית.
- המגבלה בהקשר: שתי פלטפורמות לתחזק, מחזור שחרור שעובר דרך החנויות, ומשתמשים על גרסאות ישנות. במוצר שמשתנה כל שבוע זה כבד; במוצר יציב זה סביר.
מה כולל שירות פיתוח אפליקציה אצלנו — המצבים שבהם זה נכון, התוצרים ומה קורה אחרי ההשקה — בעמוד השירות. פיתוח אפליקציות — באילו מצבים זה נכון
מוצר בדפדפן: אתר רספונסיבי או PWA
מוצר בדפדפן הוא גרסה אחת שרצה בכל מכשיר, מתעדכנת בלי לבקש מהמשתמש כלום, ונפתחת מקישור — מהודעה, ממייל, מחיפוש. אין חנות, אין תהליך אישור, אין התקנה. PWA (Progressive Web App) היא אותה גרסה עם תוספות: אפשר להוסיף אותה למסך הבית כאייקון, היא יכולה לעבוד חלקית בלי רשת, ובמערכות ההפעלה העדכניות גם לשלוח התראות — אפל הוסיפה תמיכה ב-Web Push לאפליקציות Web שנוספו למסך הבית ב-iOS וב-iPadOS 16.4 (לפי הודעת צוות WebKit). הגישה לחומרה עדיין נקבעת לפי מה שהדפדפן ומערכת ההפעלה מאפשרים, והיא צרה מזו של אפליקציה מותקנת — בעיקר בעבודה ברקע.
- מתאים כש: השימוש מזדמן או שהמשתמש מגיע מקישור; יש משתמשים חיצוניים שלא יתקינו כלום; המוצר משתנה לעיתים קרובות; צריך לעבוד גם במחשב.
- המגבלה בהקשר: אין נוכחות בחנויות (רלוונטי אם המשתמשים מחפשים שם), ויכולות המכשיר תלויות בדפדפן. אם הפעולה המרכזית היא סריקה רציפה או מיקום ברקע — זה לא המקום.
כשהמוצר בדפדפן הוא מערכת — תפקידים, נתונים ותהליכים ולא רק מסכי תוכן — עמוד השירות של מערכות Web מפרט אילו סוגי מערכות אנחנו בונים ומה כלול. פיתוח מערכות Web ופורטלים
No-Code / Low-Code
כלי No-Code ו-Low-Code מאפשרים להרכיב מוצר עובד — טפסים, טבלאות, תהליכים, לפעמים גם אפליקציה — בלי לכתוב קוד, או עם מעט ממנו. היתרון האמיתי הוא לא רק מהירות ההקמה: זה שמי שמתפעל את המוצר יכול גם לשנות אותו, בלי לפתוח משימה למפתח. לגרסה ראשונה שבודקת האם מישהו בכלל רוצה את המוצר, או לתהליך פנימי עם עשרות משתמשים, זו לעיתים קרובות הבחירה הנכונה — ומי שממליץ על פיתוח מותאם במקום זה, בלי סיבה מדידה, ממליץ על בזבוז.
- מתאים כש: עדיין לא ברור מה המוצר צריך להיות; המשתמשים הם פנימיים ומעטים; מי שיתפעל אינו מפתח; הזמן להשקה חשוב יותר מהגמישות העתידית.
- המגבלה בהקשר: הכלי מגדיר מה אפשר. כל עוד הצורך בתוך הגבול — מצוין; הבעיה היא שהגבול מתגלה בדרך כלל כשכבר יש משתמשים ונתונים. לכן התנאים למעבר (בהמשך) נקבעים ביום הראשון, לא ביום שנתקעים.
מי יתפעל וישנה את המוצר? צוות, ספקים ועלויות שימוש
זו השאלה שמדלגים עליה, והיא קובעת יותר מהטכנולוגיה. מוצר חי צריך מישהו שמוסיף שדה, משנה תהליך, מטפל במשתמש תקוע ומעדכן גרסה. בכל חלופה התשובה שונה:
| אפליקציה | Web / PWA | No-Code | |
|---|---|---|---|
| מי משנה | מפתחים; כל שינוי עובר בנייה ושחרור לחנויות | מפתחים; שינוי עולה לאוויר מיד לכל המשתמשים | המתפעל עצמו, בתוך גבולות הכלי; מעבר להם — מפתח או ספק הכלי |
| מבנה עלות השימוש | חשבונות מפתח בחנויות, שרתים, שירותי צד שלישי — לרוב לא תלוי במספר המשתמשים | אחסון ושירותים — גדל עם העומס, לא עם מספר המושבים | מנוי לפלטפורמה שלרוב נמדד במושבים, ברשומות או בהרצות — גדל עם ההצלחה |
| תלות בספק | בחנויות (כללים, אישור, עמלות) ובצוות הפיתוח | בצוות הפיתוח; הקוד והנתונים שלכם | בפלטפורמה: אם היא משנה מחיר, יכולת או תנאי ייצוא — זה משפיע עליכם ישירות |
| השאלה לשאול לפני | מי מחזיק את חשבונות המפתח, ומי מפרסם גרסאות אחרי שהפרויקט נגמר? | מי מחזיק את הדומיין, את האחסון ואת קוד המקור? | איך מייצאים את כל הנתונים, באיזה פורמט, והאם הלוגיקה ניתנת לשחזור מחוץ לכלי? |
מתי עוברים לפיתוח מותאם? אילוצים מדידים ומסירת נתונים
מעבר מ-No-Code (או מאתר פשוט) לפיתוח מותאם הוא לא כישלון — זה השלב הבא, אם תכננו אותו. הבעיה היא כשהמעבר קורה בלחץ, כי הכלי נתקע ביום שהלקוח הגדול חתם. לכן מגדירים מראש שלושה-ארבעה תנאי יציאה מדידים, ובודקים אותם מדי רבעון:
- עלות שימוש: המנוי לפלטפורמה חצה סכום שהגדרתם — או את העלות השנתית המשוערת של פיתוח ותחזוקה של אותו דבר. (מספר שלכם, לא שלנו.)
- ביצועים: פעולה מרכזית חורגת מזמן תגובה שהגדרתם, או שהכלי מגביל נפח רשומות / קריאות שאתם מתקרבים אליו.
- יכולת: נדרשת פעולה שהכלי לא תומך בה — חישוב, חיבור למערכת, הרשאה — והפתרון העוקף מורכב יותר מהבעיה.
- דרישות של לקוחות: לקוח עסקי דורש התחייבות לזמינות, אבטחת מידע או מיקום נתונים שהפלטפורמה לא נותנת בכתב.
התנאי שמחליט אם המעבר יהיה פרויקט מסודר או חילוץ הוא מסירת הנתונים. לפני שבוחרים כלי, מוודאים: שאפשר לייצא את כל הנתונים (לא רק את הטבלה הראשית) בפורמט פתוח; שהקשרים בין רשומות נשמרים בייצוא; שהלוגיקה — תהליכים, חישובים, הרשאות — מתועדת במקום שלא תלוי בכלי. אם אחת מהשלוש לא מתקיימת, המעבר העתידי יהיה יקר יותר מכל מה שנחסך.
מצב קרוב, ושונה: מוצר שנבנה מהר בקוד שנוצר בעזרת AI ועכשיו צריך להפוך למערכת ייצור. ההבדל בין השניים, ומה בודקים במעבר — בהשוואה נפרדת. Vibe coding מול הנדסת ייצור — מה בודקים במעבר
מפת החלטה — כלי עזר לא מחייב
המפה הבאה מסכמת את המדריך לכדי סדר שאלות. היא מניחה שתי הנחות שצריך לבדוק קודם: שהתשובות על הפעולה, התדירות והמכשיר ידועות (ולא מנוחשות), ושיש מישהו שיתפעל את המוצר אחרי ההשקה. אם אחת ההנחות לא מתקיימת — זו השאלה הראשונה, לא המפה.
- הפעולה המרכזית דורשת חיישנים, עבודה ברקע או עבודה בלי רשת? כן → אפליקציה (ואז בוחרים טכנולוגיה). לא → המשך.
- עדיין לא ברור מה המוצר צריך להיות, או שהמשתמשים פנימיים ומעטים, ומי שיתפעל אינו מפתח? כן → No-Code לגרסה ראשונה, עם תנאי יציאה ובדיקת ייצוא נתונים לפני שמתחילים. לא → המשך.
- המשתמשים חיצוניים, מגיעים מקישור, או שהמוצר צריך לעבוד גם במחשב? כן → מוצר בדפדפן; אם חשוב אייקון במסך הבית או התראות — PWA.
- הפעולה חוזרת כמה פעמים ביום ואין מגבלת חומרה? → שתי החלופות אפשריות; המכריע הוא מי משנה את המוצר ובאיזה קצב. שינוי שבועי מטה לדפדפן.
- יש שני סוגי משתמשים עם תשובות שונות? → שני ממשקים על אותו Backend, לא פשרה אחת שלא מתאימה לאף אחד.
מה אנחנו עושים בשלב הזה
בפגישה ראשונה אנחנו עוברים איתכם על שלושת המשתנים — פעולה, תדירות, מכשיר — ועל מי יתפעל את המוצר, ומגיעים להמלצה על סוג המוצר לפני שמדברים על פיתוח. לפעמים ההמלצה היא No-Code לגרסה ראשונה, ואז ההצעה שלנו היא הגדרת תנאי היציאה ובדיקת הייצוא, לא פיתוח. כשההמלצה היא גרסה ראשונה בקוד — ה-MVP — כך אנחנו מגדירים ובונים אותו. פיתוח MVP — איך מגדירים ובונים גרסה ראשונה
ואם כבר ברור שהמוצר הוא גרסה ראשונה בקוד, השאלה הבאה היא מה נכנס אליה ומה לא — מדריך נפרד להיקף של MVP. איך מגדירים היקף ל-MVP