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

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

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

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

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

‍

פיתוח Web App - הדרך ״הרגילה״

כדי לפתח Web app בשיטה קונבנציונלית, אנו זקוקים לתשומות הבאות:

• מפרט לפיתוח - PRD
• עיצוב מלא של ממשק המשתמש (Figma, XD)
• פיתוח צד שרת
• פיתוח פרונט אנד (בדרך כלל בכלי כמו Angular)
• בקרת איכות
• העלאה לשרתים, DevOps

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

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

לפי מתודת Lean startup, הדרך להתאים את המוצר לשוק הינה מעגל היזון חוזר. מביאים את הMVP בפני משתמשים, אוספים נתונים, מבצעים שינויים וחוזר חלילה - Build, Measure, Learn. כדי לעשות זאת במוצר קונבנציונלי נדרש לנו מפתח יחיד (נדיר) או צוות קטן (בדרך כלל), ששולט ברמת יכולת לבצע שינויים בכל מרכיבי המוצר.

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

‍

פיתוח Web ללא קוד - הדרך החדשה

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

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

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

‍

WebFlow + שרת = אפליקציית ווב!

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

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

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

לאחר מספר חודשי פיתוח ותוך שימוש בכמה מיכולותיה העדכניות של הפלטפורמה, הגענו למצב בו ביכולתנו להקים עבור אתר Webflow שרתי Node.js/MongoDB שאינם שונים משרתי כל אפליקציה אחרת, כולל ניהול משתמשים, דפי אדמין, לוגיקת צד שרת, התממשקות לAPIs וכו׳. 

וכעת רשימת התשומות שלנו תיראה כך:

• מפרט לצד שרת - תיאור API
• עיצוב מלא של ממשק המשתמש ישירות בWebFlow
• פיתוח צד שרת, הטמעה בWebFlow
• בקרת איכות
• העלאה לשרתים, DevOps

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

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

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

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

‍

לסיכום - הדרך המהירה לנתונים

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