Портал бюджетов для стройки за два дня: как руководитель без разработчиков закрыл двойной ввод

В строительной компании планы по проектам жили в Google-таблицах. Каждый руководитель проекта вёл свою: сроки, объёмы, суммы. Финансисты потом переносили эти цифры в общие таблицы, сводили по компании и считали прогноз. Между «своей» таблицей и общей данные проходили руками ещё раз, и на этом переносе рождались ошибки, которые всплывали в отчёте через неделю.

Денис Кулик, участник клуба, руководит в этой компании и программистом никогда не был. Задачу он закрыл сам за два дня: развернул сервер, собрал веб-портал на собственном домене и перевёл туда весь цикл — бюджеты, факт, планы команд и прогнозы.

Почему двойной ввод не лечится дисциплиной

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

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

Что он собрал

Портал получился обычным веб-приложением на своём домене. Внутри — бюджеты по проектам, факт, планы команд и прогнозы, которые считаются по одной зашитой методике со ставками и взносами. Руководители заполняют свои разделы у себя, финансисты видят сводку сразу, без переноса.

Технически всё жило на сервере Ubuntu, который Денис поднял в Нидерландах, и на Claude Code, который писал код по его описанию задачи. Сам он в этой связке отвечал за то, чего инструмент знать не может: как в компании считают деньги, кто какие данные вносит и что должно получиться на выходе.

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

Что сломалось по дороге

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

Это самая частая ошибка на входе, и стоит она времени: объяснять задачу приходится по второму кругу. Когда правила проекта записаны в файл, который агент читает в начале каждой сессии, перезагрузка перестаёт что-либо значить.

Что из этого забирать себе

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

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

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