Я долго работала с Enterprise-проектами. Там всё серьёзно: отдельный DevOps, код-ревью, CI/CD, модульное тестирование. Когда открыла своё дело и стала работать с маленькими проектами, поняла: лучшие практики существуют для масштабных задач — а у малого бизнеса свои. Решила собрать анти-кейсы: что случается, когда следуешь гайдлайнам для enterprise в проекте, где они не нужны.

1. Ставь React для лендинга детского праздника

Best practice номер один: используй фреймворк. React, Vue, Angular — кто угодно, лишь бы компоненты.

Детский праздник. 50 гостей. Родители already know всё: дата, место, что надеть. Им не нужен личный кабинет, подписки, уведомления. Нужен сайт с программой, таймером обратного отсчёта и парой фотографий.

React в этом сценарии приносит 2 мегабайта JavaScript. Два мегабайта ради пяти страниц и одного таймера. Страница грузится три секунды. Ребёнок не дождётся и уйдёт смотреть YouTube.

Ванильный JavaScript: 30 килобайт. Загрузка — полсекунды. Страница работает на любом устройстве. Клиент счастлив. Ребёнок узнаёт программу вовремя.

2. Делай адаптив для приглашения на вечеринку

Best practice номер два: всегда мобильная версия. Mobile-first. Google penalizes неадаптивные сайты.

Частная вечеринка, invite only. QR-код на приглашении. Гости приходят по ссылке, которую им отправили.

Мобильная версия для такого проекта — лишние деньги. Десктопный дизайн сделан идеально, на большом экране всё красиво. Адаптив в этом случае не нужен, его не откроют с телефона.

Best practice всегда мобильный приводит к увеличению бюджета на 40 процентов без реальной пользы.

3. SEO для всех для закрытого мероприятия

Best practice номер три: поисковая оптимизация. Мета-теги, семантика, структурированные данные.

Частный день рождения. 20 гостей. Родители уже знают адрес, время, дресс-код. Они получили приглашение по WhatsApp.

SEO для такого сайта — мёртвому припарки. Google не нужен. Поисковик не нужен. Зато нужна закрытая страница с паролем — и это best practice не предусматривает.

4. CMS для всех для сайта который обновляется раз в год

Best practice номер четыре: управление контентом. WordPress, October, Strapi — ставь любую CMS.

Клиент: аниматор. Меняет программу раз в год, перед каждым сезоном. Ему нужно поменять пару текстов и несколько фотографий.

WordPress требует обновлений, хостинга, безопасности. Клиент не знает, что такое PHP. Он забывает пароль от админки и звонит мне в панике.

Одна HTML-страница. Файл лежит на хостинге. Клиент открывает FileZilla, меняет текст, сохраняет. Готово. Работает 10 лет без единого сбоя.

5. TypeScript защитит тебя для прототипа

Best practice номер пять: строгая типизация. TypeScript, PropTypes, Flow.

Прототип для заказчика. Один спринт. Нужно показать концепцию, получить обратную связь, доработать.

TypeScript в прототипе — это неделя на типы вместо одного дня на функционал. Заказчик смотрит на неработающий прототип и говорит: Мне не нравится. Ты объясняешь, что types ещё не готовы. Он не понимает.

Ванильный JS для прототипа: работает сразу. Показываешь заказчику — получаешь фидбек — правишь. Быстро. Дёшево. Честно.

Почему best practices вредны для малого бизнеса

Best practices написаны для команд с DevOps-инженерами, отдельным тестировщиком, менеджером проекта. Для ситуаций, когда над продуктом работают годы и его нужно поддерживать большой командой.

Маленький проект — другие условия. Разработчик сам ведёт проект. Клиент сам принимает решения о хостингах и языках. Бюджет ограничен. Сроки горят.

В этих условиях применять enterprise-гайдлайны — всё равно что лететь на самолёте за хлебом. Технически можно. Практически — дорого, долго, нелепо.