כשהפלטפורמה מגיעה לקצה - מה עושים כש-Low-Code לא מספיק

הבטחה שלא תמיד מתקיימת

פלטפורמות ה-No-Code וה-Low-Code מכרו חזון מפתה: בנו אפליקציות מהר, בלי להזדקק למפתחים בכירים, בעלות נמוכה. וחלק גדול מהחזון הזה אמיתי. אפשר לבנות היום דברים מרשימים עם Flutter, React Native, Power Apps, או Bubble, מבלי לכתוב שורת קוד אחת לבד.

עד שמגיעים לקצה.

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

ב-Bit-Gem, חלק לא מבוטל מהפרויקטים שלנו מתחיל בדיוק כאן.

למה No-Code ו-Low-Code עובדים כל כך טוב - עד שלא

פלטפורמות כמו Flutter, React Native, Ionic, Capacitor, MS Power Apps, Oracle APEX, ו-Priority Mobile App Generator נבנו כדי לכסות את 80% מהצרכים של רוב האפליקציות. ממשק משתמש, לוגיקה בסיסית, חיבור ל-API, שמירת נתונים. הן עושות את זה טוב, מהר ובעלות שפיתוח מסורתי לא יכול להתחרות בו.

הבעיה מתחילה ב-20% שנשארו.

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

הבעיות שחוזרות הכי הרבה בשטח

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

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

SDK של יצרן חומרה שלא תוכנן לעולם הזה. חברות שמייצרות מדפסות ניידות, סורקי ברקוד, מכשירי NFC, ציוד תעשייתי, כתבו SDK ב-Java או ב-C++. הן לא תכננו שמישהו ינסה לגרום לו לעבוד עם Capacitor או עם React Native. התוצאה: אין wrapper רשמי, אין תיעוד, ואין מי שיענה על שאלות.
פרוטוקולי תקשורת לא סטנדרטיים. חיבור להתקן חיצוני דרך RS232 over BLE, קריאת נתונים דרך OTG, ממשק עם מכשיר שמדבר פרוטוקול קנייני. כל אלה הם דברים שפלטפורמות Low-Code לא בנויות לטפל בהם.

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

הדינמיקה שאף אחד לא מדבר עליה

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

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

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

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

Vibe Coding: כשה-AI לא אומר "אי אפשר"

עם הכניסה של Vibe Coding לתמונה, נוסף ממד חדש לבעיה.

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

מה שחסר הוא לא עוד prompt טוב יותר. מה שחסר הוא ראיה מערכתית.

מה זה Bridge ולמה הוא לא "לבנות מחדש"

כשפלטפורמה מגיעה לקצה שלה, הפתרון הנפוץ הוא Bridge או Plugin מותאם אישית.

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

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

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

מתי לפנות אלינו?

אם יש לכם מוצר שנכתב ב-Framework כלשהו ואחד הנושאים הבאים מצלצל לכם מוכר:

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

אם אתם תקועים בדיוק שם - דברו איתנו.

במאמר הבא בסדרה: מה זה בדיוק Bridge ואיך הוא עובד מבחינה טכנית, עם דוגמאות מהשטח לגישה ל-GPS, NFC, BLE ו-OTG.