השיקול השני עניינו בחשיבות המידע ובהקשר זה יש לבחון את השאלה אם מדובר במידע "הגורע בצורה משמעותית מן הציפיות הסבירות של הצד השני ביחס לעסקה" (פרידמן וכהן (כרך ב), בעמ' 194); ראה גם ע"א 8227/20 קסירר נ' אמסלם בפסקאות 36-35 (12.7.2023)).
השיקול השלישי עניינו בטיבה של מערכת היחסים בין הצדדים. בהקשר זה מציינים פרידמן וכהן כי יחסי אמון מכוננים מערכת יחסים שעשויה להקים חובות גילוי. צוין, בין השאר, כי בפסיקה הוטלה חובת אמון גם על מי שהזולת הסתמך על ייעוצו וחוות דעתו בשל אמון מיוחד שרכש לו וכן על צדדים לעסקה משותפת (שם, בעמ' 207). מידת האמון והמשמעות שיש לייחס לו נגזרת מנסיבותיו העובדתיות של המקרה הקונקרטי (ראו ע"א 230/80 פנידר, חברה להשקעות פתוח ובנין בע"מ נ' קסטרו, פ''ד לה(2) 713, 724-723 (1981)).
מן הכלל אל הפרט: פרוימוביץ הטעו את ורבר לגבי בשלות המערכת
- התשתית העובדתית, כפי שפורטה לעיל, מובילה למסקנה שפרוימוביץ הטעו את ורבר בעניין מהותי בעסקה.
- פרוימוביץ לא העמידו את ורבר קודם להתקשרות בעסקה על התהליך של פיתוח התוכנה כלאחר יד (ובכלל זה ללא אפיון מסודר ומובנה, ללא ניהול גרסאות ושינויים, ללא סביבת פיתוח נפרדת וללא טסטים אוטומטיים). הם גם לא הציפו בפני ורבר את הסיכון המשמעותי שהיה ברור לשמוליק סמוך להשקה, כאמור, בדבר הצפי לתקלות רבות כתוצאה מהתהליך הקלוקל של פיתוח התוכנה ואיכותה הנמוכה. שמוליק גם לא תיקן את ההבנה המוטעית שנוצרה אצל ורבר שנבעה ממצגים לא נכונים שהציג - כאילו העבודה על האתר כמעט הסתיימה כבר בחודשים ינואר ופברואר; אז הוא הציג שנדרשים "ליטושים" בלבד בניגוד למצב בפועל שבו פיתוח המערכת רק החל בחודש ינואר ועבודה משמעותית נעשתה בשלהיי אפריל ולאחר מכן. שמוליק גם גרם לורבר להבין - באופן שגוי - שהושקע כסף רב בפיתוח האתר בניגוד למציאות ובאופן שנסך תחושת ביטחון באיכות התוכנה, ובהתחשב גם באמון הרב שורבר נתנו בשמוליק תוך שהסתמכו על מקצועיותו כאיש תוכנה בעל מוניטין, כפי שהעיד גם עומרי (עמ' 62 לפרוטוקול ש' 18-13).
- באגים ותקלות בתוכנה הם כמובן צפויים וניתן גם להניח שהם בלתי נמנעים לחלוטין (או בעלות סבירה) גם אם הפיתוח הוא ברמה גבוהה. בהתאם, עמדה במשא ומתן של מפתח תוכנה שהוא לא מוכן ליטול אחריות שהתוכנה מושלמת או שהיא פותחה לפי סטנדרט מקובל שאינו מוגדר דיו היא לגיטימית. הפסול בהתנהלות של פרוימוביץ הוא שהמסרים של שמוליק נטעו בורבר את ההבנה שהפיתוח של המערכת הסתיים לפני חודשים ושבחודשים האחרונים עובדים על ליטושים בלבד ושהושקע הרבה כסף בפיתוח באופן שנסך הבנה שמדובר במערכת איכותית ושהתוכנה בשלה לעלות לאוויר. זאת, בעוד שתהליך הפיתוח במציאות היה כלאחר יד וחלקים משמעותיים פותחו ב"רגע האחרון" (בניגוד למה שהוצג) וללא ביצוע בדיקות מספקות. ברור גם שבעת המשא ומתן עם ורבר, ימים לפני ההשקה, שמוליק היה ער לאיכות הנמוכה של התוכנה ולמרות זאת הוא "רץ" להשקה תוך שמתגלות "כל הזמן בעיות חדשות". בהתאם, המסקנה המסתברת היא שהיה ברור לשמוליק שצפויות בעיות עם המערכת לאחר ההשקה מעבר לתקלות או באגים בלתי נמנעים. אלא ששמוליק בחר שלא לשתף את ורבר במידע מהותי זה.
- אמנם, כפי שעולה מניתוח הטענות והראיות לעיל, טענות רבות של ורבר לחוסרים קונקרטיים במערכת ביחס למה שהוצג (פונקציות שלא היו קיימות כלל) לא התקבלו. גם התקלות שהתגלו לא נחזות להיות מורכבות לטיפול. התקלה בתצוגת הלידים למשווקים שהייתה קריטית מבחינת אמון המשווקים טופלה בתוך זמן קצר יחסית ודומה גם שלא הייתה מורכבת בתיקון. גם יתר התקלות שעליהן הצביעו ורבר לא נחזות להיות מורכבות ונראה שטופלו בתוך זמן קצר.
אלא שהקושי העיקרי הוא, כאמור, לא במורכבות של התקלות הקונקרטיות (שניתן להניח ששמוליק לא היה מודע להן) ובאי מהותיות של מרבית החוסרים הפונקציונאליים בתוכנה. הקושי בהתנהלות של פרוימוביץ הוא בכך שפרוימוביץ לא שיתפו את ורבר במידע בדבר השבריריות של המערכת והיותה מועדת לתקלות אם תושק כמתוכנן, וזאת לנוכח אופיו הקלוקל של תהליך הפיתוח ואיכותה הנמוכה כתוצאה מכך. עצם העובדה שלא קיים תקן מקובל למערכות WordPress, כפי שהעיד המומחה בחקירה הנגדית (עמ' 75 לפרוטוקול ש' 12-8), אינו גורע מקיומם של מדדים לפיתוח איכותי ומקצועי, כעולה מחוות דעת המומחה. ניתן לקבל את הטענה של פרוימוביץ שבהיותם שותפים במיזם היה להם אינטרס בהצלחתו וגם להניח כי הם האמינו שתקלות שיתגלו יהיו פתירות ולראייתם נכון היה להתקדם בתהליך ההשקה, אך גם אם כך האמינו הם לא היו רשאים שלא לגלות את המידע לורבר קודם לכניסת ורבר למיזם בהשקעה בסכום משמעותי.