איך לבחור Tech Stack ל-SaaS הראשון שלכם: מדריך כן ליזמים

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

עזרתי למספר לא מבוטל של יזמים בפעם הראשונה לעבור ממצגת למוצר שאנשים אמיתיים משלמים עליו. כמעט אף אחד מהם לא היה טכני. כמעט כולם הגיעו אחרי שכבר ספגו כמות מפחידה של פולקלור על stacks — שהם חייבים microservices, שאיזה framework מסוים "מת", שבחירה שגויה תחרוץ את גורלם. וכמעט בכל פעם, ה-stack התברר כאחת ההחלטות הכי פחות משמעותיות שקיבלו באותה שנה. מה שהרג פרויקטים היה ה-scope, אחריות לא ברורה, ובניית הדבר הלא נכון בצורה יפהפייה. אף פעם לא ה-framework.

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

למה ההחלטה הזו מרגישה קשה יותר ממה שהיא

שאלת ה-stack מרגישה עצומה כי זו הבחירה הראשונה שנשמעת בלתי הפיכה, והיא עטופה בשפה שאתם לא דוברים. מילים כמו Postgres, React, Kubernetes, serverless נזרקות כאילו הבחירה ביניהן דומה לבחירת היסודות של בניין — תטעו והכול קורס.

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

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

מה זה באמת "stack", במילים פשוטות

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

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

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

הדברים שבאמת חשובים (והדברים שלא)

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

מה באמת חשוב

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

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

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

מה חשוב הרבה פחות ממה שאומרים

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

איזה framework ספציפי "מנצח" השנה. frameworks עולים ויורדים במחזור אופנה שכמעט אין לו קשר לשאלה אם הם יבנו את ה-SaaS לחיוב שלכם היטב. כל אחת מהאפשרויות המרכזיות ונפוצות תעשה את העבודה. הטרנד הוא רעש; בחרו מהאמצע המשעמם והפופולרי והמשיכו הלאה.

למה טכנולוגיה "משעממת" בדרך כלל מנצחת

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

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

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

שיטת החלטה שבאמת תוכלו להשתמש בה

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

1. 1
   התחילו מהצוות, לא מהטכנולוגיה

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

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

   העדיפו את הבחירה שהופכת את עריכת המוצר שלכם לזולה ומהירה. תטעו לגבי המוצר שוב ושוב — תפקיד ה-stack הוא להפוך את הטעות לכזו ששורדים.
4. 4
   שמרו על הארכיטקטורה פשוטה ככל האפשר

   מסד נתונים אחד. backend אחד. frontend אחד. בלי microservices, בלי שום דבר מבוזר וחכם, עד שבעיה אמיתית ונמדדת תכפה זאת עליכם. הפשטות היא המטרה, לא הפשרה.
5. 5
   רשמו למה בחרתם בזה

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

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

שאלות לשאול את מי שמציע stack

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

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

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

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

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

רדיפה אחרי הדבר החדש ביותר. framework מבריק ששוחרר בחודש שעבר אין לו רקורד, יש לו תיעוד דליל וקהילה זעירה. תבזבזו את הלילות שלכם על debugging של הכלי במקום על בניית המוצר. תנו לאחרים להיות ה-early adopters; לכם יש עסק לשחרר.

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

מתי באמת הזמן לבחון מחדש את ה-stack שלכם

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

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

שאלות נפוצות