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