Продукты, которые вы можете понять. Системы, на которых мы можем строить.

Что нужно было решить

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

Что мы построили

Next.js 14.2.35 (App Router) с React 18, TypeScript и Tailwind. Каждая позиция из медицинской номенклатуры стала собственной статической маршрутизацией: 521 файл `page.tsx` в `src/app`, из которых 481 под `/servicii` — 184 физиотерапия, 122 консультативные услуги, 61 периодические медицинские осмотры, 27 гинекология, 26 озонотерапия, 23 лечебные пакеты, 18 альтернативная медицина, 12 диагностика, остальные по разделам. Sitemap на продакшене перечисляет 890 адресов. Сайт двуязычный ro/ru. Редактируемый контент (врачи, пакеты, процедуры, статьи, настройки, изображения) хранится в локальной SQLite-базе через `better-sqlite3`, с WAL-журналом и активными внешними ключами, управляется из `/admin` через 20 API-маршрутов; аутентификация использует `jose` для сессии и `bcryptjs` для пароля, а смена пароля инвалидирует существующие сессии. Формы записи и контакта проверяются с помощью `zod` + `react-hook-form` и отправляют сформированное сообщение напрямую в Telegram через Bot API. Есть также калькулятор цен на `calculator`.

Что нужно было решить

Меню клуба часто меняется, у него есть цены и объёмы, которые должны быть точными, и его читают с телефона, в темноте, люди, говорящие на трёх языках. Сканированный PDF по QR-коду не решает ни одной из этих задач: его нельзя искать, переводить, обновлять без повторной печати кода.

Что мы построили

Цифровое меню без фреймворка и без пакетов: реальные источники — это четыре JSON-файла, а Python-генератор на 402 строки пишет из них один `index.html`. 119 продуктов в 21 категории, каждый с ценой, объёмом, составом и фотографией; 119 коротких текстов-презентаций, по одному на продукт; 119 наборов рекомендаций по сочетанию („с чем подходит”), которые посетитель видит на каждой карточке. У меню три языка: румынский — основа, а русский и английский покрывают не только интерфейс, но и категории, объёмы, составы, 82 вкусовые метки и все 119 текстов-презентаций. Корзина, список избранного и разделение счёта работают в браузере, без аккаунта и без сервера. Шрифты размещены на том же домене, а не у Google. Перед каждой публикацией скрипт на 233 строки выполняет 16 проверок — не просочился ли какой-либо трекер, не запрашивается ли что-либо с третьего домена, валиден ли JSON и существует ли каждое изображение, полное ли меню на всех трёх языках, снижаются ли цены в каждой категории и валидны ли структурированные данные на странице. Публикация происходит автоматически из GitHub Actions при слиянии в `main`, после того как workflow делает полную копию продакшена и хранит её 30 дней.

Что нужно было решить

У примэрии коммуны должна быть официальный веб-страница, соответствующая HG 728/2023 — с фиксированными разделами (прозрачность принятия решений, проекты и решения, объявления, документы, контакты, бюджет) — и она должна уметь обновлять её сама, без разработчика при каждом объявлении. Без этого общественно значимая информация остаётся на бумаге или в группе Facebook.

Что мы построили

Приложение Laravel 12 на PHP 8.2 с MySQL 8, front-end Vite + Tailwind, упакованное в два контейнера Docker (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). Архитектура намеренно разделяет два типа контента: редакционный, который меняется редко (география, история, учреждения, контакты, бюджет), хранится в одном PHP-файле конфигурации на 1613 строк, который напрямую читают шаблоны Blade, а тот, что меняется часто (объявления, фотогалерея, проекты и решения, документы, настройки прозрачности), хранится в MySQL и редактируется из панели `/admin`. 40 шаблонов Blade, 32 маршрута, 10 миграций базы данных. Авторизация в панели ограничена 5 запросами в минуту с одного адреса — шестой получает 429 — и каждое действие администратора попадает в таблицу аудита. Заголовки безопасности и sitemap покрыты автоматическими тестами, которые запускаются в CI.

Что нужно было решить

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

Что мы построили

Один `index.html`, сгенерированный Python-скриптом на 377 строк из JSON-файлов: 146 товаров в 31 категории, 143 коротких описательных текста, плюс переводы на русский и английский для категорий, названий, объёмов, составов, тегов и текстов. Корзина, список избранного и разделение счёта работают в браузере. Сайт напрямую обслуживается Caddy 2, с автоматическим HTTPS. Интересно, что неотслеживание пользователя — это не обещание, а правило, заданное непрерывной интеграцией: при каждом запросе на слияние CI заново генерирует `index.html` из исходников и отклоняет PR, если результат отличается от файла в репозитории (то есть опубликованная страница всегда соответствует исходникам), затем выполняет 14 проверок — без трекеров, без каких-либо ресурсов, автоматически загружаемых с стороннего домена, локально размещённые шрифты, без backup-файлов, попавших в репозиторий, политика конфиденциальности присутствует и связана из нижнего колонтитула, полное меню на трёх языках, цены в порядке убывания в каждой категории, корректные структурированные данные — и дополнительно проверяет, что из server config не исчезли заголовки безопасности и маскирование IP-адреса в логах. Все используемые GitHub Actions зафиксированы на контрольной сумме коммита, а workflow запускается с `permissions: {}`.

Что нужно было решить

непроверено — у нас нет источников, поэтому я не могу описать проблему работы, не выдумывая.

Что мы построили

React-приложение, собранное с Vite, статически раздаваемое nginx, с русской версией на `/ru/`. 181 адрес в production sitemap. Извне можно утверждать только это: исходников на этой машине нет, поэтому я не могу назвать библиотеки, структуру или интеграции.

Что нужно было решить

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

Что мы построили

Приложение React 18 + TypeScript на Vite 6, с маршрутизацией `react-router-dom` — 22 экрана, от услуг и цен до экстренной помощи, ортодонтии, имплантов, педодонтии, прозрачности и обратной связи. Сзади — API Express 4, запущенный под PM2; nginx раздает собранные файлы и пересылает дальше только `/api`. Публичные данные (услуги, команда) лежат в JSON-файлах, которые читают и API, и напрямую фронтенд. То, что мы привели в порядок, — безопасность: пароль больше не покидает сервер — `POST `login` проверяет его там и возвращает подписанный HMAC-SHA256 токен сроком на 12 часов, с лимитом в 8 попыток за 15 минут на IP-адрес и сравнением в постоянное время; записи в `services` и `team` теперь требуют токен; секрет подписи генерируется автоматически в файле с правами 0600, хранимом вне репозитория; API слушает только на 127.0.0.1, значит nginx — единственный публичный путь; CORS ограничен собственными доменами, а JSON-тело ограничено 1 MB. Сверху мы добавили CI, который собирает, проверяет типы и отклоняет пакет, если находит в нем секрет, плюс Dependabot с еженедельным ритмом для npm.

Что нужно было решить

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

Что мы построили

Две половины в одном репозитории. Публичная часть — это статически собранное приложение Vite + React Router — 50 экранов, среди которых четыре калькулятора (кредит, соответствие критериям, рефинансирование, график платежей), отдельные страницы по типам кредитов, блог, страницы преддоговорной информации и соответствия требованиям. Румынские маршруты остаются без префикса, а русские идут на `/ru/…`, с каноническими и альтернативными тегами, сгенерированными из языка активного маршрута. Бизнес-часть — модульный backend Express на TypeScript, с Prisma поверх PostgreSQL: 16 модулей — аутентификация, права по ролям, поток заявок, документы, платежи, уведомления, запланированные задачи, блог, SEO, GDPR, клиенты, лиды, контакт, калькулятор, Google Ads, здоровье — и 18 таблиц в схеме Prisma, среди которых `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` и `CronJobRun`. Работает под PM2, с отдельными скриптами для миграций в production, проверок перед запуском, генерации секретов, резервного копирования и восстановления базы.

Что нужно было решить

Автосервис ищут в очень конкретных сочетаниях — марка плюс операция плюс район («ремонт автоматической коробки BMW Botanica»). Одна страница «Servicii» не может ответить ни на что из этого. Техническая проблема в том, что сайт — это одностраничное React-приложение, поэтому поисковая система видит пустой `<div>`, если не сделано что-то конкретное.

Что мы построили

React 19 + TypeScript приложение на Vite 6, с React Router, но пререндеренное на этапе сборки: каждый маршрут выходит из сборки как отдельный HTML-файл, поэтому поисковая система получает контент, а не пустую страницу. Структура адресов была расширена проверяемыми шагами в истории — с 206 индексируемых страниц до 316 за счёт добавления сочетаний марка × категория работ, статей и страниц по сектору Кишинёва. Маршруты имеют языковые версии, отдельный sitemap изображений, изображения Open Graph и разделённый JavaScript-пакет для более быстрой загрузки. Последний коммит исправил деталь, которая тихо ломает индексацию: канонический адрес, `hreflang` и адреса в sitemap теперь все выводят одну и ту же форму с конечным слэшем.