Сначала — обнадёживающий и проверяемый факт: в сгенерированном приложении каждая зависимость зафиксирована на точной версии — не в виде диапазона совместимости, не как «последняя подходящая», а строго по номеру, например `next@14.2.3`, `react@18.2.0`, `prisma@5.12.0`. Поэтому через два года приложение установится идентично первоначальному и не сломается само по себе. Обслуживание требуется лишь для трёх независимых компонентов: исправлений безопасности библиотек, хостинга и ваших собственных бизнес-изменений. Пока приложение работает по включённому в пакет URL, первые два пункта вам ничего не стоят; как только вы начинаете размещать его на собственном сервере или править код — оно превращается в обычное программное обеспечение. А поскольку код написан на стандартном Next.js и Prisma и принадлежит вам, любой разработчик сможет взять его в работу.
Работающее приложение не деградирует само по себе
Интуитивно кажется, что программное обеспечение «стареет» и со временем ломается само собой. На деле так не бывает. В `package.json` сгенерированного приложения каждая зависимость зафиксирована на точной версии — не в виде диапазона совместимости и не как «последняя совместимая версия». Указывается полный идентификатор версии, например `react@18.2.0` или `next@14.2.3`. При повторной установке через два года воссоздастся точно такое же дерево библиотек, как в первый день, а сам код останется неизменным — ни единого байта.
Деградирует окружение: истекающий SSL-сертификат, миграция сервера, устаревание версии Node.js у хостинг-провайдера и, главное, отсутствие исправлений безопасности для зафиксированных версий. Это принципиально иная ситуация по сравнению с «ломающимся ПО», и она полностью меняет подход к планированию.
Три разных вида обслуживания, которые часто путают
Первый — БЕЗОПАСНОСТЬ библиотек: обнаружение уязвимости в одной из зависимостей требует обновления её версии. Это единственный вид обслуживания, который имеет «обратный отсчёт» и не зависит от вашей деятельности.
Второй — ХОСТИНГ: домен, сертификат, база данных, резервные копии. Пока приложение доступно по включённому в пакет URL, всё это обеспечивает платформа — и именно этот вопрос стоит задать чётко, как любому поставщику услуг: какова политика резервного копирования и с какой частотой она выполняется. Как только вы переносите приложение на свой сервер, ответственность за этот блок целиком переходит к вам.
Третий — это вовсе не обслуживание, а РАБОТА: добавление поля, статуса или экрана из-за изменений в вашем бизнесе. Такие изменения происходят только по вашей инициативе и решаются в своём масштабе — об этом подробно рассказывается в руководстве «Как развивать своё приложение».
Кто может это сделать и почему никто вас не держит в заложниках
Код написан на стандартном Next.js и Prisma, его можно экспортировать в ZIP-архив или загрузить на GitHub — он полностью принадлежит вам. Нет ни проприетарных диалектов, ни форматов, которые может корректно интерпретировать и поддерживать только поставщик.: специалист, берущий проект в работу, использует знакомые инструменты — именно поэтому передача возможна без нашего участия. Это полная противоположность закрытым решениям, где вопрос «кто будет поддерживать?» имеет лишь один ответ — поставщик, пока он существует.
Обратная сторона честна: как только вы сами начинаете править код, запущенная версия перестаёт быть той, которую платформа умеет регенерировать. Вы получаете полную свободу — и вместе с ней берёте на себя обязательства по обслуживанию. Многие небольшие компании никогда не делают этого шага — и им это не нужно. Но возможность остаётся открытой, и именно это важно, когда вы решите ею воспользоваться.
Что действительно нужно предусмотреть в бюджете
Для заказного ПО отраслевая литература оценивает затраты на корректирующее сопровождение в размере около 15–20 % от стоимости первоначальной разработки в год, а совокупные расходы на сопровождение и функциональное развитие — примерно в половину общей стоимости владения за пять лет. Именно эту статью почти никто не закладывает в бюджет — и именно она превращает успешный проект в заброшенный инструмент спустя три года.
Расчёты меняются, когда первоначальная стоимость мала, а хостинг включён в пакет: пока приложение работает «как есть», резервировать ничего не нужно. Затраты возникают строго в двух случаях — если вы переносите хостинг на собственную инфраструктуру или заказываете изменения кода. Принимать решение, осознавая эти две точки ветвления, разумнее, чем оплачивать страховку от сбоев, которых при зафиксированных версиях просто не бывает.