Почему мы показываем свои ошибки: журнал критических моментов проекта
Мы ведём открытый журнал ошибок собственного проекта: что нашли не так, как исправили и что это изменило. Без ретуши задним числом.
2026-08-17 · 5 мин чтения
У этого сайта нет клиентов с логотипами и нет команды с регалиями — бизнесу меньше года, а тексты и код мы собирали с помощью ИИ. Показать кейсы других клиентов мы пока не можем: их ещё не было.
Вместо этого мы сделали то, что можно проверить прямо сейчас: пока строили систему, вели журнал. Не отчёт «что получилось», а протокол «что пошло не так и что мы с этим сделали» — по ходу работы, а не постфактум, когда уже можно всё сгладить.
Вот пять записей из него.
Ошибка в цвете, которую заметили до того, как она попала на сайт
Первая гипотеза дизайна была простой: конкуренты в основном светлые, значит тёмная тема с ярким акцентом — это отстройка. Гипотеза выглядела разумно и чуть не пошла дальше — в итоговый арт-дирекшн.
Прежде чем её утвердить, мы решили не гадать, а проверить: открыли сайты конкурентов и вручную сняли реальные цвета с их вёрстки — не на глаз, а инструментом браузера, который читает точные коды. Оказалось, что почти тот же изумрудный оттенок уже использует один из конкурентов, а зелёный — второй. И тёмных секций у них на самом деле больше, чем казалось при беглом просмотре.
Гипотезу пересмотрели. Настоящее свободное место оказалось не в цвете, а в типографике — почти все в нише используют одни и те же массовые шрифты — и в скорости загрузки.
Урок не в том, что гипотеза была плохой. Урок в том, что мы её не приняли на веру, хотя выглядела она убедительно, и попросили доказательство раньше, чем решение стало дорогим для отмены.
Скорость и адаптивность обещали, а не считали — пока не проверили сами
Требование звучало привычно: «сайт должен быть удобным для чтения на контрасте» — стандарт, который декларируют почти все. Задекларировать его легко. Проверить — нет, если не сделать этого руками.
Мы прогнали расчёт контраста для каждой пары цветов вручную и занесли реальные числа в таблицу палитры — не «соответствует», а конкретное значение для каждой пары текст/фон. Заодно нашли слабое место: декоративная рамка на сайте недостаточно контрастна, чтобы нести информацию, — и явно пометили, что она декоративная и ни на что не влияет, вместо того чтобы понадеяться, что никто не заметит.
Платёжный сервис в задании оказался не тем, что стоит у нас на самом деле
В исходном задании фигурировал один сервис приёма платежей — как предположение по умолчанию, не как факт. Мы не стали проверять это предположение сразу, приняли как рабочую гипотезу и двинулись дальше.
Расхождение всплыло только на этапе проверки юридических требований: наша реальная платёжная инфраструктура — другая, и требование по онлайн-кассам для неё тоже другое. Пришлось возвращаться и пересчитывать раздел заново.
Из этого мы вынесли практическое правило для себя: значение по умолчанию — это не факт, а место, где легко ошибиться, если его не переспросить прямо. Теперь это правило, а не разовая случайность.
Мы отказались от гарантии возврата — и вместо неё показали состав отчёта
На этапе, где обычно ставят «гарантия возврата денег» как способ снять страх перед оплатой, мы приняли другое решение: гарантии не будет. Вместо неё — точный список того, что входит в отчёт и что не входит, опубликованный до оплаты.
Решение рискованное: если состав отчёта не проработать всерьёз, единственная страховка клиента исчезает вместе с гарантией. Поэтому состав переписывали не один раз, пока в него не попал пункт, который оказался сильнее любой гарантии: честный ответ, нужна ли вообще переделка сайта. Отчёт, который всем советует одно и то же, ничего не доказывает. Отчёт, который иногда говорит «вам это не нужно», доказывает, что его не подгоняли под продажу.
Мы чуть не сделали Android-приложение, потому что его попросили
В задании было прямое требование: сайт плюс приложение под Android. Прямое требование обычно просто выполняют.
Но данные, которые мы сами же собрали на предыдущих шагах, говорили другое: у продукта разовая покупка, а не подписка с возвратом пользователя; метрика успеха не зависит от того, есть приложение или нет; ресурс на поддержку ограничен. Формально приложение можно было сделать. По существу — оно было бы преждевременным, а мы бы потратили время туда, где результата не будет.
Мы показали эти цифры прямо, вместо того чтобы молча выполнить требование. Решение — отложить. Не потому что «так вышло», а потому что цифры сказали одно, а задание — другое, и мы выбрали цифры.
Что из этого следует для вас
Мы не показываем этот журнал, чтобы доказать, что мы особенные. Мы показываем его, потому что ровно тот же принцип используем в аудите вашего сайта: не украшаем находку, чтобы она звучала мягче, и не прячем то, что неудобно признать. Если аудит найдёт у вас нерабочую форму или разработку, которая не нужна, — в отчёте будет написано именно это.
Журнал ведётся и дальше. Если найдётся следующая ошибка — она тоже здесь появится.