Стоимость исправления небольшого SaaS, созданного ИИ

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

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

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

Фиксированная цена появляется после ограниченной диагностики

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

Диагностика небольшого SaaS обычно занимает от 8 до 20 часов сосредоточенной инженерной работы. Для планирования подойдет диапазон от 1 000 до 3 000 долларов, если репозиторий запускается обычным способом, а владелец может объяснить ожидаемое поведение. Цена растет, когда никто не контролирует учетную запись развертывания, миграции нельзя выполнить в надежном порядке, схема базы отличается от репозитория или важная логика находится в визуальном конструкторе вне системы контроля версий.

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

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

Разработчик может собрать первый пакет доказательств обычными командами репозитория:

$ git status -s
 M src/auth/session.ts
?? notes/production-errors.txt

$ git ls-files | sed -n '1,12p'
.env.example
package.json
src/auth/session.ts
src/billing/webhook.ts
...

$ git log -1
commit a1b2c3d
Author: Example Developer
Date: Mon Jul 20 10:14:00 2026 +0000
    fix checkout callback

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

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

Работу оценивают по риску, а не по числу файлов

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

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

В полезной смете есть отдельная строка на каждый пакет. Диагностика за 1 000-3 000 долларов заканчивается заметками о воспроизведении и реестром находок по приоритету. Исправление безопасности за 1 500-6 000 долларов заканчивается проверками злоупотреблений и конкретных механизмов контроля. Исправление логики за 1 500-5 000 долларов заканчивается успешно пройденными приемочными сценариями.

Выборочный рефакторинг за 1 000-4 000 долларов должен уменьшить явно названную область изменений и сохранить поведение. Тестирование за 1 500-4 000 долларов дает автоматизированный набор для критических путей и отчет. Подготовка к развертыванию за 750-2 500 долларов дает повторяемый выпуск в тестовую или производственную среду и инструкции по откату. Пока диагностика не свяжет суммы с находками, это лишь диапазоны для планирования.

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

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

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

Для действительно небольшого приложения с ограниченными находками общая фиксированная цена при этих допущениях часто попадает в диапазон 7 000-18 000 долларов. Считайте его расчетным коридором для планирования, а не обещанием или рыночным ориентиром. Ремонт за 3 000 долларов разумен, если сбой изолирован, а развертывание уже работает. Смета на 30 000 долларов тоже может быть оправданной, если слово «небольшое» описывает интерфейс, но не права, состояния оплаты, очистку данных и риск выпуска.

Объем работ по безопасности следует границам доверия

Безопасность нужно оценивать по границам доверия и операциям с данными, а не по расплывчатому обещанию «усилить» код. Такое слово скрывает объем. В смете должны быть названы механизмы контроля и способы их проверки.

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

Стандарт OWASP Application Security Verification Standard дает основу для проверки механизмов безопасности веб-приложений и список требований к безопасной разработке. Я использую его как указатель охвата, а не утверждаю, что небольшому SaaS нужны все требования. Выберите применимые пункты, запишите версию и привяжите конкретные тесты. Такой подход честнее неопределенной «проверки по OWASP».

Находки безопасности, которые часто расширяют смету:

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

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

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

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

Исправлению логики предшествует продуктовое решение

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

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

Перед оценкой я превращаю каждый сценарий в короткий список решений:

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

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

Для небольшого приложения с двумя-четырьмя поврежденными основными сценариями подойдет плановый диапазон 1 500-5 000 долларов. Нижняя граница относится к локальным ошибкам состояния или проверки с ясными приемочными случаями. Верхняя относится к поведению, распределенному между состоянием браузера, обработчиками API, триггерами базы и внешними обратными вызовами. Добавьте стоимость, если нужно исправлять производственные данные: безопасное обновление требует пробных запусков, подсчета строк, резервных копий, идемпотентности и плана отмены.

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

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

Рефакторингу нужна причина, связанная с ремонтом

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

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

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

Целевой рефакторинг небольшой кодовой базы может занять 8-30 часов и стоить 1 000-4 000 долларов по используемой здесь модели. Определите его через границу и результат: «централизовать авторизацию для маршрутов проектов и счетов, сохранить разрешенное поведение и пройти матрицу доступа». Не пишите «улучшить архитектуру» или «почистить спагетти-код». Завершение таких формулировок невозможно доказать.

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

Рефакторинг не должен становиться налогом за то, что код создала ИИ-система. Оплачивать нужно работу, которая меняет результат. Безвредную некрасивость лучше оставить.

Тесты доказывают завершение сметы

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

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

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

Краткая приемочная запись может выглядеть так:

AC-07 Cross-tenant project read
Given: user A belongs to tenant A; project B belongs to tenant B
When:  user A requests the project B identifier through the API
Then:  response is 404; no project fields are returned; denial is logged
Evidence: integration test authz.projects.spec, run 184, passed

Запись выполняет три задачи. Она сообщает разработчику, что нужно построить, дает заказчику проверяемую границу завершения и сокращает споры о том, считается ли скриншот доказательством. Для смет такого размера 1 500-4 000 долларов часто покрывают настройку тестов и критические случаи. Цена растет, когда код не дает точек для тестирования, внешние сервисы не имеют безопасных тестовых режимов или асинхронной работе требуется детерминированное управление.

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

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

Развертывание входит в ремонт

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

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

Сборка, выпуск и выполнение разделены в модели Twelve-Factor. Различие обнаруживает частый сбой приложений, созданных ИИ: скрипт сборки обращается к живой базе, миграция запускается при каждом старте процесса или производственная конфигурация попадает в открытый пакет браузера. При ремонте каждое действие нужно поместить на правильный этап и доказать, что новый выпуск создается из проверенного коммита.

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

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

Фраза «развертывание включено» не должна означать однократное нажатие кнопки. Результатом становится выпуск, который другой компетентный специалист сможет понять и повторить.

Некоторые находки требуют пересмотра сметы

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

Я использую такие условия:

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

Каждое условие должно определять дальнейшие действия. Исполнитель приостанавливает затронутый пакет, показывает доказательства, объясняет варианты и оценивает только разницу. Незатронутая работа может продолжаться, если это безопасно. Заказчик должен иметь право отказаться от изменения и получить уже оплаченную завершенную работу и заметки.

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

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

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

Обоснованная смета показывает расчет

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

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

• 1 500 долларов на диагностику и реестр находок;
• 3 200 долларов на исправление авторизации и секретов;
• 2 800 долларов на исправление логики подписки;
• 1 400 долларов на необходимый для этих исправлений рефакторинг;
• 3 800 долларов на тесты критических сценариев, тестовый выпуск и инструкцию.

Фиксированная общая сумма составит 12 700 долларов.

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

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

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

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

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

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