בחלק הזה
בקצרה
- מה זה סביבה שבה מתארים במילים אפליקציה פנימית — והיא נבנית, מחוברת לנתונים שכבר קיימים אצלך במאנדיי.
- מה נדרש תוכנית שפותחת את היכולת. ב-Trial אפשר לבנות אבל לא לפרסם; פרסום דורש Vibe app package נפרד.
- מה זה עולה בשימוש קרדיטים נשרפים גם בשלב הבנייה וגם בכל ריצה של האפליקציה.
- הבלבול הנפוץ Vibe Design System היא ספריית רכיבי ממשק למפתחים — לא אותו מוצר, ולא קשורה לבניית אפליקציות בלי קוד.
סטודיו עיצוב קטן בגבעתיים, שבעה עובדים, מנהל את כל הפרויקטים במאנדיי — חוץ מדבר אחד. תהליך אישור הסקיצות מול הלקוח יושב בגיליון Google Sheets נפרד, כי אף לוח לא נותן למעצבים את המסך שהם צריכים: תצוגה אחת, גדולה, של הסקיצה הנוכחית, שלושה כפתורים, ובלי כל שאר העמודות. זה בדיוק סוג הפער ש-monday vibe נועד לסגור — לא עוד לוח, אלא מסך ייעודי שנבנה לפי תיאור במילים.
כשהלוח כמעט מתאים אבל לא: הפער שנשאר בגיליון
כמעט בכל עסק שעובד רציני עם מאנדיי יש תהליך אחד עיקש שברח החוצה. אצל אחד זה טופס קליטת עובד חדש; אצל השני מסך שהמנהל פותח כל בוקר ורוצה לראות בו שלושה מספרים בלבד; אצל השלישי כלי פנימי שמישהו בצוות שירות משתמש בו עשרים פעם ביום ורוצה שיהיה בו כפתור אחד גדול במקום שבע עמודות.
הלוח (Board) הוא יחידת-הבסיס של מאנדיי, והוא מצוין בדיוק במה שהוא נועד לו — לנהל אוסף פריטים עם עמודות. אם עוד לא ברור לך איך לוח בנוי, מה זה קבוצה ומה זה פריט, קרא קודם את העמוד לוחות (Boards) ב-monday — יחידת-הבסיס של הכול ורק אז חזור לכאן. העמוד הזה מניח שאתה כבר יודע לעבוד עם לוח, ומדבר על מה שקורה כשלוח כבר לא מספיק.
הפער נוצר כשמה שאתה צריך אינו טבלה אלא ממשק — מסך עם היגיון משלו, כפתורים משלו, ותצוגה שמסתירה 90% מהנתונים ומראה רק את מה שרלוונטי לרגע. בעבר זה היה אומר מפתח, פרויקט, ותקציב. היום זה מה ש-vibe מנסה לתת.
מה קורה בפועל כשמתארים אפליקציה במילים
המנגנון פשוט להסבר וקשה יותר לביצוע טוב. אתה כותב בשדה תיאור מה אתה רוצה שהכלי יעשה — בעברית או באנגלית — ומחבר אליו את הנתונים שכבר קיימים אצלך: לוח, קבוצה, עמודות מסוימות. המערכת בונה מזה אפליקציה עם מסכים, ומאותו רגע אתה ממשיך לשוחח איתה: "תוסיף כפתור אישור", "תוריד את העמודה הזאת מהתצוגה", "תעשה שהמסך הראשי יציג רק פריטים של השבוע". אין שורת קוד אחת בדרך.
חשוב להבין מה נבנה בסוף: לא לוח נוסף, ולא אוטומציה. מה שיוצא הוא אפליקציה — מוצר עם מסכים משלו, שיושב בתוך סביבת מאנדיי שלך וקורא מהנתונים הקיימים. אפשר גם לבקש שהיא תפעיל AI בתוכה, למשל שתסכם טקסט שהמשתמש מכניס או שתחפש מידע ברשת. כל קריאה כזאת רצה על אותה מכסת קרדיטים של החשבון.
שני דברים עם אותו שם: vibe מול Vibe Design System
זו נקודת הבלבול הגדולה, ועדיף לפתור אותה לפני שמחפשים בגוגל ומגיעים לתיעוד הלא נכון. מאנדיי מחזיקה שני דברים שונים לחלוטין שנקראים דומה. אחד מהם הוא הכלי שהעמוד הזה עוסק בו. השני, Vibe Design System, הוא ספריית רכיבי ממשק (UI) — אוסף של כפתורים, שדות, טבלאות ותפריטים מוכנים, שמפתחת תוכנה מייבאת לתוך קוד שהיא כותבת בעצמה כדי שהמוצר שלה ייראה בשפה העיצובית של מאנדיי.
| monday vibe | Vibe Design System | |
|---|---|---|
| מה זה | סביבה לבניית אפליקציה עסקית מתיאור במילים | ספריית רכיבי ממשק (UI) מוכנים |
| למי זה מיועד | בעל עסק או איש צוות שלא כותב קוד | מפתחות ומפתחי תוכנה שכותבים קוד |
| מה יוצא בסוף | אפליקציה שרצה בסביבת מאנדיי שלך | מראה אחיד לממשק שכבר בונים בקוד |
| איפה זה גר | בתוך החשבון שלך במאנדיי | בפרויקט הפיתוח של המתכנת |
המבחן המעשי: אם המילה "להתקין ספרייה" לא אומרת לך כלום — Vibe Design System אינו הכלי שלך, ואפשר לשכוח ממנו. אם מישהו בצוות שלך מפתח, ייתכן שהוא דווקא כן ישמע עליו — אבל זה שיח אחר לגמרי, ולא זה שהעמוד הזה מטפל בו.
מה נדרש כדי שזה יגיע לצוות: בונים בחינם, מפרסמים בתשלום
כאן צריך לדייק, כי ההבדל בין "בניתי" לבין "הצוות שלי משתמש" הוא ההבדל שקובע אם הכלי הזה רלוונטי לך. הכלי אינו נפתח בכל תוכנית. בתקופת Trial אפשר לבנות — לתאר, לראות תוצאה, לתקן — אבל לא לפרסם. פרסום האפליקציה, כלומר הפיכתה לזמינה לשימוש אמיתי, דורש Vibe app package נפרד.
- לבנות ולהתנסות — אפשרי גם ב-Trial. תיאור, תיקונים, בדיקה של מה יצא.
- לפרסם לשימוש — דורש Vibe app package נפרד, בנוסף לתוכנית שפותחת את היכולת.
- קרדיטים — נצרכים גם בשלב הבנייה וגם בכל ריצה של האפליקציה.
המשמעות התכנונית: אפשר ורצוי לבדוק את הכלי לפני שמתחייבים, אבל אל תבנה תוכנית עבודה שמניחה שהאפליקציה תרוץ אצל הצוות כבר בשבוע הבא בלי לוודא קודם מה החשבון שלך צריך. הרבה עסקים מגלים את התנאי הזה אחרי שכבר השקיעו שעתיים בבנייה ונפלו בהם בפעם הראשונה שניסו לשתף.
איפה מתחילים בפועל: הכתובת הייעודית ו-Template Center
יש שני מסלולי כניסה, והם משרתים שני מצבי-ראש שונים. הראשון הוא הכתובת הייעודית monday.com/vibe — נכנסים, בוחרים את החשבון הנכון (חשוב במיוחד אם אתה חבר גם בחשבון של לקוח או של שותף), וכותבים מה רוצים. זה המסלול למי שכבר יודע מה הוא צריך.
המסלול השני הוא Template Center — מרכז התבניות של מאנדיי, שבתוכו יש קטגוריה של vibe. שם רואים אפליקציות בנויות ולומדים מהן. זה המסלול הנכון למי שעדיין לא בטוח מה בכלל אפשר לבנות: קל בהרבה להסתכל על משהו קיים ולהגיד "כזה, רק שיציג לי לקוחות" מאשר לתאר מאפס מול שדה ריק.
- בוחרים נקודת כניסה הכתובת הייעודית אם אתה יודע מה אתה בונה, Template Center אם אתה עוד סוקר אפשרויות.
- מוודאים חשבון אם אתה חבר ביותר מחשבון אחד — ודא שאתה בחשבון של העסק שלך ולא בחשבון של לקוח.
- מתארים במילים משפט אחד ברור עדיף על פסקה מעורפלת: מי המשתמש, מה הוא רואה, מה הוא לוחץ.
- מחברים נתונים מפנים את האפליקציה ללוח או לעמודות שכבר קיימים אצלך — לא מזינים נתונים מחדש.
- מתקנים בשיחה מריצים, רואים מה לא מדויק, מבקשים שינוי. זה תהליך של כמה סבבים, לא של לחיצה אחת.
- מפרסמים רק כאן נכנס תנאי החבילה בתשלום — לפני השלב הזה הכול עדיין טיוטה.
דוגמה מלאה: מסך אישור סקיצות לסטודיו בגבעתיים
נחזור לסטודיו מהפתיחה. הלוח קיים כבר שנתיים: כל שורה היא סקיצה, ובה עמודת סטטוס, עמודת לקוח, תאריך יעד, קובץ מצורף, ועוד שש עמודות שנצברו עם השנים. הבעיה אינה הלוח — הבעיה היא שהמעצב, כשהוא סוגר סקיצה בסוף היום, לא צריך לראות עשר עמודות. הוא צריך לראות סקיצה אחת ולסמן: אושר, נדחה, או ממתין ללקוח.
שים לב למה שלא קרה כאן: לא נבנה לוח חדש, לא הוקמה מערכת מקבילה, ולא נוצר מקום שני שבו הנתונים חיים. זה הכלל החשוב ביותר בעבודה עם vibe — האפליקציה היא שכבת תצוגה ופעולה מעל הנתונים שכבר קיימים, ולא בסיס נתונים נוסף. ברגע שאתה מוצא את עצמך מתאר אפליקציה ש"תשמור אצלה" מידע שאין לו מקום בלוח, עצור וחשוב מחדש.
הערה על התהליך עצמו, מהשטח: לא סביר שהתוצאה הראשונה תהיה מדויקת. התיאור הראשון מייצר משהו סביר, ואז מתחילים לתקן. מי שמצפה שהמשפט הראשון ייתן מוצר מוגמר יתאכזב; מי שמתייחס לזה כאל שיחה עם עוזר שמבין מהר אבל לא קורא מחשבות — יגיע לתוצאה טובה בהרבה.
הגבול המקצועי: מתי לוח רגיל פשוט עדיף
הפיתוי לבנות אפליקציה לכל דבר גדול, והוא טעות. ברוב המקרים בעסק של שניים עד שלושים עובדים, לוח מוגדר טוב עם תצוגה מסוננת פותר את הבעיה בעשירית מהמאמץ, בלי לצרוך קרדיטים בכל ריצה, ובלי ליצור עוד רכיב שמישהו יצטרך לתחזק כשהעובד שבנה אותו יעזוב.
שורה תחתונה: מה זה אומר על העסק שלך
אם העסק שלך עדיין בונה את הלוחות הראשונים שלו במאנדיי — הכלי הזה לא בשבילך היום. הוא נועד לרגע שבו הפלטפורמה כבר מכילה את רוב העבודה, והפער היחיד שנשאר הוא ממשק. אם לעומת זאת יש אצלך גיליון עיקש אחד שסירב להיכנס פנימה כבר שנה — יש עכשיו מסלול לסגור אותו בלי לגייס מפתח.
מבחינת החלטה כספית, שני הדברים שצריך לבדוק לפני שמתחייבים הם אלה: האם החשבון שלך מאפשר לפרסם, ומה ההיקף הצפוי של הרצות — כי קרדיטים נצרכים גם כשבונים וגם בכל פעם שהאפליקציה רצה. שני הנתונים האלה נמצאים בעמוד התוכניות הרשמי ובמסך הצריכה של החשבון, ושם צריך לבדוק אותם — לא בהערכה.
מקורות
- Get started with monday vibe — מרכז העזרה הרשמי של monday.com
- AI Credits — מרכז העזרה הרשמי של monday.com
- The pricing model for monday AI portfolio — מרכז העזרה הרשמי
- The basics of a board — מרכז העזרה הרשמי
נכון ל-29/08/2026.