מקרה בוחן
Adencer: מרקטפלייס יוצרים עם הכסף, הניירת והחבילות בפנים
פלטפורמה דו-צדדית שבה מותגים מזמינים יוצרי תוכן: בריפים לקמפיינים, חיפוש יוצרים לפי מילות מפתח ולפי משמעות, תזרים תשלום בנאמנות על Stripe, חשבוניות לפי הרגולציה הצרפתית כולל זיכויים, וחבילות שנעקבות עד לנקודת האיסוף. 28 מודלי נתונים, 171 נקודות קצה בצד השרת.
התפקיד שלי
זו הפלטפורמה של לקוח, לא שלי. עבדתי עליה כמפתח פול סטאק לצד הצוות של הלקוח, מסוף דצמבר 2025 עד אמצע יוני 2026. המוצר שייך להם, לא הייתי האדם היחיד במאגר הקוד, ואני לא הולך לכתוב את הדף הזה כאילו כן.
המצב
מותג שרוצה שיוצר יפרסם על המוצר שלו צריך לעשות בערך שמונה דברים שאין להם שום קשר לשיווק: למצוא את האדם הנכון, לסכם מחיר, לשלם בלי שאף צד ייחשף, לשלוח את המוצר, לאשר את התוכן לפני הפרסום, להוציא חשבונית כמו שצריך, ולדעת לאן לפנות כשמשהו משתבש. Adencer היא הפלטפורמה שמחזיקה את כל השמונה במקום אחד.
האילוץ
החלק הקשה במרקטפלייס הוא אף פעם לא דף הרשימה, אלא הכסף. מותג לא ישלם לזר מראש ויוצר לא יעבוד על סמך הבטחה, ולכן התשלום מאושר בזמן ההזמנה, נגבה בזמן האישור, ורק אחר כך מועבר ליוצר. כל אחד מהמצבים האלה חייב להיות בר-שחזור: גבייה שעברה חצי, העברה שנתקעה מאחורי חשבון תשלומים לא מאומת, הזמנה שבוטלה אחרי שהכרטיס כבר חויב.
הפלטפורמה מוכרת בצרפת, ולכן הניירת היא לא אופציונלית ולא קוסמטית. חשבוניות ממוספרות ברצף, נושאות סכום לפני מס ואחרי מס, ותיקון הוא זיכוי שמצביע חזרה על החשבונית שהוא מתקן, אף פעם לא עריכה של המקור. החברה של יוצר נבדקת מול המרשם הלאומי, ומשיכה דורשת תעודת זהות ואישור מגורים לפני שאגורה עוזבת את הפלטפורמה.
וחלק גדול מהשיתופים האלה כרוך במוצר פיזי, מה שהופך את הפלטפורמה בשקט גם לחברת שילוח: מדבקות משלוח, נקודות איסוף, מעקב, ושרשור שיחה שצריך לעדכן את עצמו כשהחבילה באמת זזה.
מה בניתי
Adencer חי בכתובת adencer.com. החלקים שעבדתי עליהם:
- בריפים לקמפיין שנושאים את התסריט, את תמונות המוצר, את קוד ההנחה ואת ההנחה עצמה, האם התוכן טעון אישור לפני פרסום, והאם צריך לשלוח מוצר ולהחזיר אותו.
- שתי דרכים למצוא יוצר: חיפוש מסונן לפי מילות מפתח, וחיפוש לפי משמעות שהופך משפט רגיל לווקטור ומדרג פרופילים לפי קרבה מול מאגר שמור בזיכרון, כדי שמותג יתאר את האדם שהוא רוצה במקום לנחש את התגית הנכונה.
- אינסטגרם וטיקטוק מחוברים ב-OAuth, עם תמונות מצב של העוקבים וסטטיסטיקות נגזרות (שיעור מעורבות, ממוצע לייקים, שעות פרסום מיטביות) שמתרעננות מעת לעת, חידוש טוקנים שרץ ברקע, והתוצאות משורטטות בגרפים.
- תזרים התשלום בנאמנות מקצה לקצה על Stripe: אישור, גבייה, העברה, ביטול והחזר, עם חשבונות Stripe Connect ליוצרים, כרטיסים שמורים ותשלום בארנק, עגלה שמזמינה כמה יוצרים בבת אחת, ומסלולי השחזור להעברות שנתקעות.
- חשבוניות לפי הרגולציה הצרפתית: מספור רציף ממונה, סכומים לפני מס ואחרי מס, קובצי PDF שנוצרים לשני צידי העסקה, וזיכויים שמפנים לחשבונית שהם מתקנים.
- זהות וציות: חיפוש החברה במרשם הלאומי, מעמד מע״מ, ותהליך משיכה שאוסף תעודת זהות ואישור מגורים לפני שחרור תשלום.
- שילוח פיזי עם מדבקות מודפסות, חיפוש נקודות איסוף ומעקב, מחובר לצ׳אט כך שהשרשור מתעדכן ככל שהחבילה מתקדמת.
- צ׳אט שהוא גם התהליך: תוכן שנשלח, מאושר או נדחה בתוך השרשור, עם הודעות מערכת לאירועים שחשובים וקבצים מצורפים למי שצריך אותם.
- ביקורות ודירוגים, תהליך מחלוקת שהפתרונות שלו הם החזרים אמיתיים והעברות אמיתיות, מערכת ניהול, התראות פוש ואימיילים תפעוליים.
המספרים
- 28מודלי נתונים
- 171נקודות קצה בצד השרת
- 63מסכים
- 4מצבי תשלום, מאישור עד העברה
- 2שפות, צרפתית ואנגלית
- 4סוגי חשבון
אלה ספירות הנדסיות, שנקראו מהקבצים של הפרויקט עצמו: סכמות הישויות, תיקיות פונקציות השרת, רכיבי הדפים, רשימת מצבי התשלום ותיקיות השפות. אין בדף הזה מספר משתמשים, אין הכנסות ואין שיעור עמלה. המספרים האלה שייכים ללקוח, לא לי, וזה שלו לפרסם.
מה עשיתי ומה לא עשיתי
זה המוצר של מישהו אחר. הייתי בו מפתח פול סטאק במשך כחצי שנה; לא הייתי האדם היחיד במאגר והפלטפורמה אינה שלי. אם אתם קוראים את זה כדי להחליט אם לעבוד איתי, הגרסה הכנה היא שזה מראה שאני יודע לעבוד בתוך קוד גדול שכבר קיים, בנושאי תשלומים וציות, בלי לשבור אותו. זה לא המשפט ״בניתי את Adencer״, ואני מעדיף להגיד את זה כאן מאשר שתגלו את זה אחר כך.
הפלטפורמה בנויה על פלטפורמת אפליקציות מתארחת שהמחולל שלה כותב חלק גדול מהקומיטים. זו התפשרות אמיתית וראוי לקרוא לה בשמה: זה מה שמאפשר למרקטפלייס כל כך רחב להתקיים בכלל עם צוות קטן, וזה גם אומר שהקוד הזה אינו מעשה ידיו של זוג ידיים אחד. מקרה בוחן שהיה מדלג על זה היה מוכר לכם את הדבר הלא נכון.
מה הייתי עושה אחרת: רשומת ההזמנה הגיעה לתשעים וארבעה שדות על אובייקט אחד, כי כל יכולת חדשה (שילוח, דחיית מועד, מחלוקות, חשבוניות) הוסיפה את העמודות שלה לדבר היחיד שכולן נוגעות בו. זו הבחירה הזולה ביותר בכל פעם והיקרה ביותר בפעם העשירית. לנתק את השילוח ואת החשבוניות ממנה מוקדם היה עולה שבוע וחוסך הרבה יותר.
הסטאק
- React.js
- Vite
- Base44
- Tailwind CSS
- Radix UI
- Stripe
- Stripe Connect
- i18next
לראות
רוצים משהו כזה?
ספרו לי מה אתם בונים, או מה אתם עדיין עושים ידנית, ואני אגיד לכם איך הייתי ניגש לזה. בלי התחייבות.