איך בונים מוצר SaaS מאפס: מדריך ליזמים ולעסקים

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

כמה מונחים שיחזרו כאן, בקצרה:

• SaaS (Software as a Service) - תוכנה כשירות. הלקוח לא מתקין ולא קונה רישיון, אלא משלם מנוי ומשתמש דרך הדפדפן. אתם מחזיקים מערכת אחת שמשרתת את כולם.
• ריבוי דיירים (multi-tenancy) - עותק אחד של המערכת משרת הרבה לקוחות, שנקראים דיירים, וכל אחד רואה רק את הנתונים שלו.
• MVP (Minimum Viable Product) - גרסה ראשונה מינימלית שכבר פותרת בעיה אמיתית ואפשר לגבות עליה תשלום.
• אימות (authentication) והרשאות (authorization) - מי אתם, ומה מותר לכם לעשות במערכת.
• אונבורדינג (onboarding) - הדקות הראשונות של משתמש חדש, מהרשמה ועד לפעולה הראשונה שנותנת לו ערך.
• חיוב חוזר (recurring billing) - גביית המנוי באופן אוטומטי כל חודש או שנה, כולל הפקת המסמך החשבונאי.

לפני שורת קוד: לוודא שיש בעיה שמשלמים עליה

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

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

מה נחשב אימות ומה לא

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

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

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

היקף הגרסה הראשונה

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

כך זה נראה כשמחלקים בין הגרסה הראשונה למה שאחריה:

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

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

ארכיטקטורה: ריבוי דיירים, אימות והרשאות

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

ריבוי דיירים (multi-tenancy)

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

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

אימות והרשאות

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

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

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

מנויים, מדרגות חבילה וחיוב בישראל

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

לפי מה מדרגים

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

חיוב בישראל

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

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

פאנל ניהול, אונבורדינג ואנליטיקה

שלושה חלקים שכמעט אף יזם לא מתלהב מהם, ושכל SaaS שעובד תלוי בהם.

פאנל ניהול למפעיל

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

אונבורדינג

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

אנליטיקה

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

אבטחה, אחסון ועלויות

אבטחה שאי אפשר לדחות

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

אחסון

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

כמה זה עולה

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

מתי לא לבנות SaaS

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

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

מה קורה אחרי ההשקה

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

שלושת החודשים הראשונים

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

איך מחליטים מה לבנות אחר כך

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

ממשק תכנות ואינטגרציות

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

שורה תחתונה

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

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