מאחורי הקידוד ב-NaorX: איך נראה פרויקט דיגיטלי מלא - מאפיון ועד השקה (ישראל 2026)

חזרה לשורש של NaorX

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

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

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

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

אתרים ומערכות ווב

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

בוטים

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

אוטומציה ואינטגרציה

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

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

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

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

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

1) שיחת גילוי קצרה

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

2) היקף (Scope) שניתן לבדוק

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

3) בנייה עם בדיקות ביניים

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

4) סביבת בדיקות ואישור לקוח

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

5) השקה, ניטור קצר, ואחריות

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

בפרויקטים מסוימים יש גישה ל-Workspace שלי (מערכת משימות דומה ל-Trello) כדי שתראו סטטוס בלי לשאול כל יומיים בוואטסאפ. זה לא חובה לכולם, אבל כשיש כמה משתמשים בצד הלקוח, זה מוריד רעש.

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

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

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

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

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

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

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

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

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

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