О компании заказчика
Заказчик работает в строительной отрасли более 15 лет. Компания строит дома, занимается премиальным ремонтом квартир, жилых помещений и офисов, а также производством мебели и сопутствующими строительными работами.
Для клиента проект был важен в двух направлениях.
С одной стороны, нужно было решить внутреннюю операционную задачу: ускорить подготовку смет, актов и контроль выполнения работ на объектах.
С другой — заказчик рассматривал приложение как потенциальный IT-продукт для строительного рынка, который можно развивать, продвигать и использовать как отдельное направление бизнеса.
Исходная ситуация
До начала проекта у заказчика уже была идея мобильного приложения, техническое задание и частично проработанные сценарии в Figma. Внутри компании также использовался Excel-документ, который помогал быстрее составлять сметы.
Но Excel оставался неудобным инструментом для работы на объекте. Данные приходилось переносить вручную, часть информации обсуждалась через мессенджеры и звонки, а итоговая подготовка сметы могла занимать около двух дней.
Это тормозило следующий этап сделки: согласование условий, подписание договора и старт работ. Кроме того, ошибки в сметах могли приводить к финансовым потерям, которые компания закрывала за свой счёт.
Главная проблема была не в отсутствии расчётов, а в том, что процесс составления сметы оставался слишком долгим, ручным и неудобным для работы на объекте.
Отдельное ограничение заключалось в том, что заказчик раньше не запускал IT-продукты. Ему была нужна не просто команда разработки, а подрядчик, который поможет пройти весь путь: от проверки идеи и требований до релиза, передачи продукта и дальнейшей поддержки.
Задача проекта
Нужно было превратить отраслевую экспертизу заказчика в понятный мобильный продукт для строительных процессов.
В рамках проекта требовалось:
проверить, есть ли на рынке реальная потребность в продукте для быстрого составления строительных смет;
проработать бизнес-требования и превратить идею заказчика в продуктовую концепцию;
сформировать функциональные и нефункциональные требования;
разработать удобный сценарий составления сметы прямо на объекте;
создать логику работы на уровнях компании, проекта и конкретной сметы;
реализовать возможность формировать акты на основе смет и этапов работ;
сделать интерфейс понятным для строительных специалистов, прорабов и небольших компаний;
разработать мобильное приложение и backend-часть;
подготовить продукт к релизу;
передать заказчику права, доступы, кодовую базу и проектные артефакты.
Главная бизнес-цель проекта — сократить время подготовки смет, уменьшить ручную нагрузку и создать основу для масштабируемого IT-продукта в строительной отрасли.
Решение
Мы предложили не начинать проект сразу с разработки. Сначала нужно было проверить, действительно ли проблема существует не только внутри компании заказчика, но и у других участников строительного рынка.
Такой подход был важен, потому что клиент рассматривал приложение не только как внутренний инструмент, но и как будущий продукт для внешнего рынка.
В основе решения было несколько направлений:
01. Проверка продуктовой гипотезы Мы начали с Discovery и customer development: изучили проблему, целевую аудиторию и подтвердили, что потребность в более быстром составлении смет есть у строительных специалистов, прорабов, частных мастеров и небольших компаний.
02. Перевод строительной экспертизы в продуктовую логику Заказчик хорошо понимал строительные процессы, но эту экспертизу нужно было превратить в требования, сценарии, структуру данных и понятный интерфейс. Команда Avenir помогла описать бизнес-логику продукта и подготовить её к разработке.
03. Фокус на скорости составления сметы Главная ценность приложения — не сложный набор функций, а возможность быстрее перейти от замера и обсуждения работ к готовой смете, согласованию условий и сделке.
04. Архитектура с возможностью развития Продукт проектировался не как разовый прототип, а как система, которую можно поддерживать, дорабатывать и масштабировать. Поэтому команда заранее учитывала роли, проекты, сметы, акты, стенды, backend-логику и дальнейшую передачу продукта заказчику.
Было: сметы готовились в Excel и через ручные коммуникации, а процесс мог занимать около двух дней. Стало: сметы можно формировать быстрее в мобильном приложении, используя структуру работ и прайс-лист.
Было: часть данных передавалась через звонки и мессенджеры. Стало: информацию можно вносить на объекте во время общения с клиентом.
Было: заказчик имел идею и отраслевую экспертизу, но не имел опыта запуска IT-продукта. Стало: клиент получил готовое приложение, кодовую базу, доступы, права и проектные артефакты для дальнейшего развития.
Что было сделано
Команда Avenir взяла на себя полный цикл работ: от проверки идеи и аналитики до разработки, релиза и передачи продукта заказчику.
В рамках проекта мы:
провели проверку продуктовой гипотезы;
пообщались с целевой аудиторией и подтвердили наличие проблемы;
собрали бизнес-требования;
перевели бизнес-логику в функциональные и нефункциональные требования;
подготовили план проекта с этапами, сроками и ориентировочной стоимостью;
сформировали команду разработки;
проработали архитектуру сервиса;
разработали дизайн интерфейсов;
реализовали мобильное приложение;
разработали backend-часть продукта;
подготовили несколько тестовых стендов и production-стенд;
вывели приложение на площадки;
передали заказчику права, доступы, кодовую базу и проектные артефакты;
продолжили поддержку и доработку продукта по запросам.
Работы можно разделить на несколько ключевых направлений:
01. Продуктовая аналитика и Discovery Мы помогли заказчику проверить идею, уточнить целевую аудиторию, понять ценность продукта и сформировать реалистичную основу для разработки.
02. Проектирование бизнес-логики Команда описала, как внутри продукта должны работать компании, проекты, сметы, акты, роли и ограничения пользователей.
03. UX/UI-дизайн мобильного приложения Мы спроектировали интерфейс с учётом пользователей, которые работают на объектах и не хотят тратить время на сложные сценарии.
04. Разработка приложения и backend Команда реализовала мобильное приложение на React Native и backend на Python. В проекте использовалась микросервисная архитектура.
05. Релиз, передача и поддержка После разработки команда подготовила продукт к релизу, передала заказчику технические артефакты и продолжила сопровождение.
В результате заказчик получил не набор разрозненных экранов, а полноценный цифровой продукт с понятной логикой, технической базой и возможностью дальнейшего развития.
Мобильное приложение
Ключевой частью продукта стало мобильное приложение для быстрого составления строительных смет.
После внедрения решения команда заказчика получила возможность:
создавать сметы быстрее и удобнее;
работать с составом работ и прайс-листом;
выбирать нужные позиции и редактировать данные;
формировать смету на основе выбранных работ;
работать с объектом прямо на месте;
связывать сметы с проектами и этапами;
формировать акты на основе смет и выполненных работ;
учитывать разные роли пользователей и ограничения доступа.
Одним из важных решений стала структура работы на нескольких уровнях:
компания — общий уровень управления;
проект — конкретный объект или заказ;
смета — расчёт работ, материалов и этапов.
Такой подход помог сделать продукт ближе к реальным строительным процессам: пользователь работает не с абстрактным документом, а с объектом, проектом, работами и актами.
Обмерный план и работа с объектом
Во время анализа конкурентов команда увидела, что во многих сервисах для построения помещений используется отдельный редактор: пользователю нужно вручную отрисовывать комнату и настраивать её параметры.
Для этого проекта мы предложили более простой сценарий. Пользователь собирает помещение с помощью блоков, вносит размеры, а система помогает связать эти данные со сметой.
Это решение лучше соответствовало главной ценности продукта: не перегружать пользователя лишними действиями, а помочь быстрее подготовить смету и перейти к согласованию работ.
Подготовка продукта к развитию
Проект изначально рассматривался как продукт, который можно развивать дальше. Поэтому мы уделили внимание не только интерфейсу и функциональности, но и организационной стороне запуска.
В проекте использовались:
Discovery;
customer development;
валидация продуктовых гипотез;
Agile-подход;
планирование по этапам;
Time & Material;
React Native для мобильного приложения;
Python для backend-разработки;
микросервисная архитектура;
несколько тестовых стендов;
отдельный production-стенд;
DevOps-подходы для поддержки инфраструктуры.
AI/ML-модели в приложении не использовались. Продукт работает на алгоритмах и backend-логике.
База данных, точный DevOps-стек и интеграции во входных данных не указаны, поэтому в кейсе мы не фиксируем их как подтверждённые детали.
Ход проекта
Проект двигался поэтапно: от проверки идеи до релиза и передачи продукта заказчику.
01. Проверка идеи и рынка Клиент пришёл с идеей, над которой думал несколько лет. Мы начали с проверки гипотезы, чтобы понять, есть ли такая проблема у других участников строительного рынка, а не только внутри компании заказчика.
02. Погружение в строительные процессы Команда изучила, как формируются сметы, как они связаны с работами, актами, этапами проекта и коммуникацией с клиентом.
03. Проработка требований После валидации гипотезы мы собрали бизнес-требования, функциональные и нефункциональные требования, а также подготовили план проекта с этапами, сроками и ориентировочной стоимостью.
04. Проектирование UX/UI Мы проработали сценарии, в которых строительный специалист может быстро составить смету прямо на объекте, без лишней сложности и перегруженного интерфейса.
05. Разработка мобильного приложения и backend Команда реализовала мобильную часть, backend-логику, работу с проектами, сметами, актами, ролями и ограничениями.
06. Тестирование и подготовка стендов Для проекта были подготовлены несколько тестовых стендов и production-стенд, чтобы команда могла проверять продукт перед релизом.
07. Релиз и передача продукта Примерно через полгода после старта продукт был выведен на площадки. Далее команда продолжила дорабатывать приложение до полноценной версии, которой могут пользоваться люди.
Такой подход был удобен для заказчика, потому что разработка не превращалась в «чёрный ящик». Клиент видел требования, схемы, диаграммы, архитектурные решения и промежуточные результаты.
Как был организован процесс
Проект вёлся по гибкому процессу. На этапе аналитики и Discovery команда встречалась с заказчиком два раза в неделю, чтобы обсуждать требования, сценарии, бизнес-логику и техническое задание.
После старта разработки коммуникация стала регулярной и прозрачной:
каждую неделю обсуждались продуктовые и бизнес-вопросы;
каждые две недели проводились промежуточные демо;
в конце месяца команда показывала функциональный результат;
внутри команды проходили ежедневные синхронизации;
по понедельникам проводилось планирование;
в конце недели — ретроспектива и улучшение процессов.
Заказчик был глубоко вовлечён в проект и выступал как отраслевой эксперт. Команда Avenir со своей стороны отвечала за продуктовую упаковку, разработку, архитектуру, управление процессом и движение к релизу.
Сложности проекта
У заказчика не было опыта запуска IT-продуктов
Клиент хорошо понимал строительный бизнес, но раньше не проходил полный цикл разработки цифрового продукта.
Мы взяли на себя не только техническую реализацию, но и продуктовую часть: помогли проверить гипотезу, собрать требования, описать бизнес-логику, подготовить план разработки и организовать процесс.
Отраслевую экспертизу нужно было превратить в систему
У заказчика было глубокое понимание строительных процессов, но эту экспертизу нужно было перевести в понятные сущности продукта: компании, проекты, сметы, акты, роли, ограничения и пользовательские сценарии.
Мы работали с заказчиком как с отраслевым экспертом, а затем превращали его знания в требования, интерфейсы, схемы и архитектурные решения.
Логика смет, ролей, проектов и актов была сложной
Продукт должен был поддерживать несколько уровней работы и учитывать разные сценарии пользователей.
Чтобы система оставалась управляемой, команда проработала архитектуру с разделением на компанию, проект и смету, а также учла роли и ограничения доступа.
В процессе изменились бюджетные условия
Проект был рассчитан примерно на год работы. Изначально бюджет составлял около 500 000 рублей в месяц, позже он сократился до 400 000 рублей.
Чтобы сохранить темп, команда перестроила формат работы: часть специалистов работала full-time, часть — part-time по Time & Material. Задачи разбивались на параллельные блоки, а отдельные решения согласованно упрощались ради релиза.
Нужно было выпустить не прототип, а рабочий продукт
Заказчик хотел получить не демонстрационную версию, а продукт, которым можно пользоваться и который можно развивать дальше.
Мы сохранили фокус на ключевой ценности: быстром составлении смет, работе с актами и контроле выполнения работ. Это помогло не перегрузить первую версию и при этом заложить основу для дальнейшего масштабирования.
Результат
Заказчик получил готовое мобильное приложение для строительной отрасли, которое помогает быстрее составлять сметы, работать с актами и контролировать выполнение работ.
После проекта клиент получил:
проверенную продуктовую гипотезу;
описанные бизнес-требования;
функциональные и нефункциональные требования;
дизайн мобильного приложения;
разработанное мобильное приложение;
backend-часть продукта;
несколько тестовых стендов и production-стенд;
релиз приложения на площадках;
переданные права, доступы, кодовую базу и проектные артефакты;
поддержку и дальнейшую доработку сервиса.
Продукт уже используется внутри компании заказчика. По данным из интервью, процесс составления смет улучшился на 30%, а экономия для компании составляет от 40 000 рублей в месяц.
Также стало удобнее работать на объектах: данные можно вносить на месте, во время общения с клиентом, а не передавать через мессенджеры или звонки. Смета формируется автоматически на основе выбранных работ и прайс-листа, что снижает ручную нагрузку и помогает быстрее переходить к согласованию условий.
Главный результат проекта — заказчик получил не просто приложение, а самостоятельный IT-продукт, который можно использовать внутри компании, развивать и масштабировать на строительном рынке.
Почему этот кейс важен для похожих компаний
Этот кейс будет близок компаниям, у которых есть сильная внутренняя экспертиза, но нет понятного пути, как превратить её в digital-продукт.
Чаще всего похожая ситуация возникает, когда:
бизнес работает через Excel, мессенджеры и ручные процессы;
сотрудники тратят много времени на подготовку документов;
ошибки в расчётах приводят к финансовым потерям;
у компании есть идея продукта, но нет опыта разработки;
уже есть ТЗ, наброски интерфейсов или внутренние таблицы, но не хватает системной реализации;
нужно не просто написать код, а проверить гипотезу, собрать требования и довести продукт до релиза.
Команда Avenir умеет подключаться не только на этапе разработки. Мы помогаем разобраться в бизнес-задаче, проверить ценность идеи, спроектировать продуктовую логику и пройти путь от концепции до работающего digital-инструмента.
Хотите автоматизировать процессы или запустить цифровой продукт?
Если в вашей компании есть процессы, которые до сих пор держатся на Excel, ручных расчётах, чатах и звонках, их можно превратить в удобный цифровой инструмент.
Команда Avenir поможет разобраться в текущем процессе, проверить продуктовую идею, спроектировать решение и разработать приложение, сервис или внутреннюю систему под задачи бизнеса.
Мы можем подключиться как на старте идеи, так и к уже существующему проекту: провести аудит, собрать требования, предложить план работ и довести продукт до результата.