מאב טיפוס לייצור: צ'קליסט

לפני המשתמש האמיתי הראשון

בחודש הראשון

עם הגדילה

למה דווקא בסדר הזה

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

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

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

אם חסרים סעיפים

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

שאלות נפוצות

אפשר להעלות לייצור אפליקציה שנבנתה ב-Lovable או ב-Bolt?

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

מה הכי מסוכן באב טיפוס של AI לפני השקה?

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

צריך לכתוב את אב הטיפוס מחדש מאפס?

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

כמה זמן לוקחת ההכנה לייצור?

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

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

מתחילים בסעיפים 2, 3 ו-5, בסדר הזה: סודות, גישה, גיבוי. הם סוגרים את מה שאי אפשר לתקן בדיעבד.