בנינו אפליקציה אישית כחלופה למנוי RiseUp
אפליקציה בעברית עם תנועות, תקציבים ותחזית נבנתה על מקור נתונים קיים. כך העברנו היסטוריה וקטגוריות, ומה עדיין חסר כדי לאמת עצמאות וחיסכון של כ־390 ש״ח בשנה לפני עלויות.
ניהול כספים אישיים · החלפת מנוי תוכנה · תקופה: גרסה 1.4.0 מתועדת ב־19 באוקטובר 2026; סקירת מקורות ב־20 באוקטובר · עודכן
כלים: Moneytor, Python, SQLite, Next.js, TypeScript, Vercel, Claude
הפרויקט בקצרה
- השירות המקורי
- RiseUp לניהול תזרים אישי
- עלות המנוי הקודם
- כ־390 ש״ח בשנההערכת הבעלים; המטבע הונח כשקלים. חשבונית ומעמד המע״מ לא נבדקו.
- החלופה
- אפליקציה אישית בעבריתנתוני Moneytor, היסטוריה מיובאת, קטגוריות ותקציבים.
- כלי AI בפיתוח
- Claudeתרומה מתועדת בקוד; אין מדידת שעות או עלות נפרדת.
- תקופת הפיתוח
- גרסאות מתועדות ב־18 וב־19 באוקטובראין מכאן מדידה של מלוא משך ההקמה או שעות העבודה.
- עלות שוטפת חדשה
- טרם חושבהיש לכלול מקור נתונים, אחסון ותחזוקה.
- חיסכון שנתי נטו
- טרם אומת
- מצב המעבר
- אפליקציה בנויה; עצמאות טרם הוכחהביטול RiseUp תוכנן ל־20 באוקטובר. הרענון עדיין כולל סנכרון תקציבים ממנו.
1. מה קיבלנו מהמנוי הקודם
השימוש ב־RiseUp היה אישי: להבין מה נכנס, מה יצא, לאילו קטגוריות שייכות ההוצאות ומה עוד צפוי לרדת. המשימה היומיומית אינה מסתיימת ברשימת תנועות. צריך לחבר בין חיוב, חודש התקציב והתשלומים העתידיים כדי לקבל תמונה שאפשר לעבוד איתה.
החלופה נבנתה עבור חשבונות אישיים בלבד, על בסיס מקור נתונים שהיה זמין דרך Moneytor. הרעיון היה ליצור מסכים וכללים שמתאימים לאופן שבו הבעלים עוקב אחרי הכסף, תוך שמירת היסטוריה שכבר סודרה. התוצאה המתועדת היא אפליקציה בעברית עם תנועות, קטגוריות, תקציבים ותחזית. עצמאות מלאה מ־RiseUp עדיין דורשת בדיקה נוספת, משום שמסלול הרענון ממשיך לפנות אליו לקבלת תקציבים.
2. נקודת המוצא הכלכלית
עלות RiseUp שנמסרה הייתה כ־390 בשנה. בחישוב הנוכחי אנחנו מניחים שקלים, לפי ההקשר, ומסמנים את הסכום כהערכת הבעלים. לא נבדקו חשבונית, מע״מ, הנחה או תנאי החידוש. גם היקף השירות שנכלל במסלול המקורי אינו משוחזר כאן במלואו.
ההפרש שכדאי לבדוק הוא ההוצאה הנוספת שנוצרת בגלל החלופה. Moneytor, אחסון ועבודת תחזוקה עשויים לעלות כסף גם כשהממשק נכתב במיוחד למשתמש אחד. אם מקור הנתונים היה נרכש ממילא, אפשר לחשב רק את התוספת שנגרמה מהאפליקציה, בתנאי שמסבירים את ההקצאה. בלי נתוני החיוב האלה אין בסיס להכריז על חלופה חינמית.
| רכיב | סכום או מצב | מקור |
|---|---|---|
| מנוי RiseUp | כ־390 ש״ח לשנה | הערכת הבעלים מ־20 באוקטובר 2026 |
| מועד הביטול | תוכנן ל־20 באוקטובר | תיעוד הפרויקט; הפסקת הגישה לא אומתה |
| נתונים ואחסון בחלופה | לא נמדדו לצורך ההשוואה | יש להפריד תוספת עלות מהוצאה קיימת |
3. למה לבנות אפליקציה אישית
היכולת לקבל תנועות ממקור קיים פתחה אפשרות לבנות את שכבת העבודה שסביבן: סידור קטגוריות, כללים לבתי עסק, תשלומים ותקציב. במקום להתחיל מחיבור עצמאי לבנקים, אפשר היה להתמקד בדרך שבה הנתונים הופכים להחלטות יומיומיות של המשתמש.
היקף אישי מאפשר לבחור מה נחוץ ולהימנע מהקמת מוצר שמיועד לכל משק בית. ובכל זאת, רף ההצלחה גבוה ממסך שמציג סכום: תיקון קטגוריה צריך להישמר, תשלום עתידי צריך להגיע לחודש הנכון, והעברת היסטוריה לא אמורה להכפיל הוצאות. החלופה תיחשב עצמאית רק כאשר העדכון השוטף והתקציב ימשיכו לעבוד גם אחרי שהגישה לשירות הישן מסתיימת.
4. מה חייב להישאר אחרי המעבר
הדרישות כללו תנועות והכנסות, סיכום חודשי, קטגוריות שניתן לערוך, תקציבים, זיהוי חיובים חוזרים ותצוגת התחייבויות עתידיות. נוספו רשומות ידניות ויומן פעילות, כדי שהמשתמש יוכל להסביר שינוי ולחזור ממנו כשהפעולה הפיכה. הממשק נבנה בעברית ומימין לשמאל.
חשובה לא פחות הייתה ההבחנה בין מה שנצפה במקור לבין מה שהאפליקציה הסיקה. זיהוי חיוב חוזר מבוסס על דפוס בתנועות; תחזית אינה אישור מהבנק. כשחלק מהמידע חסר, צריך להציג את הכיסוי ולהשאיר למשתמש אפשרות לתקן.
| צורך | הפתרון המתועד | הנקודה שדורשת תשומת לב |
|---|---|---|
| היסטוריה | ייבוא RiseUp וחיבור לנתוני Moneytor | מניעת ספירה כפולה בין המקורות |
| קטגוריות | כללים ותיקונים לפי תנועה או בית עסק | תיקון המשתמש צריך לקבל קדימות |
| תשלומים | שיוך לפי מועד חיוב והצגת התחייבויות | תשלום עתידי לא נספר כהוצאה שכבר קרתה |
| תקציב | עריכה באפליקציה ונתונים שמקורם ב־RiseUp | העצמאות לאחר ביטול טרם אומתה |
| בקרה | יומן פעילות ותצוגת כיסוי | השלמת נתונים חסרים נשארת משימה אנושית |
5. הכלים, ה־AI והאוטומציה
Python מבצע את האיסוף והעיבוד, SQLite שומר את הנתונים, ואפליקציית Next.js עם TypeScript מציגה את התוצאה. הנתונים המוצגים מגיעים מעותק מעובד שנשמר באחסון פרטי. כך ממשק הגלישה אינו צריך לקבל את פרטי הגישה למקור הבנקאי כדי להציג את התנועות.
Claude מופיע כשותף לכתיבת הקוד בהיסטוריית הגרסאות, לרבות עבודת הקטגוריות וייבוא ההיסטוריה. זו עדות לעזרה בפיתוח, בלי אפשרות להסיק ממנה שעות שנחסכו או איזה חלק נכתב ללא תיקון. כללי סיווג שנלמדו מהיסטוריה הם מנגנון נפרד: הם מחילים התאמות מתוך נתונים קודמים.
קיים גם תיעוד למחקר בתי עסק באמצעות Claude, אך הוא מסומן כתוספת שלא שוחררה ובברירת מחדל מציע שינויים לבדיקה. הוא אינו הבסיס לטענה שהחלופה כבר מפעילה ייעוץ פיננסי אוטומטי.
| כלי | תפקיד | תלות שוטפת |
|---|---|---|
| Moneytor | מקור לתנועות עדכניות | נדרש לרענון |
| Python ו־SQLite | עיבוד ושמירת הנתונים | נדרשים להפעלת המערכת |
| Next.js, TypeScript ו־Vercel | ממשק עברי ואירוח | נדרשים להצגת האפליקציה |
| Claude | סיוע מתועד בפיתוח | עלות הפיתוח לא הופרדה |
| RiseUp | היסטוריה מיובאת וסנכרון תקציבים | עדיין נוכח ברענון המתועד |
6. איך העברנו את העבודה למערכת החדשה
הבסיס היה סנכרון תנועות, סיווג וסיכום חודשי. מעליו נבנו הממשק, שינויי הקטגוריות ועריכת התקציב. הגרסאות המתועדות ב־18 וב־19 באוקטובר 2026 מוסיפות גם יומן פעילות, בחירת קטגוריות נוחה ופרטי חיוב. התאריכים מתארים שחרורי גרסאות, ואינם מדידה של כל זמן הפיתוח.
בגרסה 1.4.0 נוספה העברת ההיסטוריה מ־RiseUp. הייבוא שומר את שדות המקור ומוסיף תנועות היסטוריות או תנועות שמשלימות פער. כשקיימת תנועה מקבילה ב־Moneytor, המנגנון מקשר ביניהן במקום להציג שתיים. ההתאמה בוחנת אמצעי תשלום, סכום, קרבה בתאריך ודמיון בשם בית העסק.
העבודה לא נעצרת בייבוא הראשון. בכל סנכרון נבדק שוב החיבור בין המקורות, כדי שתנועה שנוספה מאוחר יותר לא תישאר לצד העותק שיובא. הועבר גם ידע על קטגוריות: כללים נוצרים רק כשיש מספיק דוגמאות ועקביות, ותיקון מפורש של המשתמש מקבל קדימות. כך נשמרת העבודה שהושקעה בסידור ההיסטוריה.
7. איך נראה שימוש שוטף
תהליך הרענון מושך תנועות, מעבד אותן ומעלה לאפליקציה עותק לתצוגה. המשתמש פותח חודש, בוחן הוצאות ותשלומים, ומתקן קטגוריה כשצריך. התיקונים נשמרים ונמשכים חזרה למנגנון העיבוד, כדי שהעבודה בדפדפן לא תיעלם בעדכון הבא. רשומות ידניות מקבלות טיפול נפרד כדי למנוע ספירה כפולה.
אם שלב חובה ברענון נכשל, התהליך נעצר ומסמן כישלון; הוא גם מונע ריצות חופפות. בזמן כתיבת הסיפור, שלב הסנכרון עדיין כולל תקציבים מ־RiseUp. לכן הצגת נתונים באפליקציה היום אינה מוכיחה שהרענון יצליח אחרי ניתוק הגישה אליו.
גם תאריך עדכון הקובץ אינו בהכרח תאריך העדכון בבנק. אפשר לעבד בהצלחה מידע שהמקור טרם רענן. בבקרה השוטפת צריך לבחון את טריות נתוני המקור ואת כיסוי החשבונות לצד מועד הרענון של האפליקציה.
8. איך בודקים שהחלופה באמת מספיקה
תיעוד הפרויקט מציין פריסה של גרסה 1.4.0 ב־19 באוקטובר. לצורך הכנת הסיפור נבדקו הקוד והתיעוד, בלי כניסה מחודשת לאפליקציה הפרטית ובלי הצגת תנועות אישיות. קיימים מנגנוני השוואה וכיסוי נתונים, אבל עצם קיומם אינו תוצאה של התאמה כספית שנבדקה בסבב הזה.
הבדיקה המכרעת צריכה לכלול חודש מוגדר: להשוות סך הכנסות והוצאות, לבדוק תנועות חופפות ולבחון תשלומים שטרם הגיע מועד חיובם. אחריה נדרשת תקופת עבודה ללא גישה ל־RiseUp. הביטול תוכנן ל־20 באוקטובר; מועד הפסקת הגישה, ביטול החיוב וההתנהגות לאחריהם עדיין לא אומתו.
| בדיקה | מה היא מוכיחה | מצב הראיות |
|---|---|---|
| ייבוא חוזר של ההיסטוריה | אותו קובץ אינו מוסיף הוצאות כפולות | התנהגות מתועדת במנגנון הייבוא |
| התאמה חודשית מול המקורות | הסכומים והחודשים נכונים | לא בוצעה כאן בדיקה חדשה בנתונים האישיים |
| כיסוי וטריות | המידע המוצג מספיק ועדכני | דורשים בדיקה שוטפת מול המקור |
| רענון אחרי סיום RiseUp | אין תלות פעילה במנוי הישן | טרם הוכח; סנכרון התקציב עדיין קיים |
9. מה אפשר לומר על החיסכון
אם חיוב RiseUp אכן ייפסק, הוצאות המנוי שעשויות להיחסך הן כ־390 ש״ח בשנה לפי ההערכה שנמסרה. זהו תרחיש שנתי לפני עלויות החלופה. אין כאן טענה שכבר נחסך הסכום, ואין בסיס להשליך יום עבודה מוצלח על שנה שלמה.
מהסכום יש להפחית תוספת עלות לנתונים, אחסון, שימוש בכלי AI אם יהיה שוטף, ותחזוקה. בשנה הראשונה צריך להביא בחשבון גם בנייה, בדיקות והעברת היסטוריה. אלה לא נמדדו במלואם. הבעלות על הממשק והיכולת להתאים אותו הן תועלות אמיתיות לשיקול, אבל לא הומרו כאן לשקלים.
| שורה בחישוב | הנתון הזמין |
|---|---|
| מנוי שנתי שעשוי להיחסך | כ־390 ש״ח, הערכת בעלים |
| תוספת עלות למקור הנתונים ולאחסון | לא נמדדה |
| תחזוקה ועלות ההקמה | לא נמדדו במלואן |
| חיסכון שנתי נטו וזמן החזר | טרם חושבו |
| חיוב שכבר נמנע | לא אומת בסקירה הזאת |
10. מה למדנו ומתי זה כדאי
המסכים הם החלק הגלוי של ההחלפה. העבודה שמאפשרת לסמוך עליהם נמצאת בטיפול בכפילויות, בתאריכי חיוב, בקטגוריות ובמידע החסר. ייבוא ההיסטוריה עוזר להתחיל עם הקשר, אבל הוא לא מבטל מעצמו חיבור פעיל לשירות הקודם.
הגישה מתאימה למי שיש לו מקור נתונים מתאים, צרכים אישיים מוגדרים ויכולת לתחזק את האפליקציה ולבדוק את התוצאות. מי שמעדיף שמישהו אחר יטפל בחיבורים, בתקלות ובשינויים עשוי לקבל ערך טוב יותר ממנוי מנוהל. במקרה הזה נבנתה חלופה בעלת יכולות שימושיות, והשלב הבא להוכחת הכדאיות ברור: ליישב את תלות התקציבים, לאמת את הפסקת החיוב ולמדוד תקופה של עבודה עצמאית יחד עם העלות שלה.
על הפרסום
זהו תיעוד של פתרון לשימוש עצמי. מחיר המנוי מבוסס על הערכת הבעלים ונמסר לצורך הסיפור; הוא לא אומת מול חשבונית. צילומי הממשק מציגים את התוכנה המקורית בסביבת הדגמה, ללא פרטי לקוחות או נתונים פיננסיים אישיים.
הפתרון פותח בידי Tiger Media. הסיפור מפריד בין מחיר מנוי משוער, הוצאה שנחסכה בפועל ועלויות הפיתוח והתחזוקה.
