Этот вопрос уже задавали, и ответ был плохой
10 сентября 2024 года конструктор сайтов Wix объявил, что с 12 сентября блокирует все аккаунты пользователей из России, платные и бесплатные, а сайты снимает с публикации. Два дня на то, чтобы что-то сделать. Владельцам предложили перенести домен к другому регистратору. Домен перенести можно, сайт нет: конструктор не отдаёт работающий магазин, он отдаёт выгрузку.
За два года до этого, 8 марта 2022 года, Shopify объявил о приостановке работы в России и Беларуси. Магазины на нём остались без платежей, а значит, без продаж.
В обоих случаях сервис не разорился и не сделал ничего плохого по своим правилам. Решение приняли снаружи, владельцы магазинов узнали о нём из новостей, и результат был один: вчера сайт был, сегодня его нет. Подрядчики поменьше исчезают по более обычным причинам: студия распалась, сервис продали, направление закрыли как нерентабельное. Новостей об этом не пишут, но для владельца магазина итог тот же.
Худший сценарий по четырём моделям
Конструктор. Остаётся выгрузка: товары и заказы в таблицах, если успели их сделать. Дизайн, настройки, история покупателей и сама система остаются у сервиса. С точки зрения владельца это худший из четырёх вариантов, и случай Wix показал его буквально.
Коробка. Здесь честно сказать, что это надёжнее конструктора. Сайт работает на вашем хостинге, лицензия бессрочная, доработки лежат в вашей папке, а студий под Битрикс много, и замену найти можно. Риск в другом: обновления ядра приходят от вендора, и без продления лицензии вы остаётесь на той версии, что есть. И знание о том, как именно ваш магазин доработан, живёт в голове у людей из прежней студии.
Разработка с нуля. Код ваш целиком, и это плюс. Минус в том, что кроме команды-автора его никто не читал. Документации часто нет, стек выбирала команда под себя, и новый подрядчик несколько месяцев разбирается, что тут вообще написано, прежде чем починить первую ошибку. Про «код, который помнит один уволившийся разработчик» мы говорим не для красного словца: так выглядит половина заказных систем через три года.
Ядро с внедрением. Здесь ответ целиком зависит от договора, и это главное, что нужно понять: у этой модели нет худшего сценария «по умолчанию». Он либо прописан, либо нет. Дальше про то, что именно должно быть прописано.
Худший сценарий нельзя обещать. Его можно только показать: где работает система, что написано в договоре про код, на каком стеке она написана и что лежит в документации.
Четыре пункта, которые надо прочитать до подписи
Первый: где работает система. Правильный ответ: на вашей инфраструктуре, с вашими доступами, без зависимости от серверов и аккаунтов подрядчика. Если система стоит у подрядчика «для удобства», в худшем сценарии она исчезает вместе с ним, и неважно, что написано про код.
Второй: что написано про исходный код. Условия передачи кода и бессрочного использования должны быть в лицензионном договоре, и этот пункт нужно прочитать до подписания. Формулировки «код может быть передан по отдельному соглашению» и «код передаётся» это разные пункты.
Третий: на чём написана система. Стек должен быть массовым, таким, под который на рынке тысячи разработчиков и десятки команд. Экзотический язык или собственный фреймворк подрядчика превращают ваш код в код, который есть, но который некому поддерживать. Это единственный из четырёх пунктов, который нельзя исправить договором.
Четвёртый: что лежит в документации. Архитектура, описание API и инструкции по развёртыванию должны передаваться вместе с проектом, а не существовать в голове. Попросите показать документацию до договора: у подрядчика, который её ведёт, она есть на предыдущих проектах.
Как худший сценарий выглядит у нас
Skuby разворачивается в вашем контуре, на вашей инфраструктуре и с вашими доступами. Исходный код и условия бессрочного использования прописаны в лицензионном договоре. Стек массовый: .NET, PostgreSQL, Vue и Nuxt, под них в России тысячи разработчиков, и любая команда подхватит проект. Вместе с проектом передаются архитектура, контракт API в формате OpenAPI и инструкции по развёртыванию.
Обязательных платежей после запуска нет. Поддержка и развитие по отдельному договору, по желанию, и отказ от него ничего не отключает. Если завтра нас не станет, ваш магазин продолжит принимать заказы, а вы получите работающую систему на популярном стеке, исходники, документацию и свободный выбор, кто её развивает дальше.
Про границы, чтобы картина была честной. Новой команде всё равно потребуется время, чтобы войти в код: ядро большое, и «любой разработчик за день» мы не обещаем, документация сокращает этот срок, а не убирает его. Обновления ядра, которые мы выпускаем для всех клиентов, к вам без нас приходить перестанут, и развивать систему дальше будет ваша новая команда. И живой магазин на Skuby, который можно открыть и посмотреть, доказывает, что система работает, но не доказывает сценарий нашего исчезновения: его доказывает только договор.
Что проверить у себя
- Где физически работает ваш магазин и чьи доступы нужны, чтобы его перезапустить. Если ответ «у подрядчика», начните с этого.
- Что в текущем договоре написано про исходный код и что произойдёт с сайтом, если подрядчик закроется. Найдите пункт, а не спрашивайте менеджера.
- Сколько дней уведомления вам гарантировано. У Wix было два.
- Кто, кроме подрядчика, способен развернуть систему заново. Если никто, документации нет, что бы ни было написано в договоре.
Четыре ответа занимают полчаса, и после них вопрос «а что если вы исчезнете» можно задавать любому подрядчику предметно: не «обещаете ли», а «покажите пункт».