Сайт клиники, который я отказался делать, — и как это спасло проект

Обычно кейс про сайт начинают со стека и красивых цифр конверсии. Этот я начну с отказа — потому что именно отказ оказался самым важным решением во всём проекте.

Ко мне пришла клиника из Москвы с задачей: одностраничный сайт под ключ — дизайн, вёрстка, приём заявок, деплой. Фиксированный бюджет, срок в неделю. Стандартный лендинг. Но в первой же переписке всплыла деталь, из‑за которой обычный проект превратился в проверку на профессиональную гигиену.

Техзадание, от которого пришлось отказаться

Заказчица предложила сделать сайт несуществующей клиники. Врачей взять с чужого агрегатора отзывов, адрес подставить от другой клиники, отзывы — тоже чужие. Всё это нужно было для подачи документов в иностранный Минздрав.

Соблазн большой: технически это ровно та же работа, деньги те же, срок тот же. Но по сути это не «сложная задача» — это чужой юридический риск, который перекладывают на исполнителя. Чужие персональные данные врачей без их согласия. Чужой адрес, который принадлежит другому юрлицу. Чужие отзывы. Если что‑то из этого всплывёт, отвечать будет не только заказчик, но и тот, кто это собрал и опубликовал.

Я отказался делать сайт‑фантом и предложил альтернативу: делаем сайт реальной клиники по её действующей лицензии. У заказчицы такая лицензия была. Она согласилась.

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

Никогда не подставлять чужих врачей, чужой адрес и чужие отзывы. Адрес принадлежит другому юрлицу. Персональные данные — только с письменного согласия.

Пока реальных ФИО врачей с согласиями не было, в коде стояли обезличенные плейсхолдеры — условные Соколова, Лебедев, Кузнецова. В прод чужие персональные данные не выкатывались ни на минуту. Забегая вперёд: именно эта дисциплина через месяц позволила безболезненно поменять на сайте вообще всё.

Архитектура: контент отдельно, дизайн отдельно

Главное инженерное решение проекта звучит скучно, но оно и есть фундамент всего остального: весь контент клиники живёт в одном файле. Ни одна строчка про услуги, врачей, адрес или лицензию не «зашита» внутрь дизайна. Компоненты сайта — это чистое представление, которое просто показывает то, что ему дали.

graph TB
    subgraph Content["Один файл контента"]
        C["услуги · врачи · отзывы<br/>FAQ · галерея · контакты · лицензия"]
    end

    subgraph Site["Сайт"]
        H["Главная · 11 секций"]
        L["Юр-страницы: политика,<br/>согласие, лицензия"]
    end

    subgraph Server["Сервер"]
        CA["Веб-сервер + защита канала"]
        API["Приём заявок"]
        TG["Telegram клиники"]
    end

    C --> H
    C --> L
    H -->|"заявка"| CA
    CA --> API
    API -->|"сообщение"| TG

    style C fill:#c8a15a,color:#101010
    style TG fill:#1d6c6c,color:#fff

Звучит как техническая деталь, но на практике это решение бизнес‑уровня. Когда контент отделён от оформления, любая правка текста, цены или списка услуг — это редактирование одного места, а не поиск по всему проекту. И, как окажется в финале, это же спасает при полной смене бренда.

Под капотом — современный стек фронтенда (React, Vite, TypeScript, GSAP для анимаций, WebGL для премиум‑эффекта). Но для заказчика это неважно. Важно, что сайт быстрый, красивый и легко меняется.

Версия = URL: восемь дизайнов, которые можно сравнить вживую

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

Я сделал иначе. Каждая версия дизайна получала свой постоянный адрес. Не скриншот в чате, а живой сайт, который можно открыть, потыкать, сравнить.

timeline
    title Восемь версий за неделю
    v1 : Каркас сайта, базовые секции
    v2 : Стиль по референсу, версия для слабовидящих
    v3 : Слайдер врачей, отзывы, единая карта
    v4 : Аудит доступности, реальные фото
    v5 : Премиум-редизайн, WebGL-эффект в шапке
    v6 : Витрина услуг и блок «О клинике»
    v7 : Полный ребрендинг под новое юрлицо
    v8 : Финальная полировка

Заказчик открывал версию 4 и версию 5 в двух вкладках браузера и сравнивал их бок о бок, а не по памяти. Ни одна версия не потерялась — все восемь главных дизайнов (плюс десяток промежуточных) остались доступны по своим адресам, с журналом изменений: что поменялось, какой стал размер страницы, какие остались нерешённые вопросы.

Стоимость этого подхода — примерно сорок строк скрипта, который одной командой собирает сайт и выкладывает нужную версию на её адрес за десяток секунд. А ценность — обсуждение дизайна перестаёт быть эмоциональным и становится предметным.

Доступность — не галочка, а норма для медицины

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

Я прошёл аудит по международному стандарту доступности WCAG и закрыл девять конкретных пунктов.

graph LR
    subgraph Bylo["Было"]
        C1["Слабый контраст текста"]
        C2["Модалки ловят фокус неправильно"]
        C3["Мелкие кнопки на телефоне"]
        C4["Формы без подсказок для читалки"]
    end
    subgraph Stalo["Стало"]
        F1["Контраст усилен до нормы"]
        F2["Фокус удерживается и возвращается"]
        F3["Кнопки не меньше 44 px"]
        F4["Поля помечены для скринридера"]
    end
    C1 --> F1
    C2 --> F2
    C3 --> F3
    C4 --> F4

Конкретно это означало: усилить цвета кнопок до уровня, читаемого при слабом зрении; сделать так, чтобы всплывающие окна корректно «ловили» фокус и возвращали его на место после закрытия; увеличить кнопки до размера, в который легко попасть пальцем; пометить поля форм так, чтобы программа чтения экрана понимала, что обязательно, а где ошибка. И отдельно — уважать системную настройку «уменьшить анимацию»: если человек её включил, сайт не мельтешит.

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

Премиум‑дизайн, который не тормозит

Когда база и доступность закрыты, можно поднимать планку эстетики. Финальный визуальный концепт — сдержанная роскошь: тёплое золото и глубокая бирюза на кремовом фоне, изящная серифная типографика, авторская монограмма.

Самая эффектная деталь — живой WebGL-эффект в шапке: колышущиеся золотистые нити за заголовком. Красиво, но такие эффекты обычно платят за красоту скоростью загрузки — а для сайта, куда приходят с телефона за записью к врачу, медленная загрузка недопустима.

Поэтому эффект устроен хитро: он не участвует в первой отрисовке страницы вообще.

sequenceDiagram
    participant B as Браузер
    participant S as Сайт
    participant W as WebGL-эффект

    B->>S: открываю страницу
    S->>B: показываю шапку со статичным фоном
    Note over B: главное уже видно и читается
    B->>S: браузер освободился
    S->>W: только теперь догружаю эффект
    W->>B: нити плавно проявляются поверх фона
    Note over W: настройка «меньше анимации» → эффект не грузится совсем

Сначала посетитель видит готовую, читаемую страницу. И только когда браузер освободился, поверх фона плавно проявляется анимация. Ни один байт «красоты» не задерживает то, ради чего человек пришёл. А если у пользователя включена настройка «меньше движения», эффект не загружается вовсе — экономим и трафик, и его комфорт.

Отдельно я разбил код сайта на независимые части так, чтобы правка текста в файле контента не сбрасывала кэш тяжёлых библиотек у вернувшегося посетителя. Итог — стартовая загрузка около 190 КБ, а всё необязательное (тот самый эффект, юридические страницы) подтягивается только по требованию.

Ребрендинг за один вечер

А теперь то, ради чего затевалась вся дисциплина с «контентом в одном файле».

Через месяц после сдачи заказчик вернулся с новостью: сайт переезжает на другое юрлицо, другой бренд, другой адрес и другой домен. Вместо четырёх услуг пластической хирургии — двадцать три медицинских направления по новой лицензии. По сути — другая клиника на том же сайте.

Обычно такое означает переписать половину проекта. Здесь это заняло один вечер и несколько правок.

graph LR
    subgraph Menyali["Что меняли"]
        D["файл контента:<br/>4 услуги → 23 направления"]
        M["мета-теги и картинка<br/>для соцсетей"]
        LG["логотип и брендинг"]
        LP["новая страница лицензии"]
    end
    subgraph NeTrogali["Что НЕ трогали"]
        S["все 11 секций сайта"]
        E["дизайн и эффекты"]
        HK["логика форм и модалок"]
        DP["скрипт деплоя"]
    end
    D --> OK["Новый бренд на новом домене"]
    M --> OK
    LG --> OK
    LP --> OK
    S -.->|"переиспользовано как есть"| OK
    E -.-> OK
    HK -.-> OK
    DP -.-> OK

    style OK fill:#1d6c6c,color:#fff

Переписали файл контента, поменяли логотип и заголовки, добавили страницу с новыми реквизитами и выпиской из реестра, обновили мета‑теги и картинку для соцсетей — и выкатили на новый домен. Дизайн, эффекты, доступность, логика форм — всё переиспользовалось как есть.

Дисциплина «контент только в одном файле» окупилась ровно один раз — и полностью окупила себя этим одним разом.

Заявки сразу в Telegram

Форма записи на сайте не отправляет письма, которые теряются в спаме. Заявка пациента уходит прямо в закрытый Telegram-чат клиники — администратор видит её мгновенно и перезванивает.

sequenceDiagram
    participant U as Пациент
    participant F as Форма
    participant A as Сервис заявок
    participant T as Telegram клиники

    U->>F: заполняет форму
    F->>F: проверка + ловушка для спам-ботов
    alt это бот
        F-->>U: делаем вид, что всё ок, но заявку не шлём
    else живой человек
        F->>A: отправка
        A->>T: сообщение в чат клиники
        T-->>A: доставлено
        A-->>U: «Заявка принята»
    end

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

Что осталось в сухом остатке

Параметр	Значение
Срок	неделя, фиксированный бюджет
Версий дизайна	8 главных, каждая на своём адресе
Доступность	стандарт WCAG, 9 пунктов закрыто явно
Стартовая загрузка	~190 КБ, эффекты — по требованию
Полный ребрендинг	один вырез, несколько правок
Приём заявок	мгновенно в Telegram клиники

Три вывода, которые я забираю из этого проекта:

Отказ от плохого ТЗ — часть работы, а не срыв сделки. Сайт‑фантом с чужими врачами и адресом — это не заказ, это чужой юридический риск. Предложить легальную альтернативу вместо простого «нет» — вот что превращает отказ в решение. И часто легальный путь ещё и проще.

Версия — это адрес, а не скриншот. Как только каждая итерация дизайна получает постоянную ссылку, обсуждение перестаёт быть спором о воспоминаниях. Клиент открывает две вкладки и решает предметно.

Один файл контента окупается ровно тогда, когда меняется всё. Скучная дисциплина «не размазывать данные по проекту» кажется избыточной — до вечера, когда клиника целиком меняет юрлицо, бренд и услуги, а работы оказывается на один вечер.

---

Как это выглядит

Посмотреть вживую

Следующий шаг: хотите лендинг клиники без юридических рисков — на своих URL и по стандартам доступности, напишите мне в Telegram.