הנדסת חומרה בישראל: מדריך מעמיק
האב־טיפוס עובד. הלדים נדלקים, המנוע זז, האפליקציה מדברת עם הבורד. ואז מגיעה השאלה שמפרידה בין הדגמה למוצר: מה עכשיו?
בדרך כלל זה הרגע שבו מייסד מגלה שאין מסמך דרישות מסודר, אין תכנית DFM, אין החלטה מי הבעלים של המכלול, ואין תשובה טובה לשאלות בסיסיות כמו מה יקרה אם רכיב קריטי ייעלם מהמלאי, או איך המוצר הזה יעבור EMC בלי סבב תיקונים כואב. זה לא כשל של אנשים חכמים. זה פשוט מה שקורה כשחושבים על חומרה דרך ה־PCB בלבד.
בישראל זו טעות יקרה במיוחד, כי זה לא שוק קטן או שולי. לפי דוח השמה שפורסם ביולי 2026, שוק החומרה המקומי מונה כ־34,400 עובדים בתפקידי הנדסה ומחקר, ובאותה תקופה נרשמו 1,718 משרות פתוחות. בתוך השוק הזה, תחום המוליכים למחצה הוא הגדול ביותר בגיוס, עם 15,500 מהנדסי חומרה, שהם 45.1% מכוח האדם בתחום, ועם 64% מהמשרות הפתוחות, לפי הנתונים שפורסמו ב־mako. כלומר, הנדסת חומרה בישראל היא לא נישה. זו סביבת עבודה עמוקה, תחרותית, ומאד ממוקדת ביצוע.
וזה גם אומר שהיתרון לא הולך אוטומטית למי שיודע לצייר סכימה. הוא הולך למי שיודע לקחת רעיון, לנסח דרישות, לבנות ארכיטקטורה, לבחור תהליך, ולשמור על שליטה כשהמוצר פוגש ייצור, רגולציה ושרשרת אספקה.
למה הנדסת חומרה לא מתחילה במעגל המודפס
ראיתי יותר מפעם אחת יזם שמחזיק ביד בורד עובד, מרוצה בצדק, ואז מבין שהמוצר שלו עדיין לא ממש קיים. יש כרטיס. אין מוצר. אין מי שהחליט איך המארז יפזר חום, אין מי שבדק אם אפשר לקנות את הרכיבים בכמות, ואין מי שסגר מהו מצב הכשל הבטוח אם החיישן מפסיק להגיב.
זה קורה כי קל להתאהב ב־PCB. הוא מוחשי, מדיד, נראה כמו התקדמות. אבל הנדסת חומרה מתחילה הרבה לפני השרטוט הראשון. היא מתחילה ברשימת דרישות טובה מספיק כדי לשרוד פגישה קשה עם ייצור, עם רגולציה ועם לקוח.
מוצר נכשל בדרך כלל במקום אחר
רוב הכשלים שאני רואה לא מתחילים בסכמה גרועה. הם מתחילים בדרישות חסרות. מוצר שלא הוגדר טוב ייכשל גם אם המעגל עצמו נקי ומסודר. למשל, אם לא הוגדר מראש מהי סביבת העבודה, הטמפרטורה, שיטות הניקוי, חיי הסוללה, מגבלות רעש, או ציפיות השירות, כל בחירה הנדסית בהמשך תהיה חצי עיוורת.
אותו דבר עם רגולציה. צוותים רבים דוחים את זה כי "קודם נעבוד". בפועל, ברגע שמוצר נוגע ברפואה, בתקשורת, בבטיחות או בסביבה תעשייתית, הדרישות האלה כבר יושבות בתוך הארכיטקטורה. הן לא נספח.
מוצר חומרה לא נופל רק כי בחרו קבל לא נכון. הוא נופל כי אף אחד לא החליט בזמן מה בעצם צריך לבנות.
ה־PCB הוא תוצאה, לא נקודת פתיחה
מי שמגיע מעולם האלקטרוניקה אוהב להתחיל מרכיבים, מ־MCU, מממירי מתח, מקונקטורים. זה טבעי. אבל בפועל המעגל המודפס הוא תרגום של החלטות קודמות: מה המוצר עושה, מי משתמש בו, איך מייצרים אותו, איך בודקים אותו, ואיך מתקנים אותו אחרי חודש אצל לקוח.
גם כשנכנסים לפרטים כמו מה זה PCB, חשוב לזכור שזה לא רק לוח עם נחושת ורכיבים. זה ממשק בין עולמות. אלקטרוניקה, מכניקה, קושחה, רכש, בדיקות והרכבה נפגשים שם. אם אחד מהם לא הוגדר נכון, המעגל ישלם את המחיר.
שלושה דברים שכדאי לסגור לפני שפותחים כלי EDA:
דרישות שימוש אמיתיות: מי מפעיל את המוצר, באיזה תנאים, ומה אסור שיקרה.
בעלות מערכתית: מי מחליט כשמכניקה, אלקטרוניקה וקושחה מושכים לכיוונים שונים.
כוונת ייצור: אב־טיפוס חד־פעמי הוא לא אותו תכנון כמו סדרה קצרה או מוצר שנועד להתרחב.
כשעושים את זה נכון, ה־PCB הופך לתוצאה טובה של חשיבה רחבה. כשלא עושים את זה, הוא נהיה מסמך יפה של הבעיה.
ארבעת תחומי האחריות שמחזיקים את המוצר
אפשר לחלק את העבודה לארבעה תחומים. לא כי המציאות מסודרת, אלא כי בלי מסגרת כזאת קל מאד שדברים ייפלו בין הכיסאות. בפועל הגבולות מטושטשים כל הזמן, וזה בדיוק העניין.
תכן מכאני
המארז הוא לא קופסה שבוחרים בסוף. הוא חלק מהביצועים. בחירה בין אלומיניום לפוליקרבונט, למשל, תשפיע על פיזור חום, עמידות, תחושת מוצר, משקל, קליטת RF, ועלות הכלי. לפעמים אלומיניום פותר יפה בעיית חום, ואז מגלה בעיית אנטנה. לפעמים פוליקרבונט עוזר לרדיו, ואז דורש חיזוקים מכאניים ומייצר כאב ראש בהרכבה.
במוצרים שמוחזקים ביד, גם ארגונומיה היא הנדסה לכל דבר. אם לחצן דורש כוח לא נכון, או אם שקע טעינה יושב בזווית גרועה, הלקוח לא יכתוב "בעיה מכאנית". הוא פשוט יחשוב שהמוצר לא טוב.
תכן אלקטרוני
כאן בונים את השלד החשמלי של המערכת. סכמות, חלוקת מתח, תקשורת, הגנות, בחירת רכיבים וארכיטקטורה. ההחלטה החשובה היא בדרך כלל לא איזה ממיר לבחור, אלא מה לא להכניס למערכת.
MCU עם זמינות ארוכת טווח שווה לפעמים יותר ממפרט נוצץ. רכיב "מעולה" בלי ודאות רכש עלול להפוך את ההנדסה לשבויה של המחסן. אותו דבר עם ממשקים. עוד UART אחד נראה זניח על הסכמה, ואז מגלה עלות פינים, עומס קושחה, וניתוב שמסתבך סתם.
קושחה
הרבה מייסדים מדברים על חומרה כאילו הקושחה היא תוספת. היא לא. במוצרים אמיתיים היא זו שמחברת בין רכיבים, קובעת התנהגות, ומצילה או מפילה את היציבות של המערכת.
בקר BLDC, ניהול צריכת הספק, עדכון OTA, טיפול בשגיאות, אבטחה בסיסית, bring-up של תקשורת. כל אלה יושבים בקושחה. אם האלקטרוניקה לא תוכננה עם נקודות דיבוג נכונות, או אם המכניקה לא מאפשרת גישה נוחה לצריבה ובדיקה, הקושחה תשלם בזמן.
כלל עבודה: אם תחום אחד "מסיים" בלי לדבר עם שלושת האחרים, מישהו רק דחה את הבעיה לשלב יקר יותר.
DFM שמחבר הכול
DFM הוא לא שלב של היצרן בסוף. הוא השפה שמכריחה את כולם לדבר אמת. האם אפשר להלחים את הרכיב הזה בעקביות. האם solder mask מספיק סלחני. האם הפאנליזציה הגיונית. האם יש גישה לבדיקות. האם אפשר להרכיב בלי לשבור קליפס. האם טכנאי יכול לתקן יחידה בלי לפרק חצי מוצר.
הנה דרך קצרה לחשוב על זה:
מכניקה שואלת: איך זה ייראה ויחזיק.
אלקטרוניקה שואלת: איך זה יעבוד.
קושחה שואלת: איך זה יתנהג בשטח.
DFM שואל: איך תייצרו, תבדקו ותתקנו את זה בלי לאבד כסף ושפיות.
צוותים טובים לא "מעבירים" קבצים בין התחומים. הם מנהלים את נקודות החיכוך ביניהם. שם רוב העבודה האמיתית נמצאת.
מחזור החיים של מוצר חומרה מהרעיון ועד הסדרה
יש פיתוי קבוע לקפוץ ישר לאב־טיפוס. לפעמים זה מוצדק. ברוב המקרים זה רק נותן תחושת מהירות. מחזור החיים של מוצר חומרה עובד טוב כשמבינים איזה שלב חייב עומק, ואיזה שלב יכול להישאר רזה לזמן מה.
מהרעיון לאפיון
השלב הראשון הוא לא "פיתוח". הוא בירור. מי המשתמש, מה הערך, מה חייב לעבוד, ומה אפשר לדחות. כאן גם מחליטים אילו דרישות רגולטוריות יכולות להשפיע על הארכיטקטורה. זה השלב שבו טעות קטנה נראית זולה, אבל הופכת אחר כך ל־re-spin, לעיכוב רכש, או לבדיקת מעבדה חוזרת.
אחר כך מגיע אפיון טכני. מקצים משאבים, בוחרים עקרונות ארכיטקטורה, מחליטים איפה שמים סיכון ואיפה קונים ודאות. אם בוחרים ספק או רכיב רק לפי מה שנוח ל־PoC, עלולים לגלות ב־Pilot שהוא לא מתאים להסמכה, לשרידות, או לזמינות.
למי שרוצה מסגרת מסודרת יותר, שווה לעבור על מחזור חיי מוצר במבט של פיתוח וייצור, לא רק של רעיון ועיצוב.
מאב־טיפוס לאימות
PoC טוב נועד לענות על שאלה צרה. האם הפיזיקה עובדת, האם האלגוריתם אפשרי, האם מנגנון מסוים בכלל שווה השקעה. הוא לא נועד להיות בסיס ישיר לייצור. הבעיה מתחילה כשצוות מתאהב בפתרון זמני ומשאיר אותו במוצר.
אחריו מגיע אב־טיפוס פונקציונלי, ואז אב־טיפוס תכן־לייצור. זה שינוי גדול. פתאום מסדרים נקודות בדיקה, סוגרים מחברים, בוחנים stack-up, חושבים על הרכבה, אריזה ושירות. כאן נכנסות גם בדיקות EMC ובטיחות, לא רק כחותמת בסוף אלא כבדיקה אם הארכיטקטורה עומדת במציאות.
אם המעבדה היא המקום הראשון שבו אתם מגלים רעש, הארקה גרועה או לולאות זרם, הבעיה לא במעבדה.
פיילוט וסדרה
Pilot של עשרות יחידות נועד לחשוף בעיות שהנדסה שולחנית לא רואה. שונות בין יחידות, טעויות הרכבה, זמן בדיקה, תיעוד לא ברור, התנהגות בשילוח, ותקלות שנוצרות רק כשהמערכת חוזרת על עצמה. מי שמדלג על השלב הזה בדרך כלל משלם עליו בתוך הייצור.
יש גם הקשר רחב יותר. לפי דוח רשות החדשנות שצוטט במאי 2026, תעשיית החומרה הישראלית הוסיפה כ־16.7 מיליארד שקל לתוצר בשנה אחת, גידול של 20.7% לעומת 2024, בעוד שבשנים 2022 עד 2024 התוספת השנתית הממוצעת הייתה פחות מ־1.5 מיליארד שקל, כפי שצוטט ב־סקירה על נתוני רשות החדשנות. זה חשוב כי זה מסביר למה יותר צוותים ישראליים בונים חומרה שאמורה להגיע באמת לשוק, לא רק להדגמה.
השלב האחרון הוא ייצור סדרתי. שם אין קסמים. יש תיעוד, בקרה, שינויי הנדסה, רכש, עקיבות, ותהליך שחייב לשרוד גם כשהאנשים עייפים והלו"ז לחוץ. מי שבנה נכון את השלבים הקודמים, מגיע לשם עם פחות הפתעות.
כלים ותהליכים שכל צוות חומרה צריך להכיר
כלי טוב יכול לחסוך שעות. כלי לא מתאים יכול להפוך לצוואר בקבוק יקר. בצוות קטן, הבחירה לא צריכה להיות "מה הכי מתקדם", אלא מה מאפשר לעבוד מהר, לשתף קבצים בלי דרמה, ולשמור עקביות כשעוברים מאב־טיפוס לבדיקות ולייצור.
לא הכל צריך להיות אנטרפרייז
בתכן מכאני, SolidWorks ו־Fusion 360 הם בחירות טבעיות. הראשון מרגיש יציב ומסודר יותר כשיש מכלולים מורכבים ותיעוד קפדני. השני נוח מאד כשצריך גמישות, קצב מהיר ושילוב נגיש יותר עם עבודת אב־טיפוס.
ב־EDA, Altium עדיין חזק בצוותים שרוצים ספריות מסודרות, ניהול וריאנטים ועבודה הדוקה מול ייצור. KiCad יכול להיות בחירה מצוינת כשצריך מהירות, שליטה ועלות שפויה. הוא פחות "מארגן אותך בכוח", ולחלק מהצוותים זה יתרון. לאחרים זו דווקא מלכודת.
לסימולציה, LTspice נותן הרבה מאד ערך בשלב מוקדם. Ansys ואחרים נכנסים כשבאמת יש סיבה. לא כי "ככה מקצועי", אלא כי יש בעיית SI, תרמית, שדה, או מארז שמצדיקה את העומק.
התאמת כלי עבודה לגודל צוות חומרה
כלי / תהליך | מתי משתלם לצוות קטן |
|---|---|
SolidWorks | כשיש מארז, חלקים מותאמים, ותיעוד ייצור מכאני שחייב להיות נקי |
Fusion 360 | כשצריך לעבוד מהר, לאב־טיפוס, ולשנות גאומטריה בלי טקס |
Altium | כשמנהלים PCB מורכב, ספריות, וריאנטים ומעבר מסודר לייצור |
KiCad | כשצוות קטן רוצה שליטה ישירה וכלי קל יותר לתחזוקה |
LTspice | כשצריך לבדוק רעיונות אנלוגיים וספקים לפני שבונים |
Ansys | כשיש בעיית ביצועים אמיתית שדורשת סימולציה עמוקה |
PLM קל או BOM מבוסס Git | כשצריך עקיבות בלי להכביד על הצוות |
שערי DFM, DFA ו־DVT | כמעט תמיד. זה תהליך שמחזיר את עצמו מהר |
התהליך חשוב יותר מהלוגו על האייקון
צוות של שניים עד חמישה אנשים לא צריך מערכת כבדה רק כדי להרגיש "מסודר". הוא כן צריך החלטות ברורות: מתי BOM ננעל, מי מאשר footprint חדש, איך מנהלים ECO, ואיך בודקים שינויים לפני שחרור קבצים.
בנקודה הזאת גם שותפים חיצוניים נכנסים לתמונה. למשל, רותל הנדסת מוצר בע"מ מספקת תחת קורת גג אחת אפיון, תכן מכאני ואלקטרוני, דגמים, סדרות קצרות וייצור, וזה רלוונטי במיוחד לצוותים שרוצים פחות מעברי־יד בין ספקים שונים ויותר רצף תיעודי והנדסי.
התוכנה לא תציל תהליך מבולגן. תהליך בהיר יעבוד סביר גם עם כלים פחות נוצצים.
בסוף, כלי טוב הוא כלי שהצוות באמת משתמש בו. לא כזה שמרשים במצגת.
מכשור רפואי וסטארטאפים בישראל משחקים לפי כללים אחרים
במכשור רפואי, הרבה החלטות שנראות "הנדסיות" הן למעשה החלטות רגולטוריות בתחפושת. אם מחכים עם זה, משלמים פעמיים. פעם אחת בזמן פיתוח, ופעם שנייה כשמגלים שאי אפשר להוכיח בטיחות, חסינות או עקיבות בצורה שהשוק דורש.
בישראל זה לא שוק צדדי. לפי מדריך הסחר של ארה״ב לשוק הבריאות בישראל, תחום המכשור הרפואי מהווה בערך מחצית משוק הבריאות המקומי, ושוויו הוערך ב־3.4 מיליארד דולר ב־2024, עם קצב צמיחה שנתי ממוצע של כ־2% עד 2028 כהערכה. בנוסף, היקף הייצוא הישראלי של מכשור רפואי הגיע לכ־3.4 מיליארד דולר ב־2024, לפי דוח תעשיית הבריאות וההייטק המצוטט כאן. המשמעות פשוטה. גם מוצר קטן פוגש מהר מאד שוק גלובלי.
EMC ובטיחות הם חלק מהארכיטקטורה
בישראל, בדיקות EMC ו־EMI אינן רק בדיקת איכות בסוף הדרך. מעבדת התאימות האלקטרומגנטית של מכון התקנים הישראלי מציעה בדיקות וייעוץ כבר מהשלב הראשוני של הפיתוח ועד בדיקות סופיות, לפי תקנים רלוונטיים כמו IEC 60601-1-2, IEC 61000-4-2, IEC 61000-4-3, IEC 61000-4-4, IEC 61000-4-5, IEC 61000-4-6, IEC 61000-4-8, IEC 61000-4-11, CISPR 11, CISPR 22/24/32, EN 55011/14/24 ו־EN 61000-6-1/2/3/4, כפי שמתואר ב־סקירה על בדיקות EMC ו־pre-compliance. זה אומר שתכנון הארקות, מיגון, פילטרים, הפרדת תחומי זרם מהיר ואנלוגי, ותקציב רעש, צריכים להיכנס מוקדם.
גופי פיתוח בישראל גם מדגישים את השילוב בין PCB, bring-up, בדיקות EMC ובטיחות, כולל התאמה למכשור רפואי וציוד תעשייתי, עם רלוונטיות ברורה ל־IEC 60601-1 ו־IEC 60601-1-2, כפי שמתואר ב־סקירה מקצועית על פיתוח חומרה למערכות מוסדרות. במילים פשוטות, אם לא בניתם מראש הפרדה נכונה בין קווי הספק, אות רגיש ו־RF, המעבדה רק תאשר לכם שניחשתם לא נכון.
ישראל מוסיפה שכבת מורכבות משלה
יש גם צד רגולטורי מקומי. לפי ניתוח מרשם התקני הרפואה בישראל, במערכת הישראלית רשומים 28,821 התקנים, מתוכם 91.8% מיובאים ורק 8.2% מיוצרים בישראל, ו־2,111 בעלי רישום משמשים כגורם המחזיק ברישיון מול הרשויות. זה חשוב כי סטארטאפ לא פועל בוואקום. הרבה פעמים יש גורם מתווך, רישום, אחריות מסמכית, ותלות בגורמים שאינם צוות הפיתוח עצמו.
מי שעובד על מכשור רפואי צריך לדבר מוקדם גם עם רגולציה למכשור רפואי, לא רק עם מהנדס בורדים. שם נחסכות הטעויות האמיתיות.
הגישה שעובדת היא פשוטה. לתכנן מוצר כאילו כבר מחר מישהו יבקש לראות את ניהול הסיכונים, ה־V&V, בחירת הרכיבים, וההיגיון מאחורי כל ממשק.
מיקור חוץ בהנדסת חומרה מתי זה משתלם ומתי זה מסוכן
מיקור חוץ הוא לא קיצור דרך. הוא החלפה של סוג אחד של מאמץ בסוג אחר. במקום לנהל הכול פנימה, מנהלים גבולות, תיעוד, אינטרסים והעברת ידע. לפעמים זה מהלך מצוין. לפעמים זו דרך אלגנטית לאבד שליטה.
איפה זה באמת עוזר
כשחסר ידע נקודתי, מעבדה, ציוד, או רוחב צוות, מיקור חוץ יכול לקדם מוצר מהר. זה נכון במיוחד ב־DFM, תכן מכאני לייצור, בניית דגמים, תבניות, פאנליזציה, bring-up מסודר, ובדיקות קדם־תאימות. ספק שעובד על הרבה מוצרים במקביל רואה תבניות שחוזרות על עצמן. הוא מזהה שגיאות שחברה צעירה פוגשת בפעם הראשונה.
זה גם מועיל כשצריך לרוץ מהר לאב־טיפוס מתכת, לסדרה קצרה, או להרכבת לוח בלי להקים תשתית פנימית. לא כל סטארטאפ צריך לקנות כל יכולת בעצמו.
איפה זה מתחיל להסתבך
הסיכון הגדול הוא לא רק IP. הוא אובדן ידע. אם ספק משנה מקבל בפועל החלטות ארכיטקטורה, בוחר רכיבים, מגדיר תהליכי בדיקה ושומר אצלו את כל ההיגיון, החברה עצמה נשארת עם קבצים אבל בלי הבנה.
הסיכון השני הוא תלות באדם אחד. בית תכן קטן עם איש מפתח מבריק יכול לעבוד נהדר, עד שהוא לא זמין. פתאום אין מי שמבין למה נבחרה טופולוגיית ההספק, למה בוצע שינוי footprint, או איך לפרש חריגת בדיקה שחזרה מהשטח.
אם אי אפשר להעביר את המוצר למהנדס אחר עם תיעוד סביר, זה לא שיתוף פעולה. זו תלות.
איך מחליטים נכון
כמה שאלות טובות חותכות הרבה בלבול:
מה חייב להישאר בליבת החברה: ארכיטקטורה, ידע קליני, אלגוריתם, חוויית משתמש, או קשר עם הלקוח.
מה אפשר לקנות כשירות: תכן מפורט, פריסת PCB, בדיקות, דגמים, הרכבות, תיעוד ייצור.
מה רגיש מדי להוצאה החוצה: IP, בטיחות, החלטות מוצריות מרכזיות.
כמה שקיפות קיימת: האם מקבלים מסמכי דרישות, ECO, BOM, תכניות בדיקה וקבצי מקור מסודרים.
שותף טוב לא רק "מוסר תוצאה". הוא עובד בשקיפות, מתעד החלטות, מסכים על תחומי אחריות, ומבין את הרגולציה הרלוונטית למוצר. שותף בעייתי מחליף שיחה הנדסית במילים מרגיעות.
מיקור חוץ משתלם כשהוא מגדיל קצב בלי לשבור בעלות. הוא מסוכן כשהוא מסתיר את המוצר מהחברה שבונה אותו.
מה עושים מחר בבוקר רשימה קצרה ליזם
אחרי כל הדיבורים על ארכיטקטורה, רגולציה, קושחה וייצור, נשארת שאלה אחת שימושית. מה עושים מחר בבוקר. לא בעוד רבעון. מחר.
הרשימה הקצרה שבאמת עוזרת
תתחילו במסמך דרישות. לא מסמך מפואר. מסמך אמיתי. מה המוצר חייב לעשות, באילו תנאים, ומהם מצבי הכשל שאסור לקבל. אם אין דבר כזה, כל שיחה על BOM או layout מוקדמת מדי.
אחר כך תכתבו החלטות ארכיטקטורה במקום אחד. לא בראש של המהנדס, ולא מפוזר במיילים. למה נבחר הממשק הזה, למה ההספק מחולק כך, מה נבדק, ומה נדחה בכוונה. ההרגל הזה חוסך ויכוחים מיותרים חודשיים אחר כך.
שש בדיקות מהירות
בדיקת דרישות: האם כל מי שבונה את המוצר עובד מול אותה גרסה.
בדיקת סיכוני רגולציה: האם יש משהו שמשפיע כבר עכשיו על הארכיטקטורה.
בדיקת ייצור: האם מישהו בחן אם אפשר להרכיב, לבדוק ולתקן את התכן.
בדיקת רכיבים: האם יש רכיב קריטי שאין עליו ביטחון רכש או תיעוד נדרש.
בדיקת גבולות מיקור חוץ: מה נשאר פנימה ומה יוצא החוצה.
בדיקת אבני דרך: האם ברור מהו PoC, מהו אב־טיפוס פונקציונלי, ומהו Pilot.
עדיף מסלול צנוע וברור על פני תכנית נוצצת שאף אחד לא יכול לבצע.
הדבר האחרון הוא לבחור בעלים. לא "הצוות". אדם. מישהו שמחזיק את התמונה המלאה ודואג שהחלטה מכאנית לא שוברת קושחה, שהחלטת אלקטרוניקה לא הורסת בדיקות, ושהלחץ לזוז מהר לא מוחק את היכולת לייצר.
זה כל הסיפור של הנדסת חומרה, בעצם. לא לצייר לוח. לבנות מוצר שאפשר לחיות איתו גם אחרי שהדמו נגמר.
אם אתם בונים מוצר שצריך לעבור את הדרך המלאה, מאפיון ותכן אלקטרוני ומכאני ועד דגמים, סדרות קצרות וייצור, שווה לדבר עם מי שחי את המעבר הזה ביום־יום. רותל הנדסת מוצר בע"מ מלווה חברות בפיתוח, DFM, אב־טיפוס וייצור, וזה בדיוק המקום שבו הרבה רעיונות טובים הופכים למוצרים אמיתיים.