Короткий ответ: бизнес-план мобильного приложения нужен не ради красивого документа, а ради проверки экономики. До разработки стоит понять, сколько будет стоить запуск, как вы получите первых пользователей, где упрётся воронка, сколько останется активной аудитории и при каких цифрах проект вообще имеет смысл. Если этого не сделать заранее, продукт легко выглядит убедительно на слайдах и убыточно в реальности.
Хороший план отвечает на жёсткие вопросы: для кого вы делаете приложение, какой сценарий монетизации выдержит рынок, сколько денег уйдёт на разработку и продвижение, и что произойдёт, если базовый прогноз не сработает. Именно поэтому здесь важны не общие слова, а расчётная логика, ограничения и запас прочности. Если вам нужен не рекламный текст, а рабочая модель, ниже разобран именно такой формат.
Для поиска баланса между идеей и расчётом полезно держать рядом и продуктовые, и финансовые материалы кластера: сначала сверить саму концепцию через Идеи для приложений. Затем проверить сценарии через Прототип приложения а уже после этого сводить бюджет и сроки. Такой порядок снижает риск, когда план красивее, чем сам проект.
Сильный бизнес-план мобильного приложения, это не описание компании в вакууме, а проверка того, выдержит ли идея запуск, первые оплаты и рост. Для этого нужно заранее собрать данные, посчитать пользовательскую воронку и сравнить несколько сценариев, а не опираться на одну «среднюю» цифру.
Для чего именно нужен бизнес-план: инвестор, грант или запуск своими силами
Ошибка начинается там, где один и тот же документ пытаются показать всем подряд. Инвестор смотрит на масштаб и возврат капитала, грант — на эффект и реализуемость, а внутренняя команда, на бюджет, сроки и уровень риска. Если эти задачи не развести, текст начинает противоречить сам себе: в одном месте он обещает быстрый рост, в другом — осторожный пилот, а в третьем требует слишком много денег на старте.
| Сценарий | Что должно быть главным | Что проверяют жёстче всего | Что можно сделать короче |
|---|---|---|---|
| Инвестор | Рост, масштаб, возврат капитала, доля рынка | Логика выручки и точка окупаемости | Операционные детали без влияния на деньги |
| Грант | Общественная, прикладная или технологическая польза | Измеримый результат и реальность исполнения | Длинный блок про капитализацию |
| Внутренний запуск | Бюджет, сроки, команда, предел потерь | Сколько нужно до первой проверки спроса | Историю бренда и декларации миссии |
Если проект нужен только для согласования внутри компании, не стоит раздувать его до 30–40 страниц. Часто достаточно короткой финмодели, календаря этапов и списка допущений. Для инвестора, наоборот, короткий текст без расчёта выглядит как попытка спрятать слабые места: он не видит, где проект начинает зарабатывать и при какой нагрузке ломается экономика.
Полезная проверка перед стартом простая: ответьте, что именно вы доказываете этим документом. Если ответ звучит как «что идея хорошая», формат слабый. Если ответ, «что проект можно запустить в таком-то бюджете, привлечь таких-то пользователей и выйти на такую-то экономику», вы уже в нужной зоне.
Какие данные собрать до начала расчётов
Сначала собирают не текст, а входные числа. Нужны тип приложения, источник трафика, схема монетизации, прогноз установок, доля активных пользователей, цена привлечения, частота платежей и срок, в течение которого человек остаётся в продукте. Без этих данных бизнес-план превращается в красивую догадку.
Если хочешь обсудить именно ваш сценарий и понять, что подходит — запланируй 30-минутный звонок — без обязательств.
Если хотя бы половины входных параметров нет, не пытайтесь подставить «среднюю температуру». Лучше сразу зафиксировать диапазоны и отдельным блоком показать, откуда они берутся: из тестового трафика, похожих проектов, отраслевых бенчмарков или пилотной проверки. Такой подход честнее и для инвестора, и для команды.
Особенно важно заранее посмотреть, как устроена Стоимость разработки приложения потому что на раннем этапе обычно недооценивают не только саму сборку продукта, но и аналитику, публикацию, поддержку и продвижение. Ошибка в этом месте быстро съедает запас по бюджету: проект выглядит подъёмным на словах и слишком дорогим, когда приходит время платить подрядчикам.
Для технической части полезно заранее решить, что именно вы строите: MVP, полноценный сервис или продукт, который должен сразу выдерживать рост. От этого зависит не только смета, но и глубина расчёта. Если вы сравниваете платформы, держите рядом материал о кроссплатформенной разработке мобильных приложений, а при сложных сценариях, и про Нативное приложение потому что технология меняет и срок запуска, и стоимость поддержки.
Ещё один входной параметр, который часто забывают,. Юридические и операционные ограничения. Если приложение работает с персональными данными, принимает платежи, хранит историю действий или зависит от внешних интеграций, это влияет и на сроки, и на архитектуру, и на итоговый бюджет. Игнорировать такие вещи опасно: план получается красивым только до первого юридического или технического вопроса.
Как устроена экономика мобильного приложения
У приложения нет классической воронки продаж в одном действии. Обычно деньги приходят цепочкой: установка, активация, регулярное использование, платёж или показ рекламы, затем удержание. Если на одном из этапов провал, финальные цифры в бизнес-плане уже не спасают.
На практике проект ломается не «в целом», а в одной конкретной точке. Например, платный трафик есть, но до первого ключевого действия доходит слишком мало людей; или пользователи активируются, но не остаются в продукте; или аудитория остаётся, но не даёт достаточной выручки. Поэтому считать приложение нужно через поведение пользователей, а не только через абстрактные продажи.
От установки к активному пользователю
Первая связка, сколько установок превращается в реальное использование. Здесь нельзя брать цифру «на глаз»: для разных типов приложений коэффициенты сильно отличаются. Сервис доставки, медиа-продукт и образовательная платформа живут по разной логике, и переносить модель из одной ниши в другую опасно.
Полезнее работать диапазонами. Например, 1 000 установок, 25–40% активации, 8–18% ежемесячно активной аудитории. Уже на этом уровне видно, выдерживает ли проект маркетинговую нагрузку и не сгорает ли бюджет раньше, чем появится выручка. Если цифры держатся только в верхней границе диапазона, модель надо считать как слабую, а не как «перспективную».
Хороший вопрос для этой стадии: что должен сделать пользователь в первые минуты, чтобы остаться? Если ответ не очевиден, проблема не в расчёте, а в продукте. Тогда сначала нужен прототип приложения, а уже потом — финальная модель.
От активного пользователя к выручке
Дальше считается, сколько денег приносит один активный пользователь. Это может быть подписка, комиссия, реклама, платные функции, транзакции или смешанная модель. Для инвестора важен не сам способ, а то, насколько он повторяемый и предсказуемый.
Если выручка зависит от случайных всплесков, модель хрупкая. Если один пользователь даёт небольшой, но стабильный доход, продукт легче масштабировать и проще защищать перед инвестором. Поэтому в расчётах стоит показывать не только ARPU, но и долю платящих, частоту платежа, срок жизни пользователя и отток по месяцам.
На этой стадии часто вскрывается неприятная вещь: продукт нравится пользователям, но платить за него они не готовы. В таком случае проблема не в маркетинге, а в самой схеме монетизации. Иногда проще сменить логику дохода, чем до бесконечности подгонять цифры под неудобную модель.
Какие показатели обязательно закладывать
Нельзя брать на глаз цену привлечения, конверсию в активацию, долю платящих и срок удержания. Любой из этих параметров способен сильнее изменить итог, чем любые косметические правки в презентации. Именно поэтому бизнес-план без сценариев, это скорее сценарий самоуспокоения, чем расчёт.
Минимальный набор показателей для рабочей модели: стоимость установки, доля пользователей, дошедших до первого ключевого действия, доля активной аудитории, средняя выручка на пользователя, срок удержания, расходы на поддержку и бюджет на повторный рост. Этого достаточно, чтобы увидеть, проект живёт сам или требует постоянного дофинансирования.
В условиях российского рынка к этой логике добавляется ещё одна поправка: внешняя среда менее стабильна, чем несколько лет назад, а значит допущения по трафику и каналам роста надо фиксировать жёстче. Если исходные параметры размыты, лучше честно записать это как риск, а не подменять «план» оптимизмом.
| Этап | Что считать | Какой риск видно | На что смотреть прежде всего |
|---|---|---|---|
| Установка | Стоимость привлечения, источник трафика | Слишком дорогой вход | Цена за установку |
| Активация | Процент дошедших до первого действия | Слабый онбординг или плохой первый экран | Конверсия в активность |
| Монетизация | ARPU, доля платящих, частота платежей | Слабая модель дохода | Доход на пользователя |
| Удержание | Сколько недель или месяцев человек остаётся активным | Быстрый отток и потеря LTV | Срок жизни пользователя |
Если вы уже выбираете технологический путь, экономика должна учитывать и его. Иногда Гибридная разработка даёт лучший старт по бюджету и скорости, но проигрывает там, где критичны производительность, сложные сценарии или глубокая работа с возможностями платформы. В таком случае дешевле на старте не всегда значит дешевле по жизненному циклу.
Структура бизнес-плана мобильного приложения без лишнего шума
Сильный документ не обязан быть длинным. Он обязан быть полным по смыслу. Для мобильного приложения это особенно важно: длинное описание компании почти никогда не помогает, а вот чёткая логика продукта, рынка, денег и рисков делает план читаемым и проверяемым.
Если смотреть на документ как на рабочий инструмент, а не как на формальность, в нём остаются только те разделы, которые помогают принять решение. Всё остальное, фон. Ниже, каркас, который можно адаптировать под инвестора, грант или внутреннее согласование без лишнего расширения.
Резюме: одна страница, которая должна выдержать первый скепсис
Резюме должно отвечать на три вопроса: что это за продукт, для кого он и почему запуск оправдан. Читатель должен понять это за один проход, без таблиц на пять экранов и без длинной предыстории.
Хорошее резюме не пересказывает весь документ, а даёт решение на входе. Если после него непонятно, зачем проекту деньги и в какой модели он окупается, значит первая страница не работает.
Продукт и проблема: что именно вы закрываете
Здесь важно описывать не приложение как объект, а проблему, которую оно снимает. Чем точнее сформулирована боль, тем легче потом обосновать спрос, частоту использования и выбор канала монетизации. Общие формулировки вроде «удобный сервис для всех» для расчётного документа не годятся.
Полезный тест простой: если убрать описание функции, останется ли понятна причина, по которой люди вообще будут возвращаться в продукт? Если нет, у вас либо слабое позиционирование, либо слишком широкий замах на старте.
Рынок и конкуренты: не «рынок растёт», а что именно вы проверяете
Этот блок часто превращают в общий обзор. Гораздо полезнее показать, какие параметры вы реально сравниваете: цена входа, модель дохода, удержание, степень зависимости от платного трафика, качество онбординга, наличие сильного бренда и барьеры переключения.
Если вы не можете объяснить, чем новый продукт лучше уже существующих решений, то бизнес-план начинает спорить сам с собой. В этом случае рынок и конкуренты — не декоративный раздел, а проверка, есть ли у идеи место для роста.
Монетизация: где именно появятся деньги
Выручку стоит разделять по каналам, а не смешивать в один поток. Подписка, комиссия, реклама, платные модули и транзакции живут по разным законам, и для каждого из них нужен свой прогноз. Иначе модель выглядит аккуратно, но ничего не объясняет.
Если монетизация зависит от действий пользователя, надо заранее показать, сколько людей платят, когда они платят и что происходит с доходом при падении удержания. Для приложения это часто важнее, чем красивая формулировка бизнес-модели.
Бюджет и сроки: считать нужно по фазам, а не одной строкой
Самая частая ошибка — записать один общий бюджет на разработку и успокоиться. В реальности деньги уходят поэтапно: аналитика и проектирование, дизайн, разработка, тестирование, релиз, первые кампании привлечения, поддержка и исправления. Если всё слить в одну сумму, вы теряете управление сроками и кассовыми разрывами.
Поэтому в документе лучше показывать не только итоговый бюджет, но и момент, когда именно он расходуется. Один и тот же проект может выглядеть безопасно в годовом плане и тяжело. В первом квартале, когда ещё нет стабильного потока пользователей.
Риски: где проект обычно ломается
У мобильных приложений почти всегда одни и те же уязвимые места: трафик обходится дороже, чем планировалось; люди хуже проходят активацию; удержание падает после первого месяца; поддержка и обновления съедают маржу. Если хотя бы два из этих пунктов проседают одновременно, продукт может выглядеть хорошим на презентации и быть слабым в кассе.
Хороший бизнес-план не прячет этот риск, а показывает его в цифрах. Это особенно важно для инвестора: он хочет видеть не обещание успеха, а понимание, где именно придётся тратить деньги и как быстро проект перестанет быть управляемым, если один из ключевых параметров поедет вниз.
Как считать расходы на приложение по фазам проекта
Расходы нужно делить не только по типам, но и по этапам. На старте вы тратите одни деньги, на запуске — другие, а после релиза начинается отдельная статья поддержки. Если всё сложить в один бюджет, из модели исчезает управляемость, а вместе с ней и доверие к расчёту.
Для бизнеса важен не только итоговый чек, но и момент, когда именно он возникает. Проект может выглядеть подъёмным по годовому бюджету и одновременно создавать кассовую яму в первые месяцы. Именно поэтому план должен показывать не только сумму, но и график расходов.
Разработка
Сюда входят аналитика, проектирование, дизайн, программирование, тестирование и подготовка релиза. Если продукт сложный, добавляются серверная часть, интеграции, инфраструктура и настройка окружений. На этом этапе чаще всего недооценивают объём правок после первых тестов.
Если в проекте есть несколько платформ или нестандартные сценарии, бюджет лучше считать с запасом. В противном случае формально «дешёвый» запуск оборачивается дополнительными итерациями и растянутыми сроками.
Запуск
Запуск, это не нулевая статья. После релиза нужно публиковать продукт в магазинах, настраивать аналитику, запускать первые кампании, проверять каналы трафика и собирать обратную связь. Именно в этот момент становится видно, способен ли продукт вообще получать пользователей, а не только проходить внутреннюю приёмку.
Если запуск недофинансирован, приложение может выйти в магазин, но не получить шанса на тест спроса. Тогда проблема не в идее и не в коде, а в том, что старт срезали раньше, чем он успел начаться.
Поддержка
После релиза расходы не заканчиваются. Появляются исправления, обновления, работа с отзывами, адаптация под новые версии ОС и доработка интерфейса. Если это не заложить сразу, финансовая модель быстро становится декоративной: на бумаге всё сходится, а в жизни продукт требует денег каждый месяц.
Поддержку особенно легко забыть в раннем бизнес-плане, потому что она не выглядит «запуском». Но именно она часто съедает маржу у проектов, которые хорошо стартовали и плохо были спланированы на горизонте года.
Маркетинг
Маркетинг для мобильного приложения почти всегда стоит считать отдельно от разработки. Это не только реклама, но и ASO, контент, партнёрства, ретаргетинг, тестирование каналов и повторные запусковые волны. Без стабильного потока установок выручка остаётся случайной.
Здесь особенно опасно закладывать слишком маленький бюджет «на проверку». Если продукту нужен платный трафик, но денег хватило только на короткий тест, вы не узнаете ничего о масштабе. Зато быстро узнаете, что проект не удерживает себя сам.
| Фаза | Основные статьи | Что обычно забывают | Риск недооценки |
|---|---|---|---|
| Разработка | Аналитика, дизайн, код, тестирование | Интеграции, правки, подготовка релиза | Срыв сроков и рост сметы |
| Запуск | Публикация, аналитика, первые кампании | Креативы, тексты, настройка событий | Слабый старт и дорогой трафик |
| Поддержка | Исправления, обновления, техподдержка | Реакция на версии ОС и отзывы | Падение рейтинга и отток |
| Маркетинг | Реклама, ASO, контент, партнёрства | Тестирование каналов и повторные запуски | Нет стабильного потока пользователей |
Если вам нужен не общий ориентир, а понимание диапазонов по типам проектов, полезно отдельно открыть материал Сколько стоит разработка приложения 2025 – обзор и цены. Он помогает не путать расчёт бюджета с очень грубой оценкой «на глаз».
Как проверить, что модель жизнеспособна
Сильная модель не обещает один правильный результат. Она показывает, что будет при разных сценариях. Именно это отличает рабочий бизнес-план от аккуратной версии идеи: у хорошего плана есть не только цель, но и пределы, в которых он ещё держится.
Если проект живёт только в оптимистичном сценарии, у него почти нет запаса прочности. Если он не сходится даже в базовом расчёте, его надо не дописывать, а пересматривать. Такой подход экономит время и деньги лучше любого «дооформления».
Базовый сценарий
Это вариант с умеренно реалистичными допущениями по трафику, активации, удержанию и выручке. Он показывает, есть ли у продукта шанс выйти на рабочую экономику без завышенных ожиданий. Если базовый вариант не выдерживает, это не «осторожность», а сигнал к пересборке.
Оптимистичный сценарий
Он нужен не для самоуспокоения, а чтобы увидеть верхнюю границу. Если даже оптимистическая версия не даёт разумной окупаемости, проект либо слишком дорогой, либо монетизация для него выбрана неудачно. В такой точке проще менять модель, чем раздувать ожидания.
Стресс-сценарий
Это самый честный тест. Что будет, если CAC вырастет, конверсия в активацию снизится, а удержание окажется короче, чем вы предполагали? Если ответ плохой, вы заранее видите точку отказа и не тратите деньги на иллюзию устойчивости.
| Сценарий | Что меняется | Что проверяем | Какой вывод делать |
|---|---|---|---|
| Базовый | Умеренные допущения по трафику и конверсии | Есть ли шанс на окупаемость | Подходит ли модель как основа |
| Оптимистичный | Сильный рост установки и удержания | Потенциал масштабирования | Можно ли расширять запуск |
| Стресс | Хуже цена привлечения и ниже активность | Сколько проект выдерживает без дофинансирования | Где точка отказа |
Для приложений, которые работают с персональными данными, отдельной строкой надо учитывать требования к хранению и обработке информации. Здесь полезно сверяться не только с внутренней логикой, но и с нормативной базой, включая ФЗ-152. Если это игнорировать, риск появляется не в отчёте, а уже в архитектуре и запуске.
Когда полный бизнес-план можно не делать
Полный документ нужен не всегда. Иногда он съедает время, которое лучше потратить на прототип, тест спроса или первый разговор с рынком. В таких случаях более полезен короткий формат: одна финмодель, несколько сценариев и понятный список допущений.
Если задача, только первый разговор с инвестором, часто достаточно презентации и короткого расчёта. Там важнее фокус, чем объём: проблема, решение, рынок, деньги и следующий шаг. Длинный план без числовой логики всё равно не спасёт, если у проекта нет понятного пути к доходу.
Когда идея ещё в стадии отбора, иногда разумнее начать с бюджета запуска, а не с полноценного бизнес-плана. Это особенно верно, если вы выбираете между несколькими гипотезами и пока не готовы фиксировать одну модель монетизации. В таком случае сначала считают диапазон затрат, а потом собирают расширенный документ.
Отдельный случай — внутренний запуск. Если команде нужно только согласовать первые расходы, не стоит тратить недели на многостраничную версию. Короткая модель даст больше пользы: она быстрее отвечает на вопрос, потянет ли команда старт и где заканчивается допустимый риск.
Типовые ошибки и слабые места
Плохой бизнес-план чаще всего ломается не в стиле, а в цифрах. Он может выглядеть аккуратно, но если расчёты неверны, документ не выдержит ни инвестора, ни внутренней проверки. Поэтому в этой части важнее не общий совет, а конкретная проверка слабых мест.
Самая дорогая ошибка, завысить спрос и занизить расходы одновременно. Тогда модель кажется сильной только на бумаге, а реальный запуск быстро показывает, где именно был самообман. Если проект хорошо выглядит только в одной точке входа, это уже тревожный признак.
Ошибка в воронке
Команда считает установки, но не считает активацию и удержание. В результате кажется, что трафик есть, а реальной аудитории почти нет. Для приложения это критично: без активности установка сама по себе ничего не стоит.
Ошибка в маркетинге
Бюджет на продвижение часто ставят слишком низко. Для мобильного продукта это опасно: без стабильного канала привлечения пользователей даже хороший сервис остаётся незаметным. Если маркетинг не тянет воронку, выручка будет случайной и нестабильной.
Ошибка в сроках и составе команды
Смета ломается, когда не учтены тестирование, публикация, исправления и поддержка. Ещё одна частая проблема — слишком маленькая команда для сложного продукта, из-за чего сроки растягиваются на месяцы. Иногда проект «вовремя» существует только на диаграмме.
Ошибка в модели дохода
Опасно строить выручку только на одном канале монетизации, не проверив, как он работает в вашей нише. Если пользователь не готов платить напрямую, а рекламная модель слабая, экономика быстро проседает. Тогда проблема не в презентации, а в самой механике продукта.
Когда эти ошибки появляются вместе, бизнес-план перестаёт быть инструментом и превращается в оправдание идеи. Лучше заметить это раньше и пересобрать проект, чем объяснять провал уже после релиза.
Что делать после бизнес-плана
Хороший документ нужен не ради самого документа. Он нужен, чтобы команда могла принять решение: запускать, упрощать, менять модель дохода или отказаться от идеи до того, как сгорит бюджет. Поэтому следующий шаг после расчёта — не пауза, а перевод модели в продуктовые действия.
Дальше обычно идут три вещи: проверка сценариев через прототип, уточнение бюджета разработки и выбор технологического пути. Если этого не сделать, бизнес-план быстро устареет и перестанет влиять на решения.
С чего начать после расчётов
Сначала зафиксируйте MVP: какие функции нужны, чтобы проверить спрос, а какие можно отложить. Затем соберите прототип, чтобы проверить путь пользователя, а не только описание функций. После этого уже имеет смысл обсуждать детальную смету и сроки релиза.
Как связать план с разработкой
Когда расчёты готовы, следующий логичный шаг, оценить состав работ и платформу. Для этого пригодятся материалы про Гибридные приложения Нативную разработку и проблемы разработки мобильных приложений. Они помогают не расплываться в общих словах, а принять решение по срокам, стоимости и рискам до старта.
Почему этот порядок экономит деньги
Если сначала считать не целую «идею», а конкретный путь пользователя, в модели быстро видно слабое место. Иногда узкое горлышко не в коде и не в дизайне, а в том, что люди не доходят до ключевого действия или не понимают ценность приложения в первые минуты. Это как раз тот случай, когда прототип дешевле, чем поздний rework.
Как Animar Media помогает сверить план с реальной экономикой
Для бизнес-плана мобильного приложения важнее всего не общая теория, а диапазоны по стоимости и понимание, из чего складывается бюджет. Именно поэтому полезно сверять расчёты с материалом Animar Media: он помогает не строить смету в вакууме, а привязать её к типу продукта, этапам работы и выбору платформы.
Это особенно уместно, когда команда уже определилась с идеей, но ещё не понимает, хватит ли денег на запуск и где экономика начнёт проседать. Такой формат полезен и для стартапа, и для внутреннего проекта: он возвращает разговор к срокам, деньгам и реальным ограничениям, а не к красивому описанию концепции. Если нужен опорный материал для финансовой модели, такой подход работает честно.
не меняем/»>Сколько стоит разработка приложения 2025 – обзор и цены
Часто задаваемые вопросы
Когда для приложения достаточно короткой финмодели, а не полного бизнес-плана?
Когда задача, быстро понять, сходится ли экономика, или подготовить первый разговор с партнёром. Если вы идёте за внешними деньгами, грантом или сложным согласованием, обычно нужен уже полный документ с допущениями и сценариями.
Что делать, если нет данных по стоимости привлечения пользователей?
Не подставляйте минимальное число «для красоты». Лучше заложить диапазон, а рядом описать, как вы проверите его на тестовом трафике, в пилоте или по бенчмаркам похожих проектов.
Как понять, что прогноз слишком оптимистичен?
Если проект сходится только при высокой конверсии, низком CAC и длинном удержании, это тревожный знак. Нормальная модель должна выдерживать хотя бы базовый и стресс-сценарий без красивых допущений.
Когда стоит менять монетизацию, а не дорабатывать расчёты?
Если выручка держится только на одном слабом канале и его нельзя масштабировать без резкого роста расходов, проблему нужно искать в самой модели дохода. Иногда проще сменить механику заработка, чем подгонять цифры под неудобный продукт.
Какие расходы на приложение чаще всего забывают?
Чаще всего забывают поддержку после релиза, обновления под новые версии ОС, аналитику, публикацию, тесты и повторные маркетинговые волны. На старте это кажется второстепенным, но именно эти статьи часто съедают маржу.
Что делать, если бизнес-план нужен для гранта, а не для инвестора?
Сместить акцент с возврата капитала на измеримый эффект, реализуемость и пользу проекта. При этом расчёт расходов и сценариев всё равно нужен: грантовая комиссия тоже смотрит, не является ли проект фантазией без бюджета и сроков.
