
Planyard: как три основателя довели SaaS для строителей до $10-20 тыс. в месяц
Planyard продаёт подрядчикам единое место для сметы, заказов, фактических расходов и прогноза маржи. История полезна не набором функций, а порядком действий: сначала разговоры с людьми в отрасли и кликабельные макеты, затем узкий продукт для контроля денег на объекте.
- Рынок
- $1,5 млрд: глобальный рынок ПО для строительных смет в 2025 году
- Бюджет
- от 150 000 ₽ на первую версию для одного узкого процесса, без интеграций с учётными системами
- Модель
- SaaS
- Сложность
- высокая
- Чтение
- · 8 мин чтения
Коротко
- Что продают: контроль сметы, обязательств и фактических расходов для подрядчика
- Деньги: в июне 2022 года — $10-20 тыс. MRR примерно от 40 клиентов
- Вход: начать не с «системы для всей стройки», а с одного объекта и одной боли — расхождения сметы с фактом
- Вердикт: модель применима в России с адаптацией к учёту, документам и каналам продаж
Завязка
В стройке прибыль часто исчезает не в момент подписания договора, а позже: закупка вышла дороже, субподрядчик прислал счёт без привязки к смете, а руководитель увидел разницу после закрытия месяца. Planyard пытается поймать этот момент раньше. В июне 2022 года три основателя без внешнего капитала обслуживали около 40 клиентов и называли выручку $10-20 тыс. в месяц. Это историческая цифра из интервью, а не текущий показатель компании, но она хорошо показывает масштаб первого работающего продукта. Интервью GetLatka
Planyard соединяет бюджет объекта, заказ, счёт поставщика и прогноз результата. Подрядчик покупает не таблицу красивее Excel, а возможность увидеть перерасход до того, как его уже нельзя переложить в цену.
Рынок не заперт в одной стране. Grand View Research оценивает мировой рынок ПО для строительных смет в $1,5 млрд в 2025 году и прогнозирует $3,8 млрд к 2033 году. Отчёт рынка Не нужно брать весь рынок. Для команды из одного-трёх человек достаточно одного типа подрядчика, который регулярно считает похожие работы и теряет деньги на ручном переносе цифр.
Что делают
Planyard — облачный SaaS для финансовой части строительных проектов. В нём можно загрузить бюджет, назначить ответственного, создавать заказы, согласовывать траты, сопоставлять документы и передавать одобренные данные в учётную систему. На сайте заявлены интеграции с Xero, QuickBooks, Sage и MYOB. Это не замена прорабу и не производство оборудования: сервис живёт поверх того, что происходит на объекте.
Клиент платит за доступ пользователей. Сейчас есть 14-дневный пробный период без карты, а базовый тариф для руководителя проекта начинается от $52 в месяц; следующие уровни стоят $105, $158 и $210. Дополнительный сотрудник обходится в $43 в месяц. Тарифы Planyard Такая сетка важнее названий пакетов: компания растит чек вместе с числом людей и глубиной финансового контроля, а не ждёт один большой контракт.
Главная страница обещает подрядчику заменить разрозненные таблицы единым финансовым контуром по объектам.
Не нужно повторять весь продукт. Первая версия живёт между сметой и фактом: импортирует одну смету, принимает фотографии и PDF счетов, вручную привязывает их к статьям и предупреждает владельца, когда лимит почти исчерпан. Если этим пользуются на одном объекте, тогда стоит добавлять платежи, закупки и интеграции.
Юнит-экономика
Публичной отчётности с полной себестоимостью, CAC или удержанием нет. Поэтому не будем изображать точный LTV. Есть несколько проверяемых ориентиров: исторические MRR, число клиентов, команда и открытая цена.
| Метрика | Значение | Источник |
|---|---|---|
| MRR в июне 2022 года | $10-20 тыс. | GetLatka |
| Клиенты в июне 2022 года | около 40 | GetLatka |
| Основатели в июне 2022 года | 3 | GetLatka |
| Выручка за 2021 год | менее $200 тыс. | GetLatka |
| Базовый текущий тариф | $52 в месяц за руководителя проекта | pricing |
| Пробный период | 14 дней без карты | pricing |
Диапазон $10-20 тыс. MRR на 40 клиентах не даёт честного среднего чека: у компании была цена, зависящая от числа проектов и оборота подрядчика. Зато он даёт практический вывод. До первых $10 тыс. в месяц не нужен рынок из тысяч покупателей. Нужны несколько десятков компаний, у которых стоимость ошибки в смете выше ежемесячной подписки.
Текущая цена делает расчёт входа понятнее. При $52 в месяц до $10 тыс. MRR требуется около 193 лицензий, если все покупают начальный план. Но это потолок по числу, а не план продаж: у строительной компании может быть несколько руководителей проектов, а тарифы выше. Правильнее строить не «193 регистрации», а список из 30-50 подрядчиков одного типа, проверить у них цену ошибки и продать первые платные внедрения вручную.
Тарифы привязаны к роли и ежемесячной лицензии: это делает доход повторяющимся и даёт понятный путь к более дорогому плану.
Есть и неприятный факт. В отчётности эстонского юрлица за 2024 год указаны €181 747 выручки и €84 222 чистого убытка; за 2025 год — €264 432 выручки и €47 633 чистого убытка. Эстонский бизнес-реестр Это не повод объявлять модель плохой и не доказательство текущего состояния продукта. Это повод не подменять выручку прибылью и не обещать читателю готовую маржу там, где данных нет.
Считаем твою экономику
У соло-билдера первая экономика будет другой. Не нужно сразу копировать облачную платформу с четырьмя интеграциями. Достаточно одного обещания: «к вечеру владелец видит, где по объекту ушли деньги относительно согласованной сметы».
| Статья | Что делать в первой версии | Почему не расширять сразу |
|---|---|---|
| Смета | загрузка Excel и ручная разметка статей | распознавание сложных форматов съест месяцы |
| Факт | фото счёта, PDF или ввод суммы | источник данных важнее идеального интерфейса |
| Сверка | сопоставление статьи, поставщика и суммы | здесь возникает денежная ценность |
| Оповещение | Telegram или email при перерасходе | владелец должен узнать первым |
| Отчёт | один экран «план — факт — прогноз» | не нужна ERP для первой продажи |
Бюджет в 150 000 ₽ — это не публичная цена разработки и не обещание сроков. Это редакционный ориентир для узкого пилота: интерфейс, база данных, импорт одной структуры сметы, простое распознавание документов и уведомления. Он подходит только если основатель сам делает продукт или покупает небольшую часть работ. Интеграции с бухгалтерией, ЭДО, банковскими выписками и мобильное приложение надо продавать отдельно после того, как ручной контур дал хотя бы десять платящих объектов.
Платить на старте должен не бухгалтер «за удобство». Платит владелец или финансовый руководитель, который отвечает за маржу объекта. Оффер первого разговора: «За неделю соберём один ваш объект в контроль план-факт и покажем, какие траты сейчас не видны в смете. Если отчёт не даёт нового решения, ничего не платите». Такой оффер снимает главный страх: что подрядчику снова продают длинный проект внедрения.
Что нужно, чтобы повторить
Повторять здесь нужно не интерфейс Planyard, а порядок работы. У строителей уже есть документы, таблицы, чаты и люди, которые привыкли работать по-своему. Новый сервис проиграет, если потребует сначала перенести весь учёт, а результат пообещает когда-нибудь потом. Первый оффер должен быть уже полезен поверх привычного хаоса.
Начните с одной связки документов. Например, возьмите смету и счета по действующему объекту. Заказчик даёт исходную таблицу, сервис собирает расходы по статьям и показывает владельцу три вещи: сколько было запланировано, что уже подтверждено документами и где расход выходит за пределы сметы. Этого достаточно, чтобы разговор был о деньгах, а не о «цифровой трансформации».
Первые данные придётся разбирать вручную. Это не провал продукта, а способ увидеть реальный процесс. Если в счетах постоянно нет номера объекта, проблема не решится красивой формой загрузки. Если один поставщик пишет название материала по-разному, нужно сначала договориться со сметчиком о правилах. Ручная работа на пилоте показывает, какие поля обязательны и какую проверку действительно ценит клиент.
Сразу определите границу ответственности. Сервис сообщает об отклонении и хранит комментарий, но не утверждает платёж, не рассчитывает налоги и не меняет учётную запись клиента. Такая граница делает пилот короче и снижает страх заказчика. Когда владелец несколько раз увидит расход раньше, чем он попал в итоговую сводку, можно обсуждать следующую операцию.
Нужен и простой ритуал использования. Владелец не будет открывать новую систему ради красивого дашборда. Он будет читать короткое сообщение, если оно отвечает на вопрос: «На каком объекте сегодня появилась проблема и кому её отдать?» Поэтому первый отчёт должен быть устроен вокруг решения, а не вокруг всех данных. Внутри можно оставить ссылку на детали, но в сообщении нужна одна причина внимания и одна следующая задача.
Продажа тоже начинается не с демонстрации десятков экранов. Покажите сметчику, руководителю объекта и владельцу один знакомый документ и спросите, где сейчас появляется расхождение. Пусть каждый назовёт свой момент: до закупки, после счёта или при закрытии месяца. Если ответы разные, выберите того, кто теряет деньги и может принять решение о пилоте. Пользователь и покупатель могут быть разными людьми, но их интересы надо соединить в первом предложении.
Деньги за пилот лучше брать за понятный результат, а не за доступ к ещё одной программе. Формулировка может быть такой: «Соберём контроль по одному объекту и покажем, какие расходы не видны в исходной смете». Она не обещает убрать всю ручную работу и не требует от клиента сменить учёт. После результата появляется право обсуждать подписку за регулярный контроль.
Почему не взять готовое
Вопрос про Excel нельзя обходить. Для маленького подрядчика таблица бесплатна, знакома и уже содержит смету. Ответ не в том, что она «устарела». Excel хорошо считает, пока один человек помнит, где лежит последняя версия, а расходы приходят в одном порядке. Проблема возникает, когда заказ, счёт и комментарий живут в разных местах, а владелец видит итог слишком поздно. Новый продукт должен исправлять этот разрыв, а не заставлять клиента защищать старый инструмент.
Полная ERP решает другую задачу. Она подходит компании, которая готова к длинному внедрению, настройке ролей и интеграциям. Для выбранного первого сегмента это часто означает слишком много работы до первого результата. Не надо убеждать клиента, что ERP плохая. Надо показать, что узкий слой контроля можно поставить быстрее и оставить существующую систему на месте.
Сметные программы тоже не враг. Они помогают собрать расчёт, но не всегда отвечают на вопрос, совпал ли план с тем, что уже произошло на объекте. В этом и лежит место для отдельного сервиса. Он не спорит с привычной сметой, а берёт её как исходную точку и возвращает владельцу сигнал об отклонении.
Узость продукта здесь важнее длинного списка возможностей. Хорошая первая версия отказывается от задач, которые не помогают увидеть перерасход: кадровый учёт, склад, зарплата, договорная работа и полный документооборот. Отказаться от них сложно, потому что почти каждый клиент попросит добавить «ещё одну мелочь». Но каждая такая просьба тянет новый тип данных, новую ответственность и новую поддержку.
Проверка перед расширением простая. Если новая операция не помогает владельцу раньше увидеть риск для маржи объекта, она не нужна в ближайшем выпуске. Если помогает, сначала проведите её руками на нескольких объектах. Только после повторения стоит автоматизировать ввод, уведомление и отчёт. Так продукт остаётся понятным и для команды, и для покупателя.
Карта первого пилота
Первое условие пилота — один человек у клиента отвечает за исходную смету. Без этого сервис быстро станет местом, куда все отправляют документы, но никто не отвечает за расхождения. Второе условие — владелец готов смотреть короткий отчёт и отвечать на вопрос по спорному расходу. Третье — объект ещё не закрыт: только тогда предупреждение может изменить решение, а не превратиться в посмертную аналитику.
На запуске полезно заранее договориться, что считается успехом. Не «мы попробовали новую программу», а «по этому объекту понятно, какие расходы уже не укладываются в смету и что с ними делать». Тогда обе стороны знают, зачем передают документы и почему на пилоте нужна ручная работа. У клиента появляется измеримый результат, у создателя сервиса — материал для следующей продажи.
После пилота спросите не «какие функции добавить», а «какое решение вы приняли благодаря этому отчёту». Если ответа нет, ценность пока не доказана. Если владелец назвал заказ, закупку или подрядчика, где удалось вовремя вмешаться, повторяйте этот сценарий на следующем объекте. В этот момент сервис начинает продавать не хранение документов, а контроль денег до закрытия работ.
Точка дизрапта
Главная дельта не в том, что программа хранит документы. Таблицы тоже умеют хранить цифры. Дельта в связке: смета становится исходной точкой, заказ создаёт обязательство, счёт подтверждает факт, а руководитель видит прогноз до закрытия объекта. В этой последовательности можно использовать распознавание счетов и подсказки по статье бюджета, но ИИ не должен быть товаром сам по себе. Если данные грязные, нейронка лишь быстрее разнесёт ошибку по отчёту.
Смысл продукта — не заменить сметчика, а связать смету с фактическими расходами до того, как убыток станет необратимым.
Для узкой версии можно начать даже без автоматического распознавания. Оператор или сам заказчик разносит пять-десять документов в день. Когда накопится однотипный поток, добавляется извлечение суммы, поставщика и даты. Только после этого стоит строить правила для отклонений. Такой порядок оставляет деньги на продажи, а не на бесконечную автоматизацию.
Конкурентное преимущество
У Planyard преимущество складывается из накопленного продукта: бюджеты, заказы, счета, согласования, прогнозы и интеграции. Новичку не надо побеждать его на всём поле. Его защита — глубоко понятный первый сегмент и его язык. Например, не «строительные компании», а небольшие отделочные подрядчики с 2-5 параллельными объектами, которые ведут смету в Excel и получают счета поставщиков в Telegram.
Большая ERP проигрывает здесь не качеством кода, а ценой входа. Для маленькой фирмы она слишком длинная, слишком общая и требует человека, который будет её настраивать. Узкий сервис может поставить результат за неделю, если не просит клиента менять весь учёт. Но защита хрупкая: как только продукт начнёт трогать налоги, платежи и юридически значимые документы, вырастут и ответственность, и стоимость поддержки.
Кейс Planyard показывает тип заказчика: подрядчик ищет не новую технологию, а контроль результата по объекту.
Как выходили на рынок — и как выходить тебе
Как Planyard продавал
Самый сильный факт в ранней истории Planyard — первая готовность платить появилась до кода. Основатели поговорили со знакомыми из строительства, проверили проблему на макетах в Google Sheets и Google Slides, а не стали сначала строить большой продукт. Интервью GetLatka Это и есть нормальная последовательность для скучной B2B-ниши: сначала убедиться, что у человека есть регулярная боль и бюджет, затем автоматизировать повторяющийся кусок.
На раннем этапе это была продажа от основателей. Публичный источник не раскрывает число звонков, CAC, конверсию или неудачные каналы. Их нельзя дорисовывать. Зато понятно направление эволюции: продукт вырос от проверки макета до системы, которую сегодня продают через 14-дневный пробный период, демо, страницы по ролям и контент для разных типов подрядчиков. Сайт Planyard
Контент здесь не заменяет продажу. Он помогает сформулировать проблему так, как её ищут: расчёт сметы, контроль бюджета, закупки, счета, прогноз денежных потоков. Для нового продукта разговор о конкретном объекте и его цифрах остаётся лучшим способом понять, за что клиент готов платить.
Как выходить билдеру
Первый ICP в России и СНГ: независимые отделочные и инженерные подрядчики с 2-5 одновременно идущими объектами в городах от 100 тыс. жителей. У них обычно есть владелец, сметчик или руководитель проектов; они уже считают работу в Excel, получают счета в чатах и узнают о перерасходе слишком поздно. Не начинайте с девелопера, федеральной сети или генподрядчика на госзаказе. Там длинные закупки, тендеры и интеграции съедят год.
Не начинайте с рекламного кабинета. Соберите 100 компаний через 2ГИС, профильные чаты подрядчиков, поставщиков материалов и рекомендации сметчиков. Выберите один город и одну специализацию: например, ремонт коммерческих помещений. Напишите коротко: «Собираем план-факт по объекту из вашей сметы и счетов. Покажем перерасход до закрытия месяца. Нужен один объект на пилот». Затем назначьте 20 разговоров и на каждом просите показать текущую таблицу.
Последовательность простая. Сначала десять объектов ведутся руками: вы помогаете импортировать смету и разбирать документы. Потом ищете три повторяющиеся операции и автоматизируете только их. Когда получится 30-50 объектов одного типа, добавляете повторяемый канал: партнёрство с независимым сметчиком, бухгалтером для строителей или поставщиком материалов. Только после этого имеет смысл покупать поиск и масштабировать продажи.
Главное возражение будет таким: «У нас уже есть Excel». Не спорьте. Ответ: «Excel остаётся. Мы не меняем вашу смету, а каждый день показываем, какие счета и обязательства уже выбили её из плана». Если клиент не может назвать цену одного перерасхода и не готов дать один объект в пилот, это плохой первый клиент.
Применение в России и СНГ
Вердикт — применимо с адаптацией. Локальный рынок уже знает сметные программы и учётные системы, поэтому продавать «ещё одну смету» бессмысленно. Продавать нужно контроль факта по объекту поверх того, что уже есть. У клиента могут быть Excel, 1С, Битрикс24, бумажные акты и Telegram. Побеждает тот, кто не заставляет выбросить их в первый день.
Из локальных ориентиров стоит изучить Smeta.RU и ГРАНД-Смету: они работают со сметной частью, значит привычка платить за расчёт в отрасли существует. Для лёгкого контура нужны не их функции целиком, а импорт сметы, документы и контроль план-факт. Живые сайты этих компаний полезны как карта ожиданий заказчика, а не как оправдание копировать интерфейс.
По платежам подойдут YooKassa или Tinkoff, для сообщений — Telegram и Voximplant, для размещения — Yandex Cloud. Первые контакты удобнее собирать через 2ГИС, Авито, Telegram-чаты, VK и партнёров-поставщиков. Если сервис хранит данные сотрудников, контрагентов или документы с персональными данными, нужно соблюдать требования 152-ФЗ и заранее определить, где лежат данные и кто имеет к ним доступ. Текст 152-ФЗ
Не надо начинать с ЭДО, банковской сверки или автоматического расчёта налогов. Это отдельные продукты с другой ценой ошибки. Первый рабочий продукт может принять файл сметы, принять расход, показать отклонение и сохранить комментарий. Юридические требования зависят от конкретных функций и данных, поэтому их нужно проверить до запуска пилота.
Риски
- Данные в плохом виде. Сметы, счета и акты приходят в разных файлах, поэтому автоматизация без ручного этапа будет ошибаться
- Длинная сделка. Если первым клиентом выбрать крупного застройщика, продукт уйдёт в согласования и интеграции
- Неправильный покупатель. Прораб может пользоваться системой, но платить должен человек, которому важна маржа
- Слишком широкий продукт. CRM, учёт, закупки, зарплата и документооборот в первой версии размоют одно обещание
Вердикт
Planyard показывает, что SaaS для стройки можно начать втроём и довести до первых $10-20 тыс. MRR, если продавать не «цифровизацию», а раннее обнаружение перерасхода на конкретном объекте.
Такой разбор — с цифрами, юнит-экономикой и бюджетом на старт — выходит каждый день в канале.
Читать разборы в Telegram
