Розроблення мобільного додатка для планування бюджету
Бюджетування відрізняється від простого обліку витрат тим, що тут важлива не тільки історія, але й прогноз. Користувач дивиться вперед: скільки можна витратити до кінця місяця, хватить ли на відпустку, коли виплатити кредит. Це змінює й архітектуру даних, й логіку розрахунків.
Моделі бюджетування: вибір визначає архітектуру
Три основні методології, й під кожну потрібна своя модель даних:
Конвертний метод (Envelope budgeting). Кожна категорія — «конверт» з виділеною сумою на місяць. Витратив — конверт зменшується. Перерасход в одному конверті можна покрити з іншого. YNAB працює саме так. Технічно: сутність Envelope з allocated (виділено), spent (витрачено), available (залишок). Операція зменшує available у конверті, а не просто записується в історію.
Zero-based budgeting. Кожний рубль доходу повинен бути призначений у категорію. income - sum(allocations) = 0. Це вимагає активної роботи користувача на початку місяця: розподілити весь очікуваний дохід по конвертам. Добре працює для дисциплінованих користувачів, погано — для інших.
Percentage-based (50/30/20). Автоматичне поділення: 50% — потреби, 30% — бажання, 20% — накопичення. Проста модель, мінімум дій від користувача. Реалізується як rules-engine поверх операцій з авто-категоризацією.
Важливо закласти підтримку кількох методологій або четко визначити одну на старті — переробка моделі даних на середині розроблення обнуляє місяц роботи.
Прогнозування та цілі накопичень
«Накопити 150 000 на відпустку до серпня» — це SavingsGoal з targetAmount, targetDate, currentAmount. При додаванні доходу система пропонує спрямувати частину в ціль. Прогрессбар з датою: якщо темп поповнень недостатній, показуємо попередження з розрахунком необхідного щомісячного внеску.
Прогноз витрат на основі історії — просте скользяче середнє за 3 місяці з поправкою на сезонність (грудень завжди аномальний). Реалізується на клієнті без ML — достатньо SQL-агрегації з GROUP BY month.
Регулярні операції
Регулярні платежі (підписки, аренда, кредити) — RecurringTransaction з полями amount, frequency (RRULE або enum), nextDueDate, categoryId. Фонова задача кожен день перевіряє nextDueDate <= today та створює операції автоматично. На iOS — BGProcessingTask, на Android — WorkManager з PeriodicWorkRequest(1, TimeUnit.DAYS).
Підводний камінь: daylight saving time. Якщо регулярна операція повинна створюватися «1-го числа кожного місяця», не можна просто зберігати інтервал у секундах — потрібен Calendar API з урахуванням локалі.
Сімейний бюджет
Кілька користувачів, один спільний бюджет. Це додає завдання: авторизація, ролі (власник/учасник), дозволи (хто може змінювати ліміти). Синк — обов'язковий, та конфлікти будуть: дві людини додали витрату одночасно. Firestore з трансакційними операціями (runTransaction) вирішує більшість race conditions.
Процес роботи
Визначаємо методологію бюджетування, цільову аудиторію (особистий / сімейний), потрібен ли синк та мульти-аккаунт, інтеграція з банками. Проектуємо accounting model — це найкритичніший етап. Розроблення, тестування сценаріїв з граничними випадками (місяць з 28 днями, перехід року, нульовий дохід).
Орієнтири за термінами
Особистий бюджет з конвертним методом та цілями накопичень — 6–9 тижнів. Сімейний з синком, ролями, регулярними операціями та прогнозуванням — 12–18 тижнів. Вартість розраховується індивідуально.
| Функція | Складність реалізації |
|---|---|
| Ручний ввід + категорії | Низька |
| Конвертний метод | Середня |
| Регулярні операції | Середня |
| Сімейний синк | Висока |
| ML-прогноз витрат | Висока |
| Інтеграція з банком | Висока |