Разработка мобильного приложения для планирования бюджета
Отметим: когда пользователь открывает бюджетное приложение, он ожидает не просто историю «сколько потратил вчера». Ему важно понять: «Смогу ли я купить квартиру через 3 года?», «Не превышу ли лимит до зарплаты?». Это меняет архитектуру: вместо простого учёта транзакций нужна модель бюджетирования с прогнозами, целями и правилами. Мы специализируемся на таких проектах — за годы работы запустили 8 финансовых приложений, средний рейтинг в сторах 4.7. Архитектура должна поддерживать гибкую модель учёта, прогнозирование и синхронизацию между устройствами.
Какую методологию бюджетирования выбрать?
Три основные схемы, и под каждую — своя модель данных:
Envelope budgeting (конвертный метод). Каждая категория — «конверт» с выделенной суммой на месяц. Потратил — конверт уменьшается. Перерасход можно покрыть из другого конверта. YNAB работает именно так. Технически: сущность Envelope с allocated, spent, available. Транзакция уменьшает available в конверте, а не просто записывается в историю. Подробнее о методе на Wikipedia.
Zero-based budgeting. Каждый рубль дохода должен быть назначен в категорию. income - sum(allocations) = 0. Требует активного распределения в начале месяца — подходит для дисциплинированных, но отпугивает casual-пользователей.
Percentage-based (50/30/20). Автоматическое деление: 50% — нужды, 30% — желания, 20% — накопления. Реализуется как rules-engine поверх транзакций с автокатегоризацией. Меньше действий — выше retention.
Важно заложить поддержку нескольких методологий или хотя бы чётко определить одну на старте — переделка модели данных обнулит месяц работы. По нашему опыту, конвертный метод даёт на 30% больше активных пользователей за счёт наглядности — это лучший старт для удержания аудитории.
Прогнозирование и цели накоплений
«Накопить 150 000 на отпуск к августу» — это SavingsGoal с targetAmount, targetDate, currentAmount. При добавлении дохода система предлагает направить часть в цель. Прогрессбар с датой: если темп пополнений недостаточен, отображаем предупреждение с расчётом необходимого ежемесячного взноса.
Прогноз расходов на основе истории — простая скользящая средняя за 3 месяца с поправкой на сезонность (декабрь всегда аномальный). Реализуется на клиенте без ML — достаточно SQL-агрегации с GROUP BY month. Для точности используем взвешенное среднее с коэффициентом 0.6 для последнего месяца.
Recurring transactions
Регулярные платежи (подписки, аренда, кредиты) — RecurringTransaction с полями amount, frequency (RRULE или enum), nextDueDate, categoryId. Фоновая задача каждый день проверяет nextDueDate <= today и создаёт транзакции автоматически. На iOS — BGProcessingTask, на Android — WorkManager с PeriodicWorkRequest(1, TimeUnit.DAYS). Подробнее о WorkManager — в официальной документации.
Подводный камень: daylight saving time. Если recurring транзакция должна создаваться «1-го числа каждого месяца», нельзя хранить просто интервал в секундах — нужен Calendar API с учётом локали. Ошибка здесь приводит к дубликатам или пропускам, что подрывает доверие.
Сравнение платформ для реализации recurring transactions
| Платформа | Фреймворк | Подход к фоновым задачам | Время на реализацию |
|---|---|---|---|
| iOS | SwiftUI + Combine | BGProcessingTask | 2-3 дня |
| Android | Kotlin + Coroutines | WorkManager с PeriodicWorkRequest | 2-4 дня |
Что входит в нашу работу (deliverables)
- Проектирование accounting model — выбор методологии, ER-диаграммы, описание граничных случаев (месяц с 28 днями, переход года, нулевой доход).
- Дизайн и прототипирование — Figma с состояниями загрузки, ошибок, пустых списков.
- Разработка — Swift/SwiftUI (iOS), Kotlin/Jetpack Compose (Android), Flutter/Dart (cross-platform).
- Интеграции — App Store Connect, Google Play Console, TestFlight, Firebase, аналитика (Amplitude/Mixpanel).
- Тестирование — unit-тесты (XCTest, JUnit), UI-тесты (XCUITest, Espresso), нагрузочное тестирование sync.
- Документация — архитектурная схема, API-спецификация (OpenAPI), инструкция по поддержке.
- Гарантия — 12 месяцев бесплатных исправлений багов, SLA до 4 часов на критические ошибки.YNAB рекомендует подобный подход для удержания пользователей.
Почему стоит доверить разработку нам?
Мы не просто пишем код — мы строим финансовые системы. Наш опыт включает интеграцию с банками через OpenAPI, реализацию StoreKit 2 и Billing 6 для подписок, сертификацию по App Store Review Guidelines (раздел 5.1 — конфиденциальность). За годы присутствия на рынке мы выпустили 8 приложений в категории «Финансы» с минимальным оттоком пользователей (Churn < 5% после 3 месяцев). Каждый проект сопровождается документацией и обучением команды клиента.
Процесс работы
- Аналитика — интервью с пользователями, конкурентный анализ, определение методологии.
- Проектирование — модель данных, прототип, user stories.
- Разработка — спринты по 2 недели, код-ревью, CI/CD.
- Тестирование — ручное + автоматическое, бета-тест через TestFlight / Firebase Distribution.
- Деплой — публикация в сторах, настройка мониторинга (Crashlytics, Sentry).
- Поддержка — гарантийное обслуживание, доработки по запросу.
Ориентиры по срокам
| Функция | Сложность реализации | Типичные сроки (недель) |
|---|---|---|
| Ручной ввод + категории | Низкая | 2–4 |
| Envelope budgeting | Средняя | 3–5 |
| Recurring transactions | Средняя | 2–4 |
| Семейный sync | Высокая | 5–8 |
| ML-прогноз расходов | Высокая | 6–10 |
| Интеграция с банком | Высокая | 8–12 |
Стоимость рассчитывается индивидуально — зависит от состава команды, сложности интеграций и дизайна. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение с понедельным планом за 2 рабочих дня. Закажите разработку — получите консультацию инженера по архитектуре вашего будущего приложения.