אני בונה עם יזמים ועסקים את הגרסה הראשונה שעולה לאוויר: מה חייב להיכנס פנימה, מה לדחות, ואיך להגיע לשוק בלי בית תוכנה ובלי בזבוז תקציב.
מי אני
אני רון סטולרו. מעל 10 שנים אני מפתח ומלווה מוצרים טכנולוגיים: מוצר ראשון ליזמים, מערכות פנימיות לעסקים שגדלו מאקסל וואטסאפ, וליווי טכנולוגי כשצריך חשיבה של CTO בלי לגייס משרה מלאה.
העבודה שלי מתחילה לפני הקוד. קודם ממפים את הבעיה, את המשתמשים ואת ההנחה שצריך לבדוק. אחר כך בונים מסכים וזרימות שאפשר לראות, ורק אז נכנסים לפיתוח ממוקד. כך נמנעים מפיצ׳רים מוקדמים מדי ומתקציב שנשרף על דברים שאפשר היה לדחות.
אני עובד בעברית ועם יזמים ועסקים בישראל, בלי שכבת ניהול שמפרידה ביניכם לבין מי שבונה. אם צריך להגיד לא לפיצ׳ר, או לעצור שבוע כדי לחדד משתמש, זה חלק מהתפקיד. השקט מגיע מהחלטות, לא ממצגת.
השיחה הראשונה בודקת אם בכלל צריך פיתוח, או אם מספיק חיבור בין כלים שכבר רצים. יוצאים עם כיוון לגרסה הראשונה: משתמש אחד, פעולה אחת, ומדד שאפשר לבדוק מול שוק אמיתי.
אני גר בישראל ועובד לפי שעון מקומי. שיחות, מסכים והערות מגיעים באותו יום עבודה, בלי פער של אזור זמן ובלי תרגום של הדרישה דרך מנהל פרויקט. כשצריך להראות זרימה או לתקן ניסוח בעברית, זה קורה ישירות מולי.
אני מלווה גם מייסדים לפני גיוס ראשון וגם בעלי חברה שכבר מוכרים. לפעמים העבודה היא אפיון בלבד, לפעמים ליווי שבועי עד שיש גרסה יציבה. אני לא מוכר חבילת שעות גנרית, ולא סוגר חוזה לפני שמבינים איפה הסיכון האמיתי.
לאורך הדרך שימשתי בשלושה תפקידי CTO, והעליתי לאוויר יותר מ־20 מוצרים. העבודה כללה איפיון, בחירת טכנולוגיה, בניית צוותים קטנים, עלייה לאוויר, וליווי אחרי ההשקה לפי שימוש אמיתי.
למדתי שמוצר טוב לא מתחיל ברשימת פיצ׳רים. הוא מתחיל בהחלטה מה לבנות קודם, מה לא לבנות, ואיך לבדוק את השוק בגרסה שאפשר לגעת בה. אותו עיקרון תקף גם למערכת עסקית: מתחילים מהעבודה בשטח, לא מהכלי שמוכרים.
הניסיון הזה כולל גם מוצרים שנעצרו בזמן. חלק מהערך הוא לדעת מתי POC מספיק, מתי גרסה ראשונה חייבת לעלות לאוויר, ומתי העסק צריך סדר לפני קוד. אין לי עניין למכור חודשים של פיתוח לבעיה שאפשר לסגור בחיבור בין כלים קיימים.
אחרי ההשקה אני נשאר קרוב לשימוש: מה הצוות באמת עושה במסך, איפה חוזרים לאקסל, ואיזו החלטה הבאה באמת מזיזה מדד. ככה ממשיכים לפתח בלי לנפח את המוצר סתם.
הניסיון כולל גם כלים פנימיים לצוותים קטנים וגם מוצרים שפנו ללקוחות קצה. המשותף הוא מסך שאפשר לגעת בו, מדד שאפשר למדוד, והחלטה מפורשת מה לא נכנס לגרסה הראשונה.
בין היתר ליוויתי כלים לתור פניות, לניהול הזמנות ומלאי, ולמוצרים שבודקים אם לקוח מוכן לשלם על התוצאה. בלי שמות לקוח כאן: הסיפור הוא התהליך, לא רשימת לוגו. כשיהיו שמות שאפשר לפרסם, הם ייכנסו לכאן במפורש.
עבדתי עם צוותי מכירות, תפעול ומשמרות, ועם גבייה בכרטיס או בהעברה. ראיתי איפה הרשאות נשברות, איפה דוחות משקרים, ואיפה אוטומציה רק מעתיקה טעות. הידע הזה חוסך ניסוי וטעייה יקרים בגרסה הראשונה.
איך אני עובד
יזמים ועסקים מקבלים איש קשר אחד מהרעיון עד העלייה לאוויר. אין פיצול בין איפיון, ניהול ופיתוח. יש שיחת היכרות קצרה, מפת החלטות, מסכים לאורך הדרך, ומוצר או מערכת שאפשר להמשיך לפתח.
אם הפתרון הנכון הוא POC קטן, אוטומציה או חיבור בין כלים קיימים — אגיד את זה. המטרה היא להתקדם, לא למכור פרויקט גדול יותר ממה שצריך.
שיחת היכרות נמשכת כ־30 דקות, בלי התחייבות. אפשר לקבוע אותה מדף הבית. יוצאים עם כיוון: מה בונים, מה דוחים, ומה הצעד הבא. אם עדיין مبולבלים, עדיף לקרוא קודם ואז לדבר — לא להיכנס לפיתוח מתוך לחץ.
אני לא מחליף מחלקת פיתוח גדולה ולא בית תוכנה עם שכבות ניהול. אני מתאים כשצריך אדם אחד שמוביל מוצר וטכנולוגיה עד שיש בסיס חי, ואחר כך אפשר להחליט אם לגייס צוות או להמשיך ממוקד.
אם אתם מחפשים רק ידיים נוספות בלי החלטות על תכולה, זה לא אני. אם אתם רוצים שותף שאומר מה לא לבנות, ומראה מסכים לפני שהקוד מתארך — זה בדיוק המקום לפתוח שיחה קצרה כבר עכשיו.
לא מתאים אם כבר יש מחלקת פיתוח שמחפשת רק עוד מתכנת, או אם צריך עשרות אנשים ומכרז ארוך. מתאים ליזם עם רעיון שצריך גרסה שאפשר להראות, או לעסק שתקוע בין קבצים ורוצה מערכת אחת במקום עוד מנוי.
בסוף העבודה אתם מקבלים גישה לקוד, לסביבות ולמסמך ההחלטות. אין נעילה על כלי פנימי שלי. אם תבחרו להמשיך עם צוות אחר, תוכלו לקחת את הבסיס בלי לפתוח פרויקט מאפס. זה חלק מההסכם, לא טובה בסוף.
התמחור נגזר מהיקף, מהחיבורים ומהסיכון לעצירת פעילות — לא ממחירון קטלוגי. אחרי המיפוי אפשר לתת טווח כנה לשלב הראשון. התשלום והלו״ז נכתבים בהסכם לפני שמתחילים, כולל מה קורה אם התכולה זזה באמצע.
