Стоимость первого релиза считают по циклу, а не по тарифу

Сравнивать цену пакета токенов, месячной подписки и сметы подрядчика напрямую нельзя. У них разные единицы продажи, а первый релиз покупает не токены, доступ к чату или часы разработчика. Он покупает одну работающую функциональность, которую можно показать пользователю, проверить, развернуть и исправить после первой обратной связи.

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

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

Сначала зафиксируйте, что именно считается релизом

Единица сравнения должна включать одинаковый результат для всех вариантов. Формулировка «сделать личный кабинет» слишком широка: один исполнитель посчитает форму входа, второй добавит восстановление пароля, третий заложит роли, журнал действий и адаптацию под телефон. Разница в цене возникнет ещё до выбора способа разработки.

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

К функциональному контуру добавьте определение готовности. Для первого релиза обычно достаточно следующих условий:

• основной сценарий работает в целевом браузере или на целевом устройстве;
• данные сохраняются и не смешиваются между пользователями;
• ошибки не показывают пользователю внутренние данные;
• есть рабочее развёртывание и способ вернуться к предыдущей версии;
• владелец получил исходный код, доступы и короткую инструкцию по запуску.

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

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

Цена тарифа скрывает стоимость полного цикла

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

C_release = C_access + C_generation + C_people + C_review
          + C_rework + C_infra + C_release_ops + C_risk

C_access включает подписку или минимальный платёж за доступ. C_generation покрывает токены, кредиты и платные повторные запуски. C_people переводит часы владельца, аналитика, дизайнера и разработчика в деньги. C_review отделён намеренно: проверка результата требует другой квалификации и часто становится узким местом. C_rework хранит цену исправлений после проверки. C_infra включает среду выполнения, базу, файлы и другие обязательные ресурсы. C_release_ops покрывает публикацию, домен, резервное копирование и наблюдение за первым запуском. C_risk нужен только для известных неопределённостей, а не как произвольная наценка «на всякий случай».

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

cash_cost = внешние платежи
economic_cost = cash_cost + часы команды * внутренняя ставка

Разделение снимает частый спор. Вариант на отдельных LLM-кредитах может выиграть по денежному расходу и проиграть по экономической стоимости. Для команды с сильным инженером и свободным временем это приемлемо. Для предпринимателя без технического партнёра дешёвые токены превращаются в дорогой курс разработки на собственном проекте.

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

Калькулятор начинается с измеряемых входных данных

Хороший калькулятор не спрашивает, какой вариант вам нравится. Он собирает одинаковые факты о работе и только затем применяет разные модели оплаты. Удобно завести по одному столбцу на вариант и начать с четырёх строк:

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

Оставшиеся четыре строки описывают путь от первой проверки до работающего выпуска:

• исправления: ожидаемые циклы умноженные на цену цикла;
• инфраструктура: платежи до конца выбранного периода;
• выпуск: настройка, публикация и первичная проверка;
• риск: вероятность события умноженная на цену последствия.

Последняя строка требует дисциплины. Вместо резерва в 30 процентов напишите событие: «схема авторизации не подойдёт, вероятность 0,25, переделка займёт 16 часов». Тогда риск равен четырём ожидаемым часам. Оценка вероятности всё ещё субъективна, зато команда может оспорить обе составляющие и позже сравнить прогноз с фактом.

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

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

Полезно считать точку безубыточности. Если подписка стоит S, переменная цена функции в ней равна V_s, а работа через API стоит V_a, то минимальное число функций для окупаемости подписки:

N_break_even = S / (V_a - V_s)

Формула имеет смысл только при V_a > V_s и одинаковом результате. Если подписка сокращает ещё и человеческие часы, добавьте их денежную разницу в знаменатель. Именно время, а не токены, часто меняет выбор.

LLM-кредиты дешевы только при наличии инженерного контура

Прямая оплата LLM хороша, когда команда уже умеет собирать приложение вокруг модели. Вы платите за запросы и сохраняете свободу выбора инструментов, архитектуры и инфраструктуры. Но модель выдаёт текст или код, а не принятый релиз. Между ответом модели и работающей функцией остаются репозиторий, зависимости, база, секреты, тесты, развёртывание и разбор ошибок.

Стоимость генерации считайте по попыткам, а не по финальному объёму кода. Одна попытка включает входной контекст, ответ и иногда обращения к инструментам. Когда проект растёт, модели приходится повторно читать больше файлов. Неудачная правка может потребовать возврата состояния и нового запроса с расширенным объяснением. Поэтому средняя цена попытки из первых двух запросов плохо предсказывает последнюю треть работы.

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

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

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

LLM-кредиты выигрывают, когда требования меняются часто, инженер уже в команде, а созданный контур будет использоваться много раз. Они проигрывают, когда заказчик не может проверить результат и покупает отдельными запросами компетенцию, которой у него пока нет.

Подписка на AI-среду покупает связность работы

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

В калькуляторе разделите подписку на включённую ёмкость и превышение лимитов. Укажите, сколько кредитов или операций входит в тариф, что происходит после исчерпания и переносится ли остаток. Не предполагайте, что слово «безлимит» покрывает любую нагрузку. Условия конкретного сервиса нужно читать перед расчётом, потому что лимиты и состав тарифов меняются.

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

Для подписки важны четыре вопроса:

• можно ли получить исходный код и продолжить работу вне среды;
• кто контролирует развёртывание, домен и данные;
• есть ли снимки состояния и понятный возврат после плохой правки;
• какие части выпуска всё равно требуют специалиста.

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

TakProsto объединяет чат, планирование, экспорт исходного кода, развёртывание, хостинг, собственные домены, снимки и откат, поэтому в его колонке калькулятора эти работы нельзя автоматически дублировать как внешние услуги. При этом цену ревью и ваши часы на формулировку требований всё равно следует оставить.

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

Подрядчик продаёт ответственность только в границах договора

Подрядчик может дать самый предсказуемый результат, если объём работы описан достаточно точно, а смета включает приёмку и выпуск. Вы покупаете не часы печати кода, а чужую практику: специалист выбирает архитектуру, замечает противоречия, проверяет крайние случаи и отвечает на вопросы после демонстрации. Хороший подрядчик сокращает число ваших технических решений.

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

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

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

Попросите оценить не только счастливый путь, но и два отказа: пользователь вводит неверные данные, а внешняя зависимость недоступна. По реакции видно качество оценки. Исполнитель, который включил обработку ошибок, назовёт конкретное поведение. Если в ответ звучит только «разберёмся по ходу», внесите резерв на уточнение.

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

Ревью и исправления нельзя прятать в одной строке

Ревью отвечает на вопрос «достаточно ли хорош результат», а исправление меняет результат после ответа. Если объединить их, калькулятор не покажет, где ломается процесс. Вы можете часами проверять слабую генерацию или быстро находить один и тот же дефект после каждой переделки. Лекарства разные.

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

Для небольшой функции используйте журнал циклов:

cycle, reason, owner_hours, reviewer_hours, paid_credits, result
1, missing_case, 1.0, 0.5, 420, rejected
2, access_bug, 0.5, 1.2, 610, rejected
3, accepted, 0.3, 0.6, 260, accepted

Это не эталонные значения, а форма записи. Подставляйте фактические данные. Через несколько функций журнал даст собственную среднюю цену попытки и покажет, какой процент циклов вызван неполным заданием, ошибкой реализации или новой идеей.

Не назначайте одну ставку всем часам. Время основателя, младшего разработчика и специалиста по безопасности имеет разную альтернативную цену. Но и не усложняйте модель десятью ролями ради видимости точности. Отдельная ставка нужна, если её изменение способно поменять решение.

Популярная рекомендация «заложить две итерации» слаба. Число итераций зависит от размера изменения и силы обратной связи. Лучше ограничить размер цикла: одна проверяемая правка, один набор критериев, один результат. Тогда неудачу можно отменить без потери соседней работы, а калькулятор получает повторяемую единицу.

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

Инфраструктура начинается раньше первого пользователя

Инфраструктурные расходы появляются в момент, когда результат должен работать вне компьютера автора. Даже у маленького релиза есть среда выполнения, хранилище данных, секреты, домен, резервная копия и способ увидеть ошибку. Некоторые позиции могут входить в платформу или услугу подрядчика, но калькулятор обязан показать, кто их предоставляет.

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

Разовые операции переводите в часы: создать окружение, настроить переменные, применить схему данных, подключить домен, проверить резервное восстановление и описать выпуск. Даже когда хостинг входит в подписку, человеку нужно решить, какие данные хранить и кто получит доступ. Встроенная кнопка сокращает операцию, но не принимает решение.

Следите за двойным счётом. Если подрядчик передаёт развёрнутый сервис и первый месяц инфраструктуры входит в смету, не добавляйте эти позиции снова. Если AI-среда включает хостинг, но внешний сервис отправки сообщений оплачивается отдельно, добавьте только внешний сервис. У каждой строки должен быть поставщик и подтверждение цены.

Цена выхода относится к инфраструктуре так же, как ежемесячный платёж. Спросите, можно ли выгрузить данные в понятном формате, поднять код в другой среде и перенести домен. Не нужно заранее оплачивать миграцию. Достаточно оценить часы и вероятность, если продолжение проекта действительно возможно.

Для чувствительных данных добавьте ограничения как условия, а не как красивые обещания. Где физически обрабатываются данные, какое ПО участвует, кому доступны журналы и резервные копии? Если вариант не проходит обязательное ограничение, калькулятор должен исключить его, а не компенсировать риск низкой ценой.

Нулевая строка инфраструктуры допустима только для макета, который никто не использует и который не хранит настоящие данные. Если вы называете результат релизом, проверьте хотя бы восстановление предыдущей рабочей версии. Первый неудачный выпуск быстро объясняет цену этой операции, но лучше узнать её до пользователя.

Один пример показывает, где меняется победитель

Возьмём условную функцию из начала статьи и горизонт в один месяц. Все числа ниже служат примером работы калькулятора, а не рыночными тарифами. Внутренняя ставка владельца равна 2 000 рублей в час, технического проверяющего 3 500 рублей. Для каждого варианта команда вводит наиболее вероятный сценарий.

Статья                  LLM-кредиты   AI-среда   Подрядчик
Доступ и генерация      6 000         18 000     0
Часы владельца          18            10         8
Часы проверяющего       12            7          3
Исправления деньгами    0             0          25 000
Инфраструктура и выпуск 14 000        3 000      12 000
Фиксированная работа    0             0          150 000

Экономическая стоимость LLM-кредитов равна 6 000 + 18 * 2 000 + 12 * 3 500 + 14 000 = 98 000 рублей. Для AI-среды получится 18 000 + 10 * 2 000 + 7 * 3 500 + 3 000 = 65 500 рублей. Подрядчик даст 8 * 2 000 + 3 * 3 500 + 25 000 + 12 000 + 150 000 = 213 500 рублей.

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

Теперь посчитайте границы. При какой ставке проверяющего LLM-вариант сравняется со средой? Разница остальных затрат равна 8 500 рублей в пользу LLM, а разница ревью равна пяти часам. Уже при ставке выше 1 700 рублей за час среда выходит дешевле. Такой порог полезнее спора о том, дорогая ли подписка.

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

Не публикуйте эту таблицу как обещание бюджета. Скопируйте структуру и заполните собственными тарифами, ставками и наблюдениями. После релиза замените прогноз фактом. Вторую функцию вы посчитаете заметно точнее.

Выбор зависит от дефицита команды

Выбирайте отдельные LLM-кредиты, если у вас уже есть инженерный процесс и человек, который отвечает за архитектуру и выпуск. В этом случае гибкость API и инструментов окупает ручную сборку. Первая функция несёт долю настройки, последующие используют готовую основу.

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

Выбирайте подрядчика, если внутри нет технического владельца, функция имеет чёткие границы, а ошибка дороже согласований. Зафиксируйте результат, порядок изменений, приёмку, передачу кода и поддержку. Не покупайте фиксированную смету для задачи, которую планируете переосмысливать каждый день.

Гибрид часто честнее чистого варианта. Владелец может собрать прототип в AI-среде, затем заказать техническое ревью и сложную часть специалисту. Инженер может использовать прямые LLM-вызовы, а инфраструктуру оставить управляемой платформе. Подрядчик может получить проверенный интерактивный сценарий вместо длинного документа. В калькуляторе такой путь записывается отдельной колонкой, а не размазывается по трём.

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

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

Решение принимают после короткого платного теста

Финальную оценку лучше строить на одном вертикальном фрагменте функции, который проходит через интерфейс, логику, данные и публикацию. Не просите сделать красивый экран без сохранения: такой тест проверяет только генерацию разметки. Выберите маленький сценарий, например создание одного проекта с проверкой владельца и повторным чтением из базы.

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

После теста обновите только измеренные строки. Не снижайте резерв по остальным пунктам из-за общего хорошего впечатления. Если сценарий прошёл быстро, но проверяющий нашёл нарушение доступа, увеличьте оценку технической части. Если подрядчик задал десять точных вопросов до начала, его оплаченная аналитика может уменьшить будущие переделки.

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

Не переносите цену первого релиза на весь продукт. На старте отдельные кредиты несут разовую настройку, подписка может вместить несколько следующих функций, а подрядчик набирает знание о проекте. После каждого законченного контура меняются скорость, качество требований и стоимость проверки. Калькулятор должен жить вместе с проектом.

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