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

Определяем цель и сценарии учета активов

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

Какие активы поддержать в первой версии

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

• Недвижимость (квартира, дом, участок)
• Авто и транспорт
• Счета и наличные (банковские счета, вклады)
• Инвестиции (портфель инвестиций: акции, облигации, фонды)
• Техника и ценное имущество (например, ноутбук, камера)
• Драгоценности и предметы коллекции (если есть спрос)

Ключевое решение: будете ли вы учитывать только «стоимость» или также обременения (например, ипотека/кредит). Если цель — именно активы, долги можно отложить или добавить позже отдельным модулем.

Базовые сценарии пользователя

Сформулируйте 3–4 главных сценария и стройте вокруг них всю первую версию:

1. Добавить актив за 30–60 секунд: тип → название → стоимость → валюта → категория.

2. Обновить стоимость: вручную (быстро) или через подсказки/источники (по желанию).

3. Увидеть итог: общая сумма и разрез по категориям (например, «недвижимость vs инвестиции»).

4. История изменений: хотя бы простая лента, чтобы понимать динамику.

Границы продукта и критерии успеха

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

Успех MVP приложения измеряйте так:

• Точность данных (нет путаницы с валютой, датами, категориями)
• Скорость ввода (минимум полей, автозаполнение где возможно)
• Понятные отчеты (итоги читаются за 5–10 секунд)

Выбираем функции: MVP и что оставить на позже

Правильный MVP — это версия, которую человек сможет открыть через неделю и уже понять: «теперь мои активы в порядке». Для приложения учета имущества и инвестиций это означает: минимум действий, максимум ясности.

Минимальный набор для старта (MVP)

Начните с ядра, без которого учет не работает:

• Список активов с понятными типами (наличные, банковские счета, недвижимость, авто, инвестиции, техника и т. п.).
• Стоимость и валюта для каждого актива. Важно: валюта — не «потом», иначе сумма портфеля сразу будет неточной.
• Заметки: короткое поле «что важно помнить» (например, где хранится документ, условия вклада, срок страховки).
• Файлы/фото: чек, ПТС, договор, скрин из брокера. Даже простое прикрепление 1–3 файлов к активу заметно повышает пользу.

MVP должен давать две базовые возможности: быстро добавить актив и быстро увидеть общую картину.

Полезные «плюшки», которые усиливают ценность

Когда базовые сценарии закрыты, добавляйте функции, которые повышают вовлеченность:

• Напоминания (продление страховки, срок вклада, техобслуживание).
• История изменений стоимости: «когда и почему поменялось».
• Теги и фильтры: «для работы», «семейное», «в аренде», «в залоге».

Отчеты, которые реально читают

Сделайте отчеты простыми и наглядными:

• Общая сумма активов (и отдельно по валютам, если нужно).
• Распределение по категориям: где сосредоточена основная стоимость.
• Динамика: рост/падение общей оценки по месяцам.

Что отложить на потом

Не перегружайте первую версию тем, что требует сложной логики и постоянной поддержки:

• Совместный доступ и роли (семья, бухгалтер, партнер).
• Продвинутая аналитика (сценарии, прогнозы, риск-профили).
• Интеграции с банками/брокерами/маркетплейсами и автоматический импорт.

Хорошее правило: если функция не помогает пользователю за 30 секунд понять «что у меня есть и сколько это стоит», ей не место в MVP.

Проектируем данные и структуру учета

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

Базовые сущности

Минимальный набор обычно выглядит так:

• Актив — то, что пользователь учитывает (квартира, авто, вклад, акции, техника).
• Категория — группировка активов (Недвижимость, Транспорт, Инвестиции, Драгоценности и т. п.).
• Оценка стоимости — запись о цене актива на конкретную дату.
• Документ — файлы и ссылки (чек, договор, гарантийный талон, фото серийника).
• Валюта — справочник валют и правила конвертации.

Важно: категория — это не «тип актива». Тип задает логику полей (например, для авто нужен пробег), а категория — удобство фильтров и отчетов.

Какие поля хранить в «Активе»

Чтобы покрыть большинство сценариев личных финансов, достаточно хранить:

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

Отдельно продумайте признак совместного владения и долю — это частый кейс для недвижимости и автомобилей.

История оценок: чтобы строить графики

Не перезаписывайте стоимость в одном поле. Делайте отдельную таблицу/коллекцию «Оценка стоимости»: asset_id + дата + сумма + валюта + источник + комментарий. Тогда вы:

• строите график динамики без костылей;
• понимаете «почему изменилась цена» (источник/заметка);
• можете пересчитать аналитику задним числом.

Хорошая практика — хранить последнюю оценку в активе как кеш для быстрого списка, но «истина» должна быть в истории.

Несколько валют и курсы: как не запутать пользователя

Выберите базовую валюту профиля (например, RUB) и показывайте итоги в ней. При этом:

• каждая оценка хранит свою валюту;
• конвертация делается по курсу на дату оценки (для истории) и по актуальному курсу (для «сегодня»);
• в интерфейсе явно подписывайте: «Оценка в USD, итог в RUB».

Так вы избегаете путаницы, когда пользователь видит скачки из‑за курса, и при этом получаете честную аналитику по портфелю инвестиций и имуществу.

Продумываем интерфейс и пользовательский путь

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

Принципы UX: как добавлять активы без усталости

Главное правило — минимум полей на первом шаге. Начните с 2–3 обязательных: название, категория (например, «Недвижимость», «Авто», «Инвестиции», «Техника») и примерная стоимость.

Дальше включаются «умные» помощники:

• Автозаполнение: подставляйте ранее использованные категории, валюту, тип владения.
• Умные подсказки: если человек выбирает «Авто», предложите поля «марка/модель/год»; если «Инвестиции» — «тикер/брокер/количество».
• Быстрые шаблоны: «Квартира», «Депозит», «Золото», «Ноутбук» — с уже подготовленными полями.

Важно: редкие поля (номер договора, серийный номер, документы) лучше прятать в блок «Дополнительно», чтобы не отпугнуть на старте.

Основные экраны: без сюрпризов и лишних кликов

Оптимальный набор экранов обычно такой:

1. Список активов — карточки с суммой, меткой категории, быстрым поиском и фильтрами.
2. Карточка актива — детали, история изменений стоимости, заметки, вложения (например, фото/файл документа), действия «редактировать/архивировать».
3. Добавление — пошаговая форма или один экран с умными полями.
4. Отчеты — структура по категориям, динамика, доли, валюта.
5. Настройки — безопасность, резервное копирование, валюты, источники оценок.

Онбординг: 3–5 шагов, чтобы объяснить ценность и безопасность

Сделайте короткий онбординг, который отвечает на вопросы «зачем?» и «насколько это безопасно?»:

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

Доступность: читаемо, понятно, без напряжения

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

Выбираем технологический подход без лишней сложности

Технологии легко «съедают» бюджет, если выбрать их раньше, чем понятны сценарии и MVP. Для приложения учета активов важнее надежность: быстро вводить данные, безопасно хранить, предсказуемо работать после обновлений.

Нативная разработка: две платформы — два набора работ

Нативно — это отдельные приложения для iOS и Android. Плюсы простые: максимальная скорость работы, лучший доступ к возможностям телефона (биометрия, фоновые задачи), более предсказуемое поведение интерфейса.

Минусы тоже понятны: фактически вы поддерживаете два продукта. Это дороже, требует двух специалистов/команд и усложняет синхронный выпуск новых функций.

Кроссплатформенная разработка: один код на две платформы

Кроссплатформа позволяет сделать iOS и Android из одной кодовой базы. Обычно это быстрее и дешевле в поддержке, особенно на этапе MVP: меньше повторяющейся работы, проще выпускать обновления.

Компромисс: иногда сложнее «дотянуть» идеальную плавность интерфейса, а некоторые системные функции требуют дополнительной настройки. Для учета активов (формы, таблицы, фильтры, графики) это чаще всего приемлемо.

PWA: веб-приложение, похожее на мобильное

PWA удобно, если нужно быстро проверить спрос: работает в браузере, обновляется моментально, один продукт для всех. Но у PWA есть ограничения по интеграции с устройством и оффлайн-возможностям, а также по «ощущению» полноценного приложения.

Один код или два приложения: как выбрать под команду и сроки

Выбор упирается в ресурсы:

• Если у вас один разработчик/небольшая команда и важна скорость MVP — чаще выигрывает кроссплатформа.
• Если продукт нацелен на премиальный опыт, сложные фичи устройства и высокий темп развития — натив может окупиться.
• Если вы валидируете идею и контент/логика важнее приложения — начните с PWA.

Оффлайн-режим: нужен ли и что от него требовать

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

План по версиям: сначала одна платформа, затем расширение

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

Как ускорить запуск без «классической» разработки

Если задача — быстро проверить гипотезу и собрать рабочий прототип, имеет смысл рассмотреть подход vibe-coding: вы описываете продукт и сценарии в чате, а платформа собирает интерфейсы и логику.

Например, TakProsto.AI позволяет делать веб, серверные и мобильные приложения из диалога, ускоряя путь от требований к работающему MVP. Для проектов про личные финансы важно, что платформа ориентирована на российский рынок: инфраструктура в России, локализованные и open-source LLM-модели, а также возможность выгрузки исходников, развертывания, хостинга, подключения домена, снапшотов и отката (rollback). Это удобно, когда вы хотите быстро пройти цикл «идея → MVP → обратная связь», не теряя контроля над кодом и данными.

Хранение данных, синхронизация и безопасность

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

Локальное хранение: максимум приватности, но нужен план «а если…»

Локальная база на устройстве (например, SQLite) удобна тем, что данные не уходят на сервер автоматически. Это снижает риски утечек и упрощает старт MVP.

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

Облачная синхронизация: удобство между устройствами и честный разговор о рисках

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

Риски — зависимость от сети и доверие к серверу. Их можно снизить и правильно «упаковать» в объяснение:

• показывайте, включена ли синхронизация и что именно синхронизируется (все данные или только часть);
• дайте переключатель «только локально»;
• опишите политику хранения кратко и по делу (например, ссылка на /privacy).

Шифрование: что шифровать и когда

Минимальный набор:

• на устройстве — шифровать базу/ключевые поля (названия активов, суммы, документы, заметки);
• при передаче — TLS для всех запросов;
• в облаке — шифрование на сервере, а для особо чувствительных данных — вариант end-to-end, если он вписывается в продукт.

Хорошая практика: ключи шифрования хранить в защищенном хранилище ОС и не «зашивать» их в приложение.

Авторизация: пароль/биометрия, сессии и восстановление

Для мобильного учета активов обычно достаточно:

• вход по PIN/паролю + биометрия как удобный метод разблокировки;
• авто-блокировка по таймеру;
• понятное восстановление доступа (код на почту/телефон), с предупреждением: при end-to-end часть данных может быть невозможно восстановить без ключа.

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

Обновление стоимости активов и источники оценок

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

Откуда брать стоимость: ручной ввод, шаблоны, напоминания

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

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

Источники оценки: документ, рынок, собственная оценка

Сделайте в карточке актива поле «Источник оценки» с вариантами:

• Чек/договор/выписка — подходит для покупки и официальной стоимости.
• Рыночная оценка — когда цена берется по объявлениям, каталогу, отчету оценщика.
• Собственная оценка — когда точных данных нет, но нужно ориентироваться.

Это повышает доверие к цифрам: пользователь видит не только «сколько», но и «почему так».

Частота обновления: разные правила для разных активов

Не задавайте единый интервал «раз в месяц». Лучше: настройка по типу актива (например, «каждые 6 месяцев» для недвижимости, «каждые 3 месяца» для авто, «по необходимости» для коллекций) и возможность отключить напоминания полностью.

Как помечать «оценка устарела» и не вводить в заблуждение

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

Отчеты, фильтры и полезная аналитика

Хорошая аналитика в приложении для учета активов не должна превращаться в «комбайн». Ее задача — быстро отвечать на бытовые вопросы: «Сколько у меня всего?», «Где это хранится?», «Что подорожало/подешевело?», «Что требует внимания?». Поэтому начните с простых инструментов поиска и понятных итогов, а сложные отчеты оставьте на потом.

Категории и теги: порядок вместо «свалки»

База активов быстро разрастается, если пользователь добавляет не только инвестиции, но и технику, авто, недвижимость, коллекции. Чтобы не получить хаос, разделите два уровня:

• Категории — фиксированный список верхнего уровня (например: «Недвижимость», «Транспорт», «Инвестиции», «Наличные», «Техника»).
• Теги — гибкие метки для уточнений («в аренде», «подарок», «на гарантии», «детям», «для работы»).

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

Фильтры: быстрые срезы без лишних экранов

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

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

Важно: фильтры должны запоминаться на время сессии и легко сбрасываться одной кнопкой.

Дашборд: итоги и диаграммы, которые не утомляют

Сделайте главный экран из 3–5 метрик: общая стоимость, распределение по категориям, топ-3 крупнейших актива, изменение стоимости за период (если есть обновления), напоминания/риски (например, «страховка скоро закончится»). Диаграммы — простые: круговая по категориям и столбики по динамике.

Экспорт и отчеты: PDF/CSV как опция

Экспорт полезен для личного архива, общения с финансовым консультантом или «на всякий случай». В MVP достаточно CSV (универсально), а PDF можно добавить позже как красивый отчет. Продумайте, чтобы экспорт учитывал активные фильтры — пользователь часто хочет выгрузить не всё, а конкретный срез.

Качество данных и тестирование сценариев

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

Типичные ошибки, которые стоит поймать заранее

Чаще всего проблемы возникают не из-за сложных багов, а из-за бытовых ситуаций:

• Дубликаты активов: один и тот же объект добавлен дважды (например, «Toyota Camry» и «Моя машина»).
• Разные валюты: актив в EUR, а общая сумма считается как будто в RUB.
• Неверные даты: дата покупки в будущем, перепутаны день и месяц, пропущена дата оценки.

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

Валидация и подсказки: простая страховка

Валидация должна быть заметной, но не раздражающей:

• Обязательные поля: название актива, валюта, текущая стоимость (или цена покупки — если так устроен сценарий).
• Диапазоны значений: стоимость не может быть отрицательной; для дат — разумные пределы (например, не раньше 1900 года и не позже сегодняшнего дня).
• Подсказки: примеры формата («10 500»), пояснение, что будет считаться «стоимостью» (рыночная, покупка, оценка вручную).

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

Тестовые данные и сценарии, которые имитируют реальную жизнь

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

• «Добавить 50 активов» (проверка скорости, поиска, фильтров, дублей).
• «Изменить валюту» (проверка пересчета итогов и корректности округления).
• «Восстановить из бэкапа» (проверка целостности: даты, категории, вложенные поля, история оценок).

Метрики качества: что измерять

Качество данных удобно переводить в метрики:

• Скорость добавления: сколько времени занимает внесение одного актива.
• Частота ошибок: доля попыток сохранения с ошибками валидации.
• Удержание: возвращаются ли пользователи к ведению учета через 7/30 дней.

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

Монетизация и упаковка продукта

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

Модели монетизации: что выбрать

Самый понятный вариант — бесплатная база + платные функции. Бесплатно пользователь ведет учет имущества, добавляет категории, видит базовую сводку. Платно — то, что требует инфраструктуры или дает «уровень профи».

Если у вас регулярные затраты (сервера, синхронизация, поддержка), логична подписка. Если продукт автономный и не требует постоянных расходов, возможна разовая покупка (например, Pro-версия). Иногда работает гибрид: разовая покупка за «премиум без облака» + подписка за облачные функции.

Что монетизировать честно (и почему это работает)

Хороший принцип: платными делать не базовую возможность учета, а усилители.

• Синхронизация между устройствами и доступ с нескольких устройств.
• Экспорт (CSV, Excel, PDF), автоматические отчеты для бухгалтерии/семьи, выгрузка для страховой.
• Расширенная аналитика: динамика стоимости, структура портфеля инвестиций, сценарии «что если», теги, умные фильтры, цели.
• Резервное копирование, история изменений, восстановление данных.

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

Прозрачность без темных паттернов

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

Хорошая практика:

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

Упаковка: что показать на /pricing и в магазине приложений

На странице /pricing лучше всего работают три блока: «Бесплатно», «Pro», «Pro с синхронизацией» (если нужно). Для каждого — 5–7 конкретных пунктов на языке выгод: «экспорт в Excel», «резервные копии», «расширенные отчеты по активам», «синхронизация между устройствами».

В магазине приложений сделайте акцент на простых сценариях и доверии: короткое описание, 3–5 скриншотов с ключевыми экранами (учет активов, оценка стоимости активов, отчеты), отдельный скрин о приватности и резервном копировании. Чем точнее вы «упакуете» ценность трекера активов, тем проще пользователю принять решение об оплате.

Запуск, поддержка и план развития

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

Подготовка к релизу

Минимальный набор для публикации:

• Политика конфиденциальности: что собираете (или не собираете), где храните, как удаляются данные, как связаться по вопросам.
• Описание в сторе: 3–5 ключевых преимуществ без технических деталей, кому подходит приложение.
• Скриншоты: показывайте не экраны, а задачи: «Добавить актив», «Посмотреть структуру», «Обновить стоимость», «Экспорт».
• FAQ в приложении и на лендинге: «Как перенести на новый телефон?», «Что будет при смене валюты?», «Как восстановить доступ?», «Как удалить аккаунт/данные?»

Поддержка и сбор обратной связи

Сделайте обратную связь частью продукта: короткая форма «Сообщить проблему/идею», возможность приложить скрин и логи (с согласием), статус обращения.

Для интервью с пользователями полезен небольшой список вопросов:

• Зачем вы ведете учет активов и как часто?
• Какие активы добавляете в первую очередь?
• Где «застреваете» в процессе добавления и оценки?
• Какие отчеты реально используете, а какие игнорируете?
• Чего не хватает, чтобы доверять данным?

План развития: что делать после MVP

Чтобы не распыляться, держите дорожную карту из 3–6 крупных улучшений:

• Совместный доступ (семья/партнер) с ролями и правами.
• Автоматические источники оценок там, где это уместно, плюс ручная корректировка.
• Расширенные отчеты: динамика, цели, сравнение периодов, заметки к изменениям.

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