בניית אפליקציה עם AI: השיטה שלי ב-7 שלבים

בקצרה: בונים אפליקציה עם AI לפי סדר: קודם מבינים מה בונים ולמי, אחר כך בונים גרסה קטנה (MVP), בודקים אותה, ורק אז מרחיבים ומלטשים. זו השיטה שלי ב-7 שלבים, עם פרומפטים להעתקה ל-Claude Code או ל-Codex.

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

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

שבעת השלבים בקצרה

1. תכנון: מגדירים למי האפליקציה מיועדת ומה היא צריכה לעשות.
2. MVP: בוחרים את הגרסה הקטנה שאפשר לתת לאנשים לנסות.
3. טכנולוגיה: בוחרים כלים שמתאימים לפלטפורמות שרוצים להגיע אליהן.
4. בנייה: מחברים את הפעולה המרכזית מההתחלה ועד הסוף.
5. מסך-מסך: מתקנים כל חלק בנפרד ושומרים התקדמות.
6. בדיקות: מריצים תרחישים של משתמש אמיתי.
7. עיצוב: מלטשים את המראה ובודקים שהכל עדיין עובד.

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

את הסיפור מאחורי המוצרים אפשר לקרוא בפרויקטים של בולמילה, Pooper ו-Royal Passover.

שלב 1: קודם תוכנית, אחר כך קוד

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

איך מפעילים Plan Mode

• ב-Claude Code בטרמינל: לוחצים Shift+Tab עד שבשורת המצב מופיע plan mode on. אפשר גם לפתוח סשן עם הפקודה claude --permission-mode plan. במצב הזה הכלי בודק ומציע תוכנית לפני עריכת הקוד. ההוראות של Claude Code (נפתח בלשונית חדשה).
• ב-Codex: בתחילת השיחה מקלידים /plan ושולחים. אפשר לצרף את בקשת התכנון באותה הודעה. בזמן שהכלי כבר עובד הפקודה עשויה לא להיות זמינה. ההוראות של Codex (נפתח בלשונית חדשה).

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

אני רוצה לבנות אפליקציה ל[מה היא עושה].
המשתמש הוא [מי].
הוא צריך לעשות: [הפעולות העיקריות].
מה אני מצפה שיקרה: [התוצאה הרצויה].
מה חייב לעבוד מקצה לקצה בגרסה הראשונה: [הזרימה המרכזית].

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

שלב 2: מצמצמים לגרסה שאפשר לבדוק

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

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

מה ההבדל בין MVP ל-POC?

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

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

שלב 3: בוחרים טכנולוגיה שמתאימה למוצר

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

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

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

איך רואים את האפליקציה על המכשיר?

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

npx expo start

• Android: פותחים את Expo Go ובוחרים Scan QR code, ואז סורקים את הקוד שמופיע בטרמינל.
• iPhone: סורקים את הקוד במצלמה. לפי התיעוד הנוכחי, ב-Expo Go במכשיר iOS צריך להתחבר לאותו חשבון Expo גם באפליקציה וגם ב-Expo CLI.
• דפדפן: לוחצים W בטרמינל כדי לפתוח את גרסת הווב.

אלה הוראות לדוגמת ההתחלה של Expo. לפרויקט עם יכולות native נוספות ייתכן שיידרש development build. את ההקמה המלאה מוצאים במדריך הפתיחה של Expo (נפתח בלשונית חדשה).

שלב 4: בונים זרימה אחת שעובדת

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

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

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

מגדירים תוצאה שאפשר לבדוק

במקום רק ״תבנה מסך משימות״, מגדירים מה המשתמש יוכל לעשות בסוף. ב-Codex אפשר להשתמש גם ב-/goal כדי להגדיר יעד מתמשך. היעד צריך להיות ברור, למשל: ״משתמש יכול ליצור משימה, לסמן אותה ולמצוא אותה אחרי פתיחה מחדש״. הסבר על פקודות ויעדים (נפתח בלשונית חדשה).

שלב 5: עוברים מסך-מסך

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

עכשיו רק מסך [שם].
כשמשתמש לוחץ על [X], אני מצפה שיקרה [Y]. כרגע קורה [Z].
שלבי השחזור הם: [מה עושים כדי לראות את הבעיה].
תתקן את הבעיה ותבדוק שההתנהגות הרצויה עובדת. אל תשנה מסכים אחרים בלי להסביר למה זה נדרש.

שומרים נקודת חזרה אחרי שינוי שעובד

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

תעשה commit לשינויים של המסך שבדקנו, עם הודעה שמתארת מה עובד עכשיו.
אל תכלול שינויים לא קשורים. תסכם מה נכנס ל-commit.

שלב 6: בודקים כמו משתמש אמיתי

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

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

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

אילו כלים יכולים לעזור?

• לאתר: Playwright (נפתח בלשונית חדשה) מאפשר לבדוק תרחישים בדפדפנים, כולל לחיצות, מילוי טפסים ומעבר בין מסכים.
• למובייל: Maestro (נפתח בלשונית חדשה) מאפשר לבדוק זרימות באפליקציה; ב-iOS אפשר להריץ אותן בסימולטור של Xcode.

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

שלב 7: מלטשים את העיצוב

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

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

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

בונוס: בדיקה לפני שעולים לאוויר

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

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

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

רוצים להעמיק? קלוד קוד למתחילים, Codex מול Claude Code , מה זה וייב קודינג ולחבר אפליקציה של Lovable לוואטסאפ. ואם אתם רוצים לבנות את האפליקציה יחד איתי: פיתוח אפליקציות AI לעסקים.