Как выбрать подрядчика для разработки личного кабинета: 7 вопросов, которые отсеют слабых исполнителей
Почему выбор подрядчика для личного кабинета устроен иначе, чем для обычного сайта
Если вы ищете, кому заказать разработку личного кабинета, сравнивать исполнителей по портфолио и цене недостаточно. Витрина сайта видна глазами: красиво или нет, быстро или нет. Личный кабинет почти целиком состоит из того, чего глазами не увидеть: кто и какие данные имеет право видеть, как защищён вход, что происходит при сбое интеграции с учётной системой, кто сможет развивать продукт, когда подрядчик уйдёт. Эти вещи проверяются вопросами и документами, а не скриншотами.
На сайте уже есть общая статья «7 вопросов подрядчику до аванса»: она подходит для любого проекта и отвечает на вопросы про этапы, команду, стек и состав цены. Здесь мы не повторяем её, а берём то, что специфично именно для личного кабинета клиента: ролевую модель, безопасность входа, интеграции с CRM и 1С, перенос пользователей, права на код, метрики приёмки и поддержку. А про стоимость, состав работ и ориентиры по срокам подробно написано в статье «Разработка личного кабинета: что входит и сколько стоит»; ниже мы только сверяем с ней цифры.
Статья честная в одном важном смысле: мы не утверждаем, что наши ответы единственно правильные. Каждый вопрос построен так, чтобы вы могли проверить по нему любого исполнителя, включая нас, а в конце каждого блока показываем, как отвечаем мы, опираясь только на то, что опубликовано на странице услуги. Если подрядчик не готов отвечать на такие вопросы конкретно, это уже информация, независимо от того, кто он.
Вопрос 1. Как вы проектируете роли и права доступа и кто это проверяет
Ролевая модель и права доступа — фундамент кабинета. От неё зависит, что увидит розничный клиент, что оптовый, что дилер, что менеджер клиента и что сотрудник вашей компании. Если права «навешиваются» в конце, когда экраны уже нарисованы, в логике доступа остаются дыры, которые находят уже после запуска.
Зачем спрашивать
Ошибка в правах доступа — самый неприятный тип ошибки в кабинете: интерфейс работает, заказы создаются, а клиент по подменённому адресу или номеру видит чужие документы. Это не вопрос дизайна и не видно на демо, пока кто-то специально не проверил. Поэтому важно узнать, когда и как подрядчик проектирует доступ и как его потом проверяет.
Какой ответ хороший
Подрядчик называет этап, на котором роли описываются письменно (таблица «роль, раздел, действие, разрешено или нет»), до дизайна. Объясняет, что права проверяются на сервере, а не только скрываются кнопками в интерфейсе. Отдельно говорит о тестировании прав: что именно проверяется (попытка открыть чужую запись, чужой документ, чужую цену) и кто это делает. Показывает пример такой матрицы из прошлого проекта, пусть обезличенный.
Красный флаг
«Роли сделаем по ходу, это несложно» или «разделим на админа и пользователя, этого хватит». Ещё хуже, если на вопрос о проверке прав подрядчик отвечает про то, что «у нас всё закрыто паролем». Пароль отвечает за вход, а не за то, что человек увидит после него.
Как отвечаем мы
На странице услуги модель ролей и прав доступа входит в состав работ, а проектирование сценариев кабинета — до дизайна. В этапе тестирования заявлена проверка прав доступа, интеграций и устройств. Количество ролей напрямую влияет на стоимость, поэтому его фиксируем на брифе, а не обещаем «любые роли без доплат».
Вопрос 2. Как защищены вход и данные пользователей
Личный кабинет почти всегда работает с персональными данными, а значит, подрядчик отвечает не только за функциональность, но и за то, чтобы данные не утекли. Здесь полезно получить конкретные ответы вместо общего «у нас всё безопасно».
Зачем спрашивать
Вход и восстановление доступа — самые атакуемые места любого кабинета. OWASP в справочнике по аутентификации описывает ограничение числа попыток входа как способ защиты от подбора пароля и советует привязывать счётчик неудачных попыток к учётной записи, а не только к IP-адресу, иначе атакующий меняет адреса. Там же многофакторная аутентификация названа одной из самых сильных защит от атак на пароли. Это ориентиры, по которым можно проверять любую команду. Кроме того, оператор персональных данных по статье 19 закона 152-ФЗ обязан принимать правовые, организационные и технические меры защиты данных от неправомерного и случайного доступа, уничтожения, изменения, копирования и распространения, и заказчик кабинета, как правило, именно оператор.
Какой ответ хороший
Подрядчик перечисляет конкретные меры: шифрование соединения (HTTPS), медленное хеширование паролей с солью (а не хранение паролей и не быстрые хеши вроде обычного SHA), ограничение попыток входа, защита от типовых веб-атак (CSRF и XSS), безопасное восстановление доступа с одноразовыми ссылками ограниченного срока. Говорит, где в кабинете нужна двухфакторная аутентификация и где она избыточна, и не обещает её «по умолчанию и бесплатно». Объясняет, где будут храниться данные и кто имеет доступ к серверу и базе. По 152-ФЗ честно говорит, что делает команда (проектирует кабинет так, чтобы его можно было эксплуатировать в соответствии с требованиями), а что остаётся на стороне заказчика как оператора (политика обработки, согласия, уведомления).
Красный флаг
«Безопасность у нас на высоком уровне» без перечня мер. «Соответствие 152-ФЗ гарантируем», без объяснения, как именно и в чём граница ответственности: закон возлагает обязанности на оператора, и ни один подрядчик не может снять их с вас простой фразой. Подозрительно также, если на вопрос, как хранятся пароли, отвечают «в базе, но она закрыта».
Как отвечаем мы
В опубликованный состав работ по кабинету входят HTTPS, защита от CSRF и XSS, хеширование паролей (bcrypt), ограничение попыток входа, авторизация и восстановление доступа, хранение и защита персональных данных и соответствие 152-ФЗ в части технических мер, зависящих от исполнителя (обязанности оператора — политика, согласия, процессы — остаются у заказчика). Чего в составе нет отдельной строкой: двухфакторной аутентификации и независимого пентеста. Если они нужны вам, их нужно прописать в ТЗ и смете; требования к защите конкретного проекта мы фиксируем в ТЗ и договоре после брифинга.
Вопрос 3. Как будут устроены интеграции с CRM, 1С и платёжной системой
Кабинет без интеграций быстро превращается в витрину с устаревшими данными, которую приходится обновлять вручную. Интеграции — самый трудоёмкий пласт работы и один из главных факторов стоимости, поэтому именно здесь чаще всего прячутся расхождения между КП и реальностью.
Зачем спрашивать
Запросы «интеграция личного кабинета с 1С» и «с CRM» звучат как одна галочка, но за ними несколько разных работ: какие данные и в каком направлении ходят, как часто, что происходит, если учётная система недоступна или вернула ошибку, как обрабатываются конфликты (заказ изменили и в кабинете, и в 1С). У каждой учётной системы свои особенности, и оценка «подключим 1С» без изучения вашей конфигурации ни о чём не говорит.
Какой ответ хороший
Подрядчик просит доступ к описанию или тестовой копии вашей системы до оценки, а не после. Описывает схему обмена: что синхронизируется, в какую сторону, по расписанию или по событию. Объясняет, что показывает кабинет пользователю, если обмен не удался (сообщение, последние известные данные с отметкой времени), и как о сбое узнают ваши сотрудники. Отдельно называет, что считается «подключением» в смете: список конкретных объектов (контрагенты, заказы, остатки, документы), а не «интеграция с 1С» целиком.
Красный флаг
Фиксированная цена интеграции, названная до знакомства с вашей системой. Ответ «подключим по API, это стандартно» без вопросов о версии и конфигурации. Отсутствие ответа на вопрос «что увидит клиент, если 1С не отвечает».
Как отвечаем мы
В составе работ по кабинету заявлены интеграции с CRM, учётной системой (например, 1С), платёжным сервисом, а при необходимости со складской системой. Набор систем фиксируется на брифе и закладывается в договор до старта; стоимость растёт с их количеством и сложностью подключения. Поэтому нижняя граница «от 900 000 ₽» относится к минимальному набору интеграций, а верхнюю границу мы заранее не обещаем.
Вопрос 4. Как вы переносите существующих пользователей и данные
Этот вопрос задают реже всего, а проблем из-за него больше всего. Если у вас уже есть клиенты в старом кабинете, в CRM или в таблицах, новый кабинет должен принять их без потерь и без требования «зарегистрируйтесь заново».
Зачем спрашивать
Миграция пользователей затрагивает сразу несколько рисков: потерю истории заказов и документов, дублирование аккаунтов, проблему с паролями (из старой системы их часто нельзя перенести в читаемом виде, и это нормально) и юридический вопрос: на каком основании вы переносите персональные данные в новую систему. Если миграции нет в плане и смете, её либо делают «на коленке» перед запуском, либо вы получаете доплату на последнем этапе.
Какой ответ хороший
Подрядчик спрашивает, откуда и в каком виде придут данные, оценивает объём и качество (дубли, пустые поля, разные форматы телефонов), предлагает пробный перенос на копии и сверку результата. Объясняет, как пользователи войдут в новый кабинет: например, по ссылке для установки нового пароля. Определяет, что происходит со старым кабинетом и когда он отключается, чтобы не оставлять две системы с разными данными.
Красный флаг
«Загрузим из Excel, это быстро» без разговора о качестве данных. Обещание «пользователи даже не заметят, пароли перенесём» без объяснения, как именно это сделано технически и безопасно. Полное молчание о миграции в КП, при том что у вас клиенты есть уже сегодня.
Как отвечаем мы
Отдельной строки про миграцию пользователей в опубликованном составе работ нет, поэтому прямо советуем: у любого подрядчика, включая нас, спрашивайте о ней письменно и просите вынести в смету отдельным пунктом. В нашем процессе источники данных и системы, с которыми нужна интеграция, разбираются на этапе брифа и аналитики (3-5 дней), а состав работ фиксируется в договоре до старта.
Вопрос 5. Кому принадлежат права на код и что вы получаете на руки
Это один из самых дорогих вопросов в долгосрочной перспективе: от ответа зависит, сможете ли вы развивать кабинет без прежнего подрядчика или останетесь привязаны к нему.
Зачем спрашивать
По статье 1296 ГК РФ исключительное право на программу или базу данных, созданную по договору на их создание, принадлежит заказчику, если договором между подрядчиком и заказчиком не предусмотрено иное. Это правило по умолчанию, но договор может от него отходить: в нём может быть сказано, что права остаются у исполнителя, а заказчику дана лишь лицензия. Поэтому важно прочитать условие в договоре, а не полагаться на «всё и так ваше». Второй слой вопроса — практический: права на код не помогут, если у вас нет самого кода, документации и доступов к хостингу, домену, репозиторию и сервисам.
Какой ответ хороший
В договоре прописаны передача исключительного права (или чёткие условия лицензии) и перечень передаваемого: исходный код в репозитории, который находится на вашей стороне, документация (как развернуть, как устроены роли, схема интеграций), доступы к сервисам и дизайн-система. Подрядчик заранее называет сторонние компоненты, на которых построен кабинет, и их лицензии (на них исключительное право не передаётся ни вам, ни подрядчику). Передача происходит при приёмке и не поставлена в зависимость от споров по другим вопросам.
Красный флаг
Договор, в котором прав на результат нет вообще или они «возникают после полной оплаты всех последующих работ». Репозиторий, который находится только в аккаунте подрядчика. Закрытая платформа или конструктор, из которого код нельзя вывести. Фраза «сопровождать можем только мы», сказанная как достоинство, а не как факт, который надо проверить.
Как отвечаем мы
На странице услуги заявлено: исходники, документация, доступы и дизайн-система передаются клиенту полностью, так что продолжать развитие можно с другой командой. В принципах компании это сформулировано как отказ строить бизнес на том, чтобы клиент не мог уйти. Условия договора мы, как и любой подрядчик, подписываем конкретно под проект, поэтому читайте именно тот текст, который получите.
Вопрос 6. Какие метрики приёмки вы фиксируете и как тестируете кабинет
Фраза «приёмка по ТЗ» звучит надёжно, но не отвечает на главное: что именно будет считаться, что кабинет работает хорошо. Без измеримых критериев приёмка превращается в спор о том, нравится или нет.
Зачем спрашивать
Если критерии успеха не записаны до старта, их придумывают после сдачи, обычно в пользу того, кто сильнее в споре. Для кабинета измеримыми бывают скорость отклика ключевых страниц, доля успешных входов и восстановлений доступа, время выполнения основного сценария (например, повторного заказа), доля заказов, дошедших до учётной системы без ручной правки. Что именно выбрать, зависит от задачи, но выбрать нужно до начала работ.
Какой ответ хороший
Подрядчик в брифе формулирует целевые показатели в цифрах и вписывает их в договор. Описывает план тестирования: проверка прав доступа, интеграций, устройств, а для проектов с высокой посещаемостью нагрузочное тестирование. Объясняет, что будет, если показатель не достигнут, и кто принимает решение о приёмке. Говорит, что не может сам провести независимую проверку безопасности, если это не входит в состав, и предлагает привлечь внешнего специалиста.
Красный флаг
«Приёмка по факту выполнения всех пунктов ТЗ» без критериев качества. Обещание «выдержит любую нагрузку» без цифр и условий теста. Ответ «тестируем сами, показывать отчёт необязательно». Отказ заранее обсуждать, что считать неудачей.
Как отвечаем мы
Один из наших принципов: метрика фиксируется до старта, а не после, то есть на первой встрече вместе с клиентом формулируется, что будет считаться успехом проекта в цифрах, и это попадает в бриф и договор. Процесс включает полное тестирование на реальных устройствах и нагрузочное тестирование для проектов с высокой посещаемостью, а также финальную приёмку клиентом; для кабинета на этапе тестирования заявлена проверка прав доступа и интеграций. Работаем спринтами с демонстрацией результата каждую неделю, рабочая версия доступна на стейджинге с первых недель. Независимого аудита безопасности (пентеста) в составе нет.
Вопрос 7. Что происходит после запуска: гарантия, поддержка, развитие
Личный кабинет не заканчивается релизом. Меняются форматы документов, API внешних сервисов, требования закона и бизнес-правила, а пользователи находят сценарии, о которых никто не думал. Вопрос о поддержке нужно задавать до подписания, а не когда что-то сломалось.
Зачем спрашивать
Гарантия и поддержка — разные вещи. Гарантия покрывает исправление ошибок, допущенных при разработке, в определённый срок. Поддержка включает мониторинг, обновления, реакцию на сбои и мелкие доработки. Если в договоре есть только слово «поддержка» без сроков и условий, вы не знаете, что получите, когда на третьей неделе после запуска перестанет работать выгрузка в 1С.
Какой ответ хороший
Подрядчик называет длительность гарантийного периода и объясняет, что считается гарантийным случаем (ошибка разработки), а что новой задачей. Отдельно описывает формат сопровождения: канал обращений, время реакции, кто отвечает, как считается стоимость. Говорит, как проходит передача знаний вашей команде или другому исполнителю, если вы решите уйти.
Красный флаг
«Поддержка бесплатно навсегда» (не бывает) или «после запуска вы нам не нужны» (скорее всего, придётся нужны). Гарантия без срока. Отсутствие ответа на вопрос, что вы получите, если подрядчик перестанет работать.
Как отвечаем мы
После запуска действует гарантийный период: исправляем ошибки, допущенные при разработке. Его точная длительность на сайте не опубликована и фиксируется в договоре. Дальнейшее сопровождение и новые функции обсуждаются отдельно, по договорённости, без единого фиксированного тарифа; часть клиентов переходит на постоянное сопровождение. После запуска мы также смотрим на метрику, зафиксированную в брифе, и при необходимости донастраиваем.
Чек-лист: что проверить в КП и договоре на разработку личного кабинета
Сохраните этот список и пройдите по нему с каждым претендентом. Отметьте, на что получили конкретный ответ, а на что общие слова.
1. Роли и права описаны письменно (таблица «роль, раздел, действие») и согласуются до дизайна.
2. Права проверяются на сервере; в плане тестирования есть попытки получить чужие данные.
3. Перечислены меры защиты входа: HTTPS, хеширование паролей, ограничение попыток входа, защита от CSRF и XSS, безопасное восстановление доступа.
4. Понятно, нужна ли двухфакторная аутентификация, и она либо включена в смету, либо осознанно отложена.
5. Разграничена ответственность по 152-ФЗ: что делает исполнитель, а что остаётся на вас как операторе (политика, согласия, процессы).
6. Для каждой интеграции указаны система, направление обмена, объекты данных и поведение при сбое.
7. Миграция существующих пользователей и данных вынесена отдельным пунктом: объём, способ входа в новый кабинет, пробный перенос, судьба старой системы.
8. В договоре прописана передача исключительного права (или лицензии) и перечень передаваемого: исходники, документация, доступы, дизайн-система.
9. Известны сторонние компоненты и их лицензии; репозиторий находится на вашей стороне.
10. Метрики приёмки записаны в цифрах до старта; указано, кто и как принимает результат.
11. В плане тестирования названы права доступа, интеграции, устройства и (если важна посещаемость) нагрузка; есть понимание, нужен ли независимый аудит безопасности.
12. Этапы и сроки расписаны, есть регулярные демо и рабочая версия на стейджинге до финальной сдачи.
13. Гарантийный период назван в днях или месяцах, указано, что он покрывает; формат дальнейшего сопровождения описан.
14. Исполнитель, который будет делать работу, назван: понятно, штатная это команда или субподряд.
Как сравнить несколько коммерческих предложений на личный кабинет
Когда на руках три предложения с ценами от «дёшево» до «очень дорого», самая частая ошибка — сравнивать итоговые суммы. Они сопоставимы только при одинаковом составе работ, а состав почти всегда разный.
Приведите предложения к одной таблице
Сделайте таблицу: по строкам — работы и условия из чек-листа выше (роли и права, безопасность, каждая интеграция, миграция, тестирование, передача кода и документации, гарантия, поддержка), по столбцам — подрядчики. Отмечайте не «есть/нет в тексте», а «указано конкретно / общие слова / отсутствует». Пустые клетки — это то, что вам либо придётся докупать, либо вы получите не такой результат, как ожидали.
Проверьте цену на разумность, а не на минимум
Для ориентира: у нас опубликована нижняя граница для формата «Веб-сервис с личным кабинетом» — от 900 000 ₽ и от 10 недель, и она зависит от числа ролей, глубины интеграций, объёма истории и документов, а также от того, строится кабинет с нуля или встраивается в существующий сайт. Если одно из предложений радикально ниже остальных при том же заявленном объёме, это повод выяснить, что именно не посчитано; если радикально выше, повод выяснить, что вы покупаете сверху. Рыночных средних цен на кабинеты мы не приводим: проверяемой статистики у нас нет, а чужие цены не наша тема.
Сравните не только список работ, но и способ работы
Спросите у каждого: как часто вы увидите результат, где можно будет посмотреть рабочую версию до сдачи, кто принимает решения по спорным вопросам, как будут фиксироваться изменения объёма. Подрядчик, который работает с регулярными демо и стейджингом, оставляет вам возможность поправить курс на второй неделе, а не на десятой.
Закрепите разговоры письменно
Всё, что вы услышали на встрече и что для вас важно (двухфакторная аутентификация, миграция, нагрузка, срок гарантии), должно оказаться в КП, ТЗ или договоре. Устные обещания к моменту приёмки забываются, а письменное можно предъявить обеим сторонам без обид.
Что фиксирует InnovateSoft: коротко и без обещаний сверх опубликованного
Чтобы вы могли сопоставить наши ответы с ответами других подрядчиков, приводим только то, что опубликовано на странице разработки личного кабинета под ключ и в общих принципах компании.
Цена и срок: формат «Веб-сервис с личным кабинетом» — от 900 000 ₽ и от 10 недель; точную цифру называем после брифинга, верхнюю границу заранее не обещаем. Состав работ, срок и стоимость фиксируются в договоре до старта. Этапы: бриф и аналитика (3-5 дней), прототип и структура (1 неделя), дизайн (2-3 недели), разработка и интеграции (3-6 недель, зависит от сложности), тестирование и запуск (1 неделя).
Что входит: проектирование сценариев до дизайна, модель ролей и прав доступа, авторизация и восстановление доступа, хранение и защита персональных данных, безопасность (HTTPS, защита от CSRF и XSS, хеширование паролей bcrypt, ограничение попыток входа, соответствие 152-ФЗ в части технических мер исполнителя), интеграции с CRM, учётной системой, платёжным сервисом и при необходимости складом, админка, тестирование и запуск, базовая настройка аналитики.
Метрики: целевые показатели формулируются вместе с клиентом на первой встрече и попадают в бриф и договор; после запуска смотрим на метрику, зафиксированную в брифе, и при необходимости донастраиваем. Работаем двухнедельными спринтами с показом результата каждую неделю.
Передача: исходники, документация, доступы и дизайн-система передаются клиенту полностью. Гарантия: после запуска исправляем ошибки разработки; длительность периода фиксируется в договоре; сопровождение и новые функции обсуждаются отдельно.
Чего на опубликованной странице нет, и что мы поэтому не обещаем заранее: отдельной строки про миграцию пользователей, двухфакторной аутентификации, независимого пентеста, единой цены на поддержку. Всё это обсуждается на брифе и фиксируется в смете, если нужно именно вам. Если кабинет нужен как часть интернет-магазина или B2B-каталога, смежный формат описан на странице создания сайта каталога.
Как использовать эти вопросы на практике
Лучший формат — письменный список из семи вопросов, отправленный нескольким подрядчикам до личной встречи. Сравните не уверенность тона, а конкретику ответов: названы ли меры, этапы, документы, сроки. Подрядчик, у которого процесс уже отлажен, отвечает на такие вопросы за час; тот, у кого его нет, начинает импровизировать или уходит от ответа. Это само по себе полезный фильтр, и сработает он на любой студии, а не только на тех, кого вы подозреваете заранее.
Если вы только оцениваете, нужен ли вам кабинет и в каком составе, начните со статьи «Разработка личного кабинета: что входит и сколько стоит», а затем возвращайтесь к этому списку. Подробнее о форматах и ориентирах по цене и сроку всех сайтов — на странице создания сайтов под ключ.
Источники
Гражданский кодекс РФ, статья 1296 «Произведения, созданные по заказу» (часть четвёртая), п. 1: исключительное право на программу для ЭВМ, базу данных или иное произведение, созданное по договору, предметом которого было создание такого произведения, принадлежит заказчику, если договором между подрядчиком (исполнителем) и заказчиком не предусмотрено иное. https://legalacts.ru/kodeks/GK-RF-chast-4/razdel-vii/glava-70/statja-1296/
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 19 «Меры по обеспечению безопасности персональных данных при их обработке», ч. 1: оператор обязан принимать необходимые правовые, организационные и технические меры (или обеспечивать их принятие) для защиты персональных данных от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий. https://legalacts.ru/doc/152_FZ-o-personalnyh-dannyh/glava-4/statja-19/
OWASP Cheat Sheet Series — Authentication Cheat Sheet: ограничение числа попыток входа (throttling и блокировка) как защита от подбора пароля, с привязкой счётчика неудачных попыток к учётной записи, а не только к IP-адресу; многофакторная аутентификация описана как одна из самых сильных защит от атак на пароли. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
OWASP Cheat Sheet Series — Password Storage Cheat Sheet: пароли не хранят в открытом виде; рекомендуются медленные хеши с солью (Argon2id, scrypt, bcrypt), быстрые хеши вроде SHA-256 для паролей не подходят. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Частые вопросы
Вернуться в блог.