אפיון אפליקציה: תבנית של עמוד אחד

אפיון אפליקציה: התשובה הקצרה

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

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

אני מפרסם אפליקציות iOS משלי. Solys, שעון מעורר עם מיני-משחקים, ו-TradaZen, סימולטור מסחר, נמצאות ב-App Store. Nolera ו-Clic נדחו על ידי Apple, ואז תוקנו. זו השיטה שאני מפעיל על כל אחת מהן, ואותה אני מציע לך כאן.

למה עמוד אחד מספיק כדי להגדיר את האפליקציה שלך

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

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

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

מה צריך להיות באפיון של אפליקציה?

ענה על כל אחת מהשאלות האלה במשפט או שניים.

1. מי משתמש באפליקציה, ובאיזה מצב? לא "בני 18-35". יותר אדם מסוים, ברגע מסוים ביום שלו.
2. איזו בעיה האפליקציה פותרת, במשפט אחד? אם אתה צריך "וגם", אתה מתאר שתי אפליקציות.
3. מהי הפונקציה המרכזית של הגרסה הראשונה? אחת בלבד. השאר יחכו למספרים. העמוד MVP לאפליקציית iOS מסביר איך לבחור.
4. איך האפליקציה מרוויחה כסף? מנוי, רכישה חד-פעמית או חינם. התשובה הזו משנה את האפליקציה כבר מהמסך הראשון. אם אתה מתלבט, קרא מנוי או רכישה חד-פעמית לאפליקציית iOS.
5. מה אפשר לעשות בלי ליצור חשבון? להחליט מוקדם מה זמין בלי הרשמה חוסך לך לבנות מחדש את כל תהליך הכניסה.
6. אילו נתונים חייבים לשרוד החלפת טלפון? זו השאלה שקובעת אם אתה צריך backend כמו Supabase, או שהכול יכול להישאר על המכשיר.
7. רק iOS, או iOS ו-Android? העצה שלי כשאתה מתחיל: קודם iOS. אני מפרט למה באפליקציית iOS ו-Android במקביל.
8. מה במפורש לא נכנס לגרסה הראשונה? החלק הכי שימושי במסמך. הוא חותך ויכוחים עוד לפני שהם מתחילים, גם עם עצמך וגם עם ה-AI.
9. איך תדע שזה עובד? סימן אחד, שאפשר למדוד בשבועות שאחרי ההשקה: תקופות ניסיון שהתחילו, מנויים, משתמשים שחוזרים.
10. מה האילוצים האמיתיים שלך? הזמן שאתה יכול להקדיש כל שבוע, הציוד שלך, וחשבון Apple Developer שעולה 99 דולר לשנה. אין לך Mac? זה לא חוסם, כמו שאני מסביר בלפרסם אפליקציית iOS בלי Mac.

תבנית האפיון להעתקה

העתק את התבנית לפתק או לקובץ טקסט בתיקייה הראשית של הפרויקט, ואז החלף כל שורה.

• שם זמני לאפליקציה: …
• בשביל מי: אדם ש… ברגע ש…
• הבעיה שנפתרת, במשפט אחד: …
• הפונקציה המרכזית של גרסה 1: …
• מה המשתמש רואה כשהוא פותח את האפליקציה בפעם הראשונה: …
• מודל עסקי: מנוי / רכישה חד-פעמית / חינם, ומה בתשלום: …
• בלי חשבון אפשר: …
• נתונים שנשמרים בין שני טלפונים: אין / …
• פלטפורמה: קודם iOS (Android בהמשך אם המספרים מצדיקים)
• מחוץ לגרסה 1: …, …, …
• סימן הצלחה: …
• Stack: React Native, Expo, Supabase אם צריך חשבונות, RevenueCat למנויים
• אילוצים: … שעות בשבוע, חשבון Apple Developer פתוח או לא, Mac או לא
• אפליקציות שאני אוהב את החוויה שלהן, ולמה: …

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

אפיון הוא לא רשימת משאלות. הוא רשימת החלטות שהתקבלו.

דוגמה: העמוד ממולא עבור אפליקציה בדיונית

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

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

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

איך להשתמש באפיון כדי לכוון את ה-AI

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

שים את העמוד בהקשר הקבוע של הפרויקט. Claude Code קורא קובץ CLAUDE.md בתיקייה הראשית, ול-Cursor יש קובצי חוקים משלו. הדבק שם את האפיון, יחד עם ה-stack שלך. כך כל בקשה יוצאת מאותו בסיס.

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

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

תן לו לבדוק את העמוד, לא רק את הקוד. שאל: "אילו שאלות באפיון הזה עמומות או סותרות?". זה שימוש לא מוערך מספיק ב-AI, והוא חוסך לך שבועות של עבודה בכיוון הלא נכון.

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

להפוך החלטות לקריטריוני בדיקה

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

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

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

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

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

להחליט מה להוריד כשהגרסה הראשונה גולשת

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

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

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

המלכודת של קטלוג הפיצ'רים

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

גרסה ראשונה טובה עושה דבר אחד, ועושה אותו טוב. רק תיזהר מהקיצון השני: Apple דורשת שאפליקציה תהיה יותר מאתר עטוף, לפי סעיף 4.2 של ה-App Review Guidelines. פונקציה מרכזית אחת, כן; קליפה ריקה, לא: זו עילת הדחייה של guideline 4.2.

מה לא צריך להיות באפיון של אפליקציה

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

מתי לעדכן את האפיון?

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

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

מהעמוד לאפליקציה מפורסמת

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

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

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

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

שאלות נפוצות

איך כותבים אפיון לאפליקציה?

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

באיזו תוכנה לכתוב אפיון לאפליקציה?

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

צריך אפיון של 40 עמודים לאפליקציה?

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

איך נותנים את האפיון ל-AI שכותב קוד?

שים את העמוד בהקשר הקבוע של הפרויקט: Claude Code קורא קובץ CLAUDE.md בתיקייה הראשית, ול-Cursor יש קובצי חוקים משלו. צטט את החלק "מחוץ לגרסה 1" כשה-AI מגזים. לפני משימה גדולה, בקש תוכנית שמכבדת את העמוד, בלי לכתוב קוד מיד.

איך בודקים שפונקציה עומדת באפיון?

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

מה לא כדאי לשים באפיון של אפליקציה?

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