8 רכיבים חשובים בהסכם פיתוח אתר או אפליקציה לעסק שלכם

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

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

אז מה חשוב?

ראו 8 סעיפים שחשוב שההסכם יתייחס אליהם:

עקבו אחרי עו"ד ליכטנשטיין בגוגל

1) בעלות על הקוד

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

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

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

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

2) גישה לקוד המקור

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

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

3) אפיון או מפרט טכני

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

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

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

4) לוח זמנים ואבני דרך

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

וזה בדיוק מה שעליכם לעשות.

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

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

5) צרו נספח שירות (SLA)

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

SLA צריך להגדיר בבירור שלושה רכיבים: (1) זמן תגובה מינימלי, (2) זמינות מינימלית (כמה זמן עלול האתר שלא להיות באוויר. מה ה-Uptime שלו?), ובמקרים מסויימים גם (3) זמן לפתרון הבעיה (אם כי זה רכיב שלעיתים קרובות אינו ניתן להגדרה, מראש).

6) מה האחריות לתחזוקה ועדכונים

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

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

7) מה קורה בסיום ההתקשרות?

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

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

8) פיצוי מוסכם וסעדים

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

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

טעויות נפוצות במגעים מול המפתח

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

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

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

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

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

ייעוץ, כתיבת הסכמים ובדיקת הסכמים קיימים

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

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

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