כמה עולה לפתח אפליקציה — ולמה אף אחד לא יכול לענות בלי לשאול

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

למה אי אפשר לתת מספר?

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

מה מייקר בפועל?

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

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

איך קוראים הצעת מחיר?

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

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

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

מה כן אפשר לעשות כדי להוזיל?

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

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