Разработка мобильного приложения для планирования бюджета
Бюджетирование отличается от простого учёта расходов тем, что здесь важна не только история, но и прогноз. Пользователь смотрит вперёд: сколько можно потратить до конца месяца, хватит ли на отпуск, когда выплатить кредит. Это меняет и архитектуру данных, и логику расчётов.
Модели бюджетирования: выбор определяет архитектуру
Три основные методологии, и под каждую нужна своя модель данных:
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.
Recurring transactions
Регулярные платежи (подписки, аренда, кредиты) — RecurringTransaction с полями amount, frequency (RRULE или enum), nextDueDate, categoryId. Фоновая задача каждый день проверяет nextDueDate <= today и создаёт транзакции автоматически. На iOS — BGProcessingTask, на Android — WorkManager с PeriodicWorkRequest(1, TimeUnit.DAYS).
Подводный камень: daylight saving time. Если recurring транзакция должна создаваться «1-го числа каждого месяца», нельзя хранить просто интервал в секундах — нужен Calendar API с учётом локали.
Семейный бюджет
Несколько пользователей, один общий бюджет. Это добавляет задачи: авторизация, роли (владелец/участник), разрешения (кто может менять лимиты). Sync — обязателен, и конфликты будут: два человека добавили расход одновременно. Firestore с транзакционными операциями (runTransaction) решает большинство race conditions.
Процесс работы
Определяем методологию бюджетирования, целевую аудиторию (личный / семейный), нужен ли sync и мульти-аккаунт, интеграция с банками. Проектируем accounting model — это самый критичный этап. Разработка, тестирование сценариев с граничными случаями (месяц с 28 днями, переход года, нулевой доход).
Ориентиры по срокам
Личный бюджет с конвертным методом и целями накоплений — 6–9 недель. Семейный с sync, ролями, recurring и прогнозированием — 12–18 недель. Стоимость рассчитывается индивидуально.
| Функция | Сложность реализации |
|---|---|
| Ручной ввод + категории | Низкая |
| Envelope budgeting | Средняя |
| Recurring transactions | Средняя |
| Семейный sync | Высокая |
| ML-прогноз расходов | Высокая |
| Интеграция с банком | Высокая |