Прототип выглядит готовым: что проверить перед первым пользователем

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

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

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

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