Как создать мобильное приложение для заметок о расходах на ходу

Что вы создаёте и почему это важно

Приложение для «заметок о расходах на ходу» — это простой мобильный инструмент для фиксации трат в момент их совершения: на углу улицы, в такси, в очереди в аэропорту. Важна скорость: минимум ввода, пара тапов — и готово. Если приложение требует длинных форм или точного ввода, люди не будут им пользоваться, когда жизнь идёт слишком быстро.

Для кого это

Такое приложение особенно полезно фрилансерам, которые отслеживают деловые расходы; небольшим командам, которым нужны лёгкие записи для возмещения; и путешественникам с несколькими валютами и множеством чеков. Оно также помогает тем, кто к концу недели забывает, на что был расход в «$18.40».

Что вы построите (и какие решения примете) в этом руководстве

К концу статьи у вас будет чёткий план MVP приложения для заметок о расходах, который умеет:

• Захватывать быстрый расход (сумма, категория, короткая заметка)
• Прикреплять фото чека при наличии
• Надёжно работать оффлайн и синхронизироваться позже
• Экспортировать простые отчёты для выставления счетов, отчётов или возмещений

Вы также примете практические решения — что значит «быстрый захват» для ваших пользователей, какой подход к сканированию чеков вписывается в бюджет и как обеспечить приватность без лишнего трения.

MVP сначала, потом итерации

Цель — не построить полноценную бухгалтерскую систему. Начните с версии, которую люди могут использовать ежедневно, не задумываясь. Увидев реальные паттерны использования, вы добавите умные подсказки, лучшие отчёты и интеграции.

Это руководство сфокусировано: цель — выпустимый первый релиз без ненужной сложности.

Потребности пользователей и ключевые сценарии

Если приложение предназначено для заметок о расходах на ходу, основная потребность проста: зафиксировать расход в момент его совершения, даже если детали нечёткие. Люди не хотят «заниматься бухгалтерией» на кассе — им нужен быстрый и надёжный запис, которому можно доверять позже.

Ключевые задачи пользователя

Большинство пользователей выполняют три задачи:

• Захватить сейчас: сумма (или фото), продавец и краткая подсказка вроде «обед с клиентом».
• Уточнить позже: категория, разделение налога/чаевых, проект/клиент, способ оплаты.
• Отправить/экспортировать позже: отправить в бухгалтерию, на возмещение или в персональные инструменты бюджета.

Распространённые боли, которые нужно учесть

Проблемы со скоростью обычно рушат привычку отслеживать расходы:

• Потерянные чеки (бумага выцветает, выбрасывается или вообще не печатается).
• Забытые контексты (с кем был обед, к какому заданию относится расход).
• Медленные формы (слишком много обязательных полей, экранов, ввода).

Выберите основной сценарий

Выберите один «момент по умолчанию», который приложение будет делать лучше всего: кофе/такси/еды в движении — одна рука на телефоне, плохое освещение, мало времени, нестабильный сигнал. Этот сценарий должен определять решения для MVP (крупные кнопки, минимум ввода, грациозная работа оффлайн).

Метрики успеха, которые держат в тонусе

Определите измеримые результаты рано:

• Время на запись расхода: например, до 10–15 секунд для базовой записи.
• Процент завершённых записей: % захваченных элементов, доведённых до финального состояния в течение 48 часов.

Простые user stories

• «Как путешественник, я хочу сфотографировать чек и сразу сохранить, чтобы не потерять его до отеля.»
• «Как консультант, я хочу одним тапом добавить заметку «Проект Дельта», чтобы позже корректно отправить расходы.»
• «Как менеджер, я хочу чистый экспорт, чтобы возмещения не требовали переписок.»

Чек-лист функций MVP для заметок о расходах

Приложение успешно, когда фиксирует самое важное за секунды и не мешает дальше. Для MVP сфокусируйтесь на одном потоке «Добавить расход», который надёжно сохраняет запись и делает её легко доступной.

Обязательные поля (минимум, который всё ещё выглядит завершённым)

Начните с этих непреложных полей:

• Сумма (с поддержкой десятичных и явным отображением валюты)
• Продавец (кем был платёж)
• Категория (хотя бы небольшой стартовый набор)
• Дата (когда это произошло)
• Заметка (короткое описание, которое поможет позже)
• Фото (опционально, но поддерживаемое)

Опциональные поля (полезные, но не мешающие сохранению)

Добавляйте только то, что быстро вводится и очевидно полезно:

• Проект/клиент (для фрилансеров и команд)
• Способ оплаты (нал/карта/возмещаемый и т.д.)
• Теги (для гибкой группировки вроде «путешествие» или «налоги»)

Что можно автозаполнять

Автозаполнение снижает трение и повышает точность:

• Дата/время по умолчанию «сейчас», редактируемая
• Валюта по локали устройства; возможность ручной смены
• Местоположение только при явном согласии; MVP должен работать и без него

Определите, что такое «заметка»

Решите заранее: это свободный текст или вы также предлагаете шаблоны (например «Такси до аэропорта», «Обед с клиентом»)? Для MVP достаточно свободного текста. Позже можно добавить быстрые подсказки.

Объём MVP vs «потом»

MVP: создать расход, редактировать, список/поиск, базовые категории, прикрепление фото, простые итоги.

Потом: OCR-сканирование, умные подсказки по категориям, интеграции, конвертация валют, коллективная работа.

UX-поток для быстрого захвата в реальной жизни

Хорошее приложение для заметок о расходах ориентировано на момент, когда вы действительно тратите деньги: стоите у кассы, идёте на встречу или несёте сумки. Цель UX — зафиксировать пригодную запись за секунды с минимальным мышлением.

Начинайте с точки входа в один тап

Не заставляйте пользователей искать приложение. Предложите хотя бы один быстрый способ запуска:

• Виджет на экран блокировки или главный экран для «Новый расход»
• Быстрое действие приложения (long-press на иконку) для прямого перехода в ввод
• Системные шорткаты (голосовой шорткат или автоматизация) для частых пользователей

При открытии приложение должно попадать прямо на экран захвата, а не на дашборд.

Выберите шаблон ввода, соответствующий скорости

Два шаблона работают хорошо:

• Один экран: сумма, продавец, категория и заметка в одном месте. Подходит продвинутым пользователям и быстрым правкам.
• Шаг за шагом: сумма → категория → детали. Подходит, когда нужны крупные элементы ввода и минимум отвлечений.

Если вы выбираете шаги, держите их немного и разрешайте пропускать опциональные поля.

Сократите печатание с помощью дефолтов и подсказок

Упростите ввод, делая «правильный» вариант очевидным:

• Последний использованный способ оплаты и категория
• Валюта по умолчанию (с быстрым переключателем при поездках)
• Подсказки продавцов из истории

Используйте крупный числовой ввод для суммы, а текстовые поля делайте опциональными.

Поддерживайте «сохранить сейчас, отредактировать позже»

Жизнь бывает сумбурной. Позвольте пользователям нажать Сохранить, как только у них есть сумма (или хотя бы фото чека), а затем уточнять запись позже.

Практичный поток:

• Сохранить немедленно → показать лёгкое подтверждение
• Отправить в список «Без категории» или «Требует проверки»
• Позволить быстрые правки из списка без открытия полной формы

Базовая доступность, которая предотвращает трение

Быстрый захват проваливается, если по нему трудно попасть или его тяжело прочитать. Используйте большие зоны нажатия, понятные метки (не только иконки), высокий контраст и надёжную поддержку тёмной темы. Убедитесь, что основное действие (Сохранить) доступно одной рукой.

Фотографии чеков и варианты OCR

Захват чека — это то место, где приложение либо кажется бесшовным, либо раздражающим. Ваша цель — получить читаемое фото чека с минимальным трением, даже если пользователь стоит в очереди или идёт к такси.

Цели для съёмки камеры

Сделайте поток камеры таким, чтобы он «просто работал»:

• Автофокус и автоэкспозиция, настроенные под бумагу (часто глянцевую и помятую)
• Ясные подсказки кадрирования (границы) и мгновенная обратная связь вроде «Слишком темно» или «Подойдите ближе»
• Быстрая съёмка одной рукой: большая кнопка, тактильный отклик и быстрый повтор

Относитесь к сканированию как к опции. Пользователи должны уметь мгновенно сохранить фото и идти дальше, а извлечение данных пусть выполняется в фоне.

Варианты OCR: на устройстве vs на сервере

OCR на устройстве хорош для приватности, работы оффлайн и скорости (без загрузки). На слабых устройствах или при нетипичных форматах чеков результаты могут быть хуже.

Серверный OCR даёт более предсказуемые результаты и проще улучшается централизованно, но требует загрузки, сети и вызывает вопросы приватности/соответствия. Если вы выбираете этот путь, явно сообщайте, что загружается и как долго хранится.

Практичный подход — гибрид: сначала на устройстве, затем предлагать серверный OCR, когда есть сеть и пользователь дал согласие.

Что извлекать (и чего не стоит торопиться извлекать)

Начните с полей с высокой уверенностью, которые нужны для отчётов:

• Итоговая сумма
• Название продавца
• Дата
• Налог (опционально)
• Валюта (по символу и локали)

Построчные позиции можно отложить; они добавляют сложность и редко нужны для простых отчётов.

Когда OCR терпит неудачу: делайте правку быстрой

Всегда предоставляйте понятный экран ручного ввода с быстрыми правками: тап чтобы исправить сумму/дату, подсказки продавцов и опция «Отметить как нечитаемое».

Предотвращение дубликатов

Добавьте лёгкие проверки на дубликаты: предупреждение, когда новый чек похоже совпадает по сумме + временному окну + похожести продавца, и дайте пользователю подтвердить, а не блокировать операцию.

Оффлайн-режим, хранение и стратегия синхронизации

Приложение для заметок о расходах ощущается «на ходу» только если работает в метро, подвале клиента или на парковке. Рассматривайте оффлайн как поведение по умолчанию: пользователь должен иметь возможность добавить расход, прикрепить фото и идти дальше — при наличии или отсутствии сети.

Offline-first: записывайте локально, синхронизируйте потом

Когда пользователь нажимает Сохранить, сохраняйте расход сразу на устройстве. Не блокируйте сохранение сетевым вызовом. Это одно решение снимает основное разочарование и предотвращает потерю записей.

Для локального хранения подумайте о небольшом зашифрованном хранилище на телефоне (например, зашифрованная SQLite). Оно должно хранить:

• Поля расхода (сумма, валюта, дата, категория, заметки)
• Метаданные по чекам (имя файла, статус, метки времени)
• Очередь синхронизации (что нужно загрузить)

Правила синхронизации, которые не удивляют пользователей

Синхронизация — это место, где приложения ведут себя непредсказуемо. Выберите правило и сообщите о нём.

• Last-write-wins — самый простой вариант: самая свежая правка перезаписывает более старую. Обычно достаточно для заметок о расходах, потому что редко редактируют один и тот же элемент одновременно на двух устройствах.
• Если ожидается частое редактирование на нескольких устройствах (например, для общих аккаунтов), рассмотрите лёгкое слияние по полям: изменение категории на одном устройстве не должно стирать заметку, отредактированную на другом.

Решите также, что происходит, если элемент удалён на одном устройстве, а отредактирован на другом. Частый подход — «мягкое удаление» (отмечен как удалённый, синхронизирован, затем удалён окончательно).

Фоновые загрузки изображений чеков

Фотографии чеков большие и чаще всего первыми терпят неудачу. Сохраняйте изображения локально, затем загружайте в фоне при доступе в интернет (предпочтительно по Wi‑Fi, если пользователь не разрешил мобильную передачу). Загрузки должны быть возобновляемыми, чтобы плохое соединение не начинало всё заново.

Понятная обратная связь: очередь, синхронизация, ошибка

Дайте пользователям видимый и спокойный статус:

• В очереди (сохранено и ждёт)
• Синхронизируется…
• Ошибка с кнопкой Повторить и опцией «повторить всё»

Это превращает синхронизацию из тайны в предсказуемую часть опыта.

Выбор техстека без лишних раздумий

Отличное приложение можно построить разными инструментами. Цель — не выбрать «лучший» стек, а тот, который ваша команда сможет выпустить и поддерживать.

Платформа: iOS, Android или кроссплатформенно

Если ваша команда уже знает Swift/SwiftUI или Kotlin/Jetpack Compose, нативные приложения часто быстрее дают полированный и надёжный опыт захвата (камера, оффлайн-хранилище, шеринговые листы).

Если нужно покрыть обе платформы с небольшой командой, выберите одну кроссплатформенную опцию и придерживайтесь её:

• Flutter: хорошая производительность, единый UI, надёжные пакеты для камеры и оффлайна.
• React Native: быстрые итерации при знании web/JS, богатая экосистема.

Практичное правило для MVP: если у вас один мобильный инженер — выберите кроссплатформу; если есть выделенные iOS + Android — идите нативно.

Архитектура приложения: держите предсказуемо

Используйте простой, последовательный паттерн, чтобы фичи вроде «редактировать расход», «прикрепить чек» и «статус синхронизации» не превратились в клубок:

• MVVM (часто в нативе и Flutter) хорошо подходит для форм и состояния.
• Redux-подход (в React Native) удобен, когда оффлайн + синхронизация даёт много состояний.

Не переусердствуйте: чистое отделение UI, состояния и слоя данных обычно достаточно.

Бэкенд: только то, что действительно нужно

Многим MVP требуется четыре вещи:

1. Аутентификация (email, вход через Apple/Google)
2. База данных (расходы, категории, настройки)
3. Хранение файлов (фото чеков)
4. Поиск/экспорт (фильтрация и генерация CSV/PDF)

Управляемый бэкенд (Firebase, Supabase) сокращает время настройки. Собственный бэкенд (Node/Django/Rails) даёт больше контроля при ожидании сложной отчётности или строгого соответствия.

Если хотите быстро двигаться, не перестраивая всякую инфраструктуру, платформа вроде Koder.ai также может помочь на этапе прототипа: вы прототипируете основные потоки (список расходов, форма захвата, загрузка чеков, экраны экспорта) через чат‑ориентированный рабочий процесс, а затем экспортируете исходники, когда готовы взять поддержку на себя. Это удобно для MVP с React-дэшбордом и бэкендом Go + PostgreSQL, поддерживает режим планирования, снимки и откат.

Форма API (держите её простой)

Проектируйте эндпоинты вокруг основных сущностей:

• POST /expenses, PATCH /expenses/{id}
• POST /receipts (загрузка), привязка к расходу
• GET /expenses?from=\u0026to=\u0026category=
• POST /exports (возвращает ссылку на файл)

Компромисс между стоимостью и сложностью

Кроссплатформа экономит время разработки, но может потребовать усилий для краёв камеры/OCR. Управляемый бэкенд дешевле на старте, кастомный может быть экономичнее в долгосрочной перспективе при масштабе. Если сомневаетесь, стартуйте на управляемом и оставьте путь миграции позже (см. /blog/offline-sync-basics).

Безопасность, приватность и разрешения

Приложение быстро становится хранилищем личных и деловых данных. Рассматривайте безопасность и приватность как ключевые требования продукта, а не как «хорошо бы сделать потом».

Что считается чувствительными данными?

Даже без хранения банковских данных вы будете работать с информацией, раскрывающей привычки трат или деловую активность:

• Фото чеков (иногда частичные номера карт, адреса магазинов, налоговые номера)
• Названия продавцов, позиции и суммы
• Даты, метки времени и (при добавлении) геолокация
• Заметки вроде «обед с клиентом» или «поездка команды»

Базовые защиты, которых ожидают пользователи

Начните с простого и защищённого базиса:

• Шифрование в транзите: TLS для всех API-вызовов
• Шифрование на диске: шифруйте чувствительные данные на устройстве и в облаке там, где это возможно
• Принцип минимальных прав: храните изображения чеков и распарсенные данные в отдельных бакетах/коллекциях с жёсткими правилами доступа

Если используете сторонний OCR, ясно объясните, что загружается, как долго хранится и могут ли вендоры использовать данные для обучения моделей.

Разрешения: просите только когда нужно

Разрешения — момент доверия. Запрашивайте их при необходимости с простым объяснением:

• Камера: только при нажатии «Сканировать чек»
• Фото/медиатека: только при выборе «Загрузить из галереи»

Избегайте запроса локации по умолчанию; предлагайте опцию позже.

Доступ к аккаунту и блокировка приложения

Для большинства MVP достаточно email + magic link/OTP. Добавляйте SSO позже для рабочих клиентов.

Рассмотрите также опцию блокировки на устройстве (Face ID/Touch ID/PIN) для открытия приложения или просмотра чеков — особенно на общих устройствах.

Хранение и удаление как функции продукта

Сделайте элементы приватности видимыми:

• Экспортируй и затем удаляй: позволять скачивать отчёт и удалять данные
• «Удалить аккаунт», который действительно удаляет чеки, текст от OCR и бэкапы в понятные сроки
• Опции хранения по правилам (например, хранить чеки 90 дней или 7 лет)

Понятные настройки уменьшают обращения в поддержку и повышают доверие пользователей.

Категории, валюта и умные подсказки

Хорошая организация превращает кучу быстрых заметок в полезный отчёт. Для приложения это обычно значит: модель категорий, обращение с валютами и лёгкие подсказки, которые убирают рутину.

Простая модель категоризации (с возможностью роста)

Начните с короткого фиксированного списка, который знаком большинству (например: Питание, Транспорт, Проживание, Офис, Развлечения, Комиссии). Держите его под ~10–12, чтобы избежать перегруза выбора.

Добавьте пользовательские категории как запасной вариант. Две практические правила:

• Позвольте пользователям переименовывать/удалять свои категории
• Не допускайте дубликатов, отличающихся только регистром

Умные подсказки простыми правилами

Вам не нужен «AI», чтобы казаться умным. Постройте небольшой слой правил:

• Отслеживайте частых продавцов и предлагайте последнюю использованную категорию для них
• Предлагайте недавно использованные категории вверху селектора
• Если пользователь меняет категорию, спросите (один раз), «запомнить это для следующего раза?»

Это снижает время ввода без навязывания автоматизации.

Мультивалютность без усложнений

Храните оба значения:

• Оригинальная сумма + оригинальная валюта (как на чеке)
• Конвертированная сумма + базовая валюта (для отчётов)

Конвертацию можно делать по дневному курсу (достаточно для MVP). Показывайте курс и дату, чтобы итоговые суммы не казались странными.

Поля НДС/налога: только при необходимости

Если вы не нацелены на строгие бизнес-возмещения с самого начала, держите НДС опциональным: переключатель «Налог включён?» или поле «Налог» скрытое за «Добавить детали».

Поиск и фильтры, которые реально отвечают на вопросы

Сделайте лёгким ответ на «Сколько я потратил на X в прошлом месяце?». Поддерживайте фильтры по датам, категории, сумме и продавцу, а также простой текстовый поиск по заметкам и названию продавца.

Экспорт и простые отчёты по расходам

Захват расходов — лишь половина работы. В какой-то момент вам нужно что-то отдать в бухгалтерию, загрузить в портал возмещений или сохранить в архив. Экспорт — то место, где приложение становится практичным инструментом.

Форматы экспорта (сейчас vs позже)

Начните с форматов, которые легко генерировать и которые принимают повсеместно:

• CSV для таблиц и бухгалтерских инструментов (лучший «универсальный» вариант)
• PDF-сводка для чистого, только для чтения отчёта, который можно отправить по почте или загрузить

Если планируете интеграции с бухгалтерией позже, проектируйте модель экспорта так, чтобы можно было добавить интеграции без изменения хранения записей.

Простой поток «отчёт о расходах»

Сделайте процесс отчёта предсказуемым:

1. Выбрать период (текущий месяц, прошлый месяц, пользовательский диапазон)
2. Просмотреть (итоги по категориям, отсутствующие чеки, неразобранные элементы)
3. Экспорт/поделиться (сохранить в файл, отправить по почте, открыть шеринговый лист)

Добавьте опционный фильтр «проект/клиент», если приложение это поддерживает, но не делайте его обязательным.

Чеки: ссылки vs встроенные вложения

Решите, как чеки идут с отчётом:

• CSV + ссылки на чеки: включайте URL или локальную ссылку к каждой записи
• PDF с миниатюрами: удобнее для аудита, но больше размер файла

Вне зависимости от выбора, явно показывайте, когда чек отсутствует.

Конвенции имен файлов для порядка

Используйте последовательные имена, например:

• expenses_2025-01-01_to_2025-01-31_jordan.pdf
• expenses_2025-01_project-acme.csv

Поля для аудиторской готовности

Даже лёгкое приложение должно экспортировать:

• Время создания и время изменения
• Источник (вручную vs OCR)
• Валюта, категория, продавец (если есть), заметки

Эти детали сокращают переписку, когда кто-то спрашивает «Когда это было внесено и откуда взялось?»

Тестирование в реальных условиях

Приложение побеждает или проигрывает в хаотичных ситуациях: плохое освещение, отсутствие сигнала и одна свободная рука при ходьбе. Тестирование должно отражать реальность, а не только «happy path» демонстрации.

Функциональные тесты, которые необходимо покрыть

Начните с набора тестов, которые защищают основной поток (захват → сохранение → синхронизация → экспорт):

• Валидация формы: обязательные поля (сумма, дата), разумные пределы, отрицательные значения, формат валюты и обработка «неизвестного продавца»
• Оффлайн-очередь: создание/редактирование/удаление без сети и подтверждение локального хранения и отображения в UI
• Повторы синхронизации: симуляция обрывов сети во время синхронизации, проверка бэкоффа, разрешения конфликтов (один и тот же элемент отредактирован дважды) и статуса «последняя синхронизация»
• Fallback OCR: когда OCR не сработал, пользователь всё равно может сохранить вручную, а частичные результаты OCR очевидно редактируемы

Тесты на устройствах и в окружениях (то, что ломает камеру)

Проверьте вручную на нескольких реальных устройствах (не только на флагмане):

• Плохое освещение и блики на глянцевых чеках
• Дрожание камеры (хождение, одна рука) и задержки автофокуса
• Режим самолёта и зоны с низким сигналом (переключение Wi‑Fi ↔ мобильная сеть)
• Мало места на диске и условия с ограниченной памятью

Проверки производительности, которые ощущают пользователи

Измеряйте «ощущаемые» тайминги и держите их стабильными между сборками:

• Время запуска приложения до экрана захвата
• Время старта камеры и до первого чёткого кадра
• Время от тапa «Сохранить» до появления записи в списке (даже если синхронизация ещё идёт)

Отчёты об крашах и базовая аналитика

Настройте отчётность о сбоях рано, чтобы ловить специфичные для устройства баги. Добавьте лёгкое событие для ключевых шагов (открытие захвата, фото чека, успешный/неудачный OCR, успешная/неудачная синхронизация), избегайте логирования чувствительных текстов или полных изображений чеков.

Проведите небольшой бета‑тест с опросом

Пригласите 10–30 человек, которые реально путешествуют или подают расходы. Держите обратную связь структурированной:

• Когда в последний раз захват был медленным или непонятным?
• Доверяли ли они оффлайн-режиму?
• Как часто падал захват фото или OCR?
• Что они экспортировали и был ли отчёт пригоден?

Запуск, онбординг и план итераций

Плавный запуск — это не наличие всех функций, а умение доказать ценность за минуту: сохранить расход, прикрепить чек и найти его позже.

Чек-лист перед запуском (что выпустить)

Подготовьте метаданные магазинов и требования к соответствию заранее, чтобы не ускоряться на последнем этапе:

• Метаданные в сторе: понятный заголовок/подзаголовок, описание с ценностным предложением («Сохраняйте чеки и быстро формируйте отчёты»)
• Скриншоты: показывайте сначала поток захвата (сумма → категория → чек), затем оффлайн-режим, потом экспорт
• Детали приватности: объясняйте, что собираете (email, ID устройства, аналитика), что остаётся на устройстве и как обрабатываются фото чеков
• Базовая поддержка: короткое FAQ, контактный email и простая форма «сообщить о проблеме»

Онбординг (3–5 экранов, максимум)

Держите онбординг коротким и ориентированным на действие:

1. Покажите Быстрый захват (сумма, категория, опциональная заметка)
2. Запрашивайте только необходимые разрешения в момент использования (камера при «Добавить чек»)
3. Предложите пример расхода, который пользователь сможет отредактировать, затем предложите записать первый реальный

Модель монетизации

Выберите одну понятную модель:

• Бесплатный уровень: ручной ввод + ограниченные ежемесячные экспорты
• Подписка: неограниченные чеки/OCR и облачная синхронизация
• Командные планы: общие рабочие пространства, поток утверждений, админ‑контролы

(Если вы строите с Koder.ai, эти уровни естественно масштабируются: стартовое бесплатное MVP, затем Pro/Business для OCR, облачной синхронизации и командных рабочих пространств; Enterprise для требований соответствия и кастомных развёртываний.)

Метрики после релиза, которые действительно важны

Отслеживайте поведение, связанное с ценностью:

• Ретеншн: D1/D7/D30
• Логи расходов в неделю на активного пользователя
• Использование экспорта: сколько пользователей генерируют отчёт и как часто

Дорожная карта итераций

Используйте реальные данные для приоритезации:

• Шорткаты: виджеты, «повторить последний расход», быстрые чипсы для категорий
• Интеграции: бухгалтерские инструменты, пересылка по почте, общие диски
• Утверждения: отправить → проверить → возместить
• Автоматизация: умные подсказки по категориям, расчёт пробега, регулярные расходы.