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

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

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

איך אתם מגלים שיש לכם שני מוצרים

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

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

תדעו שחציתם את הקו הזה כשאחד מאלה מתחיל להיות נכון:

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

אם אתם רואים שניים או יותר מאלה, אין לכם בעיית פיצ’ר. יש לכם פיצול מוצר שמחכה לקרות.

שלוש הצורות של פיצול

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

צורה 1: אפליקציה אחת, שתי דלתות

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

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

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

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

צורה 2: שתי אפליקציות, backend אחד

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

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

הצורה הזו היא התשובה הנכונה כש:

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

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

צורה 3: שתי אפליקציות, שני backends

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

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

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

מה לעשות לפני שאתם מפצלים משהו

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

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

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

שלישית, החליטו מה זהה מתחת. אותם משתמשים? אותם נתונים? אותם תשלומים? כל “כן” מושך אתכם לכיוון צורה 1 או 2. כל “לא” מושך אתכם לכיוון צורה 3. אין תשובה נכונה — רק התשובה שמתאימה לאיך שהמוצר שלכם באמת עובד.

מה משתנה אחרי הפיצול

שני דברים נעשים קלים יותר ודבר אחד נעשה קשה יותר.

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

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

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

שאלה קטנה לסיום

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

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

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