מערכות ופלטפורמות מותאמות אישית

אנחנו בונים מערכות תפעוליות: המערכת שהעסק רץ עליה, ולא אתר שמתאר אותו. בפועל זה בדרך כלל Laravel או Next.js על AWS או Google Cloud, באזור il-central-1 ללקוחות ישראליים, כשהחלקים שבדרך כלל מתגלים מאוחר מתוכננים בכוונה כבר בהתחלה.

• הסכמה

  ההחלטה שנעשית קשה יותר בכל שבוע שדוחים אותה.

• תורים

  לא אופטימיזציה. ההבדל בין להאט לבין ליפול.

• ממשק ה־API

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

בסיס הנתונים הוא ההחלטה שנשארת

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

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

תורים הם לא אופטימיזציה

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

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

API מתוכנן פעם אחת

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

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

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

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

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

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

אנחנו בוחרים לפי הפרויקט ולא לפי הרגל. Laravel ו-PHP כשהעבודה תפעולית וארוכת טווח, Next.js ו-React כשהממשק הוא החלק הקשה, על AWS או Google Cloud. מה שלא נעשה זה לבחור משהו כי הוא חדש.

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

אנחנו מריצים את המוצרים שלנו על אותה תשתית, כולל irua.app ו-wagate.app, כך שההחלטות התפעוליות שאנחנו ממליצים עליהן הן כאלה שאנחנו חיים איתן בעצמנו.

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

ספרו לנו מה אתם בונים