Разработка сайтов и веб-приложений
Клиент приходит с задачей «нам нужен сайт» — и уже в первом разговоре выясняется, что за этим стоит: интернет-магазин с синхронизацией с 1С, корпоративный портал с ролевым доступом, SaaS-платформа с multi-tenant архитектурой или публичный лендинг с A/B-тестами. Это принципиально разные задачи — по архитектуре, стеку, срокам и точкам сложности. За 8 лет работы мы провели более 150 таких проектов — от простых лендингов до высоконагруженных платформ, и знаем, где реально возникают узкие места.
Ниже — как мы принимаем технические решения по каждому направлению и что гарантируем на каждом этапе.
Почему выбор rendering strategy — главное решение на старте?
Большинство современных интерфейсов строятся на React или Vue. Выбор между ними почти никогда не принципиален — важнее выбор rendering strategy: SSR, SSG, ISR или SPA.
Для публичных сайтов с SEO-требованиями мы по умолчанию берём Next.js App Router или Nuxt 3. ISR позволяет кешировать страницы каталога на CDN и регенерировать их по триггеру — без полного SSR на каждый запрос. Это даёт TTFB < 80 ms даже на каталоге из 200 000 SKU.
Для административных панелей, дашбордов, CRM-интерфейсов — SPA на Vite + React достаточно и работает быстрее в разработке. TypeScript обязателен: без него рефакторинг на масштабе больно.
Бандл — постоянный источник проблем. Незамеченный moment.js в зависимостях добавляет 230 KB gzip. lodash вместо lodash-es ломает tree-shaking. Мы используем @next/bundle-analyzer или vite-bundle-visualizer на каждом проекте — до деплоя, не после.
Какие задачи мы решаем
Backend: Laravel, Node.js, Go, Django
| Задача | Стек |
|---|---|
| CMS, e-commerce, REST API для бизнес-логики | Laravel 10/11 + PostgreSQL |
| Realtime: чат, уведомления, стриминг данных | Node.js (Fastify) + Redis + WebSocket |
| Высоконагруженные микросервисы, gRPC | Go |
| Аналитика, ML pipeline, data-heavy | Django + Celery + PostgreSQL |
| Контентные сайты с умеренной нагрузкой | Laravel + Octane (Swoole) |
Laravel — наш основной фреймворк для бизнес-приложений. Octane с Swoole держит 8 000–12 000 RPS на одном сервере m5.xlarge при правильной настройке — это покрывает 95% задач без горизонтального масштабирования. Для Node.js выбираем Fastify вместо Express: в 2–3 раза быстрее на холодных запросах, лучше TypeScript-интеграция.
База данных: PostgreSQL как основа
PostgreSQL — основная БД. Для кешей и очередей — Redis. MongoDB используем только под конкретные задачи: хранение неструктурированных документов или геоданных. Wikipedia: PostgreSQL подтверждает его надёжность.
N+1 query — самая распространённая причина деградации производительности. На странице каталога с eager loading with(['category', 'images', 'attributes']) это не проблема. Но стоит добавить пользовательские метки или агрегированные рейтинги — и без withCount, loadMissing или выделенного query object начинается по 300+ запросов на страницу. Мы покрываем это тестами через Laravel Debugbar и Telescope в dev-окружении.
Индексы — отдельная история. Composite index по (status, created_at DESC) для фильтрованных лент. Partial index для soft-deleted записей. GIN-индексы для JSONB-полей и full-text search. Без этого любой ORDER BY на большой таблице превращается в seq scan.
CMS и контент
Для проектов, где редакторы работают с контентом самостоятельно, выбор CMS зависит от сложности структуры данных:
- WordPress — для простых корпоративных сайтов и блогов. Быстро, знакомо, огромная экосистема плагинов. Мы его не демонизируем — он решает свои задачи хорошо. Но для e-commerce с нестандартной бизнес-логикой это плохой выбор.
- Headless CMS (Strapi, Directus, Payload CMS) — когда нужна гибкость в структуре данных и фронтенд полностью на React/Vue. API-first, контент через REST или GraphQL, фронтенд деплоится отдельно на Vercel или собственном Nginx.
- Собственная CMS на Laravel — для проектов с уникальными требованиями к workflow, ролям, версионированию контента. Дороже в разработке, но полностью подчинено задаче.
E-commerce: производительность каталога и интеграции
Интернет-магазины — отдельное направление с высокой технической насыщенностью. Здесь важны:
- Производительность каталога при больших объёмах (Elasticsearch или PostgreSQL full-text search)
- Корректный checkout с обработкой гонок при резервировании товаров
- Интеграции: 1С, МойСклад, платёжные шлюзы (Stripe, ЮКасса, ЕРИП)
- Фасетная фильтрация без N+1
Для небольших магазинов иногда достаточно WooCommerce или OpenCart с кастомизацией. Для магазинов с нестандартной логикой (подписки, аренда, b2b прайс-листы) пишем на Laravel с нуля.
SaaS-платформы: multi-tenancy, биллинг, feature flags
SaaS — это не просто «сайт с авторизацией». Это multi-tenant архитектура, биллинг, onboarding, feature flags, rate limiting, audit logs. Каждый из этих блоков имеет нетривиальные реализации. Wikipedia: Multi-tenancy описывает основные подходы.
Multi-tenancy на уровне базы данных: shared schema (tenant_id на каждой таблице) против separate databases. Первый подход проще в обслуживании, второй даёт изоляцию данных — выбор зависит от требований клиентов к безопасности.
Биллинг через Stripe с webhook-обработкой — обязательно идемпотентный приём событий. invoice.payment_succeeded может прийти дважды.
AI-интеграции: LLM, RAG, streaming
Сегодня появились задачи, которых раньше не было: интеграция LLM в продукт, AI-поиск, генерация контента, чат-боты с RAG. Мы работаем с OpenAI API, Anthropic API, Ollama для локальных моделей, а также с векторными базами данных (pgvector, Qdrant) для semantic search.
Важный нюанс: streaming responses от LLM требуют правильной реализации Server-Sent Events или WebSocket на бэкенде и корректной обработки chunks на фронтенде. Без этого UX страдает — пользователь ждёт весь ответ целиком вместо того, чтобы видеть его постепенно.
SEO и Core Web Vitals
SEO закладывается в архитектуру, а не добавляется в конце. SSR/SSG для публичных страниц, правильные canonical, structured data (JSON-LD), sitemap с приоритетами.
Core Web Vitals — метрики, которые реально влияют на ранжирование:
- LCP (Largest Contentful Paint): цель < 2.5 s. Частая причина провала — hero image 3–4 MB без
srcsetи безloading="eager"+fetchpriority="high"на первом экране. - CLS (Cumulative Layout Shift): цель < 0.1. Динамические баннеры без зарезервированного места, шрифты без
font-display: swap— типичные источники. - INP (Interaction to Next Paint): цель < 200 ms. Тяжёлые event handlers, синхронный JS на main thread, неоптимальные React re-renders.
Мы измеряем это в Lighthouse, PageSpeed Insights и через Playwright в CI — не только на десктопе, но и на эмулированном 4G mobile.
Как мы строим процесс и оцениваем сроки
Этапы работы
- Discovery — сбор требований, анализ текущей системы (если есть), выявление интеграций, составление ERD
- Проектирование — архитектура, выбор стека, wireframes или Figma-прототип
- Дизайн — UI kit, адаптивный дизайн, design system в Figma
- Разработка — спринты по 1–2 недели, демо после каждого
- Тестирование — unit, integration, e2e (Playwright), нагрузочное (k6 или Locust)
- Деплой — Docker + Nginx, CI/CD через GitHub Actions или GitLab CI, мониторинг через Sentry + Grafana
- Поддержка — SLA, обновления зависимостей, масштабирование
Ориентиры по срокам
| Тип проекта | Срок |
|---|---|
| Лендинг / визитка | 2–4 недели |
| Корпоративный сайт | 4–10 недель |
| Интернет-магазин (средний) | 8–16 недель |
| SaaS-платформа (MVP) | 12–24 недели |
| Корпоративный портал / ERP | 16–40 недель |
Стоимость рассчитывается индивидуально после декомпозиции. На оценку влияет количество интеграций, объём пользовательских ролей, требования к нагрузке и наличие готового дизайна.
Типичные ошибки, которые мы встречаем в готовых проектах
Отсутствие индексов на внешних ключах. Laravel не создаёт их автоматически до определённой версии. На таблице в 500K строк JOIN без индекса — seq scan на каждый запрос.
JWT без механизма отзыва. Access token живёт 15 минут — окей. Но если нет blacklist или rotation refresh tokens, скомпрометированный токен работает до истечения срока.
Отсутствие rate limiting на API. Без throttling эндпоинт /search или /export легко положить случайным скриптом.
Деплой без rollback-стратегии. Если деплой сломал прод, нужен механизм быстрого возврата. Blue-green или хотя бы тегированные Docker-образы с возможностью откатиться за 2 минуты.
Логи только в stdout без агрегации. Sentry для exception tracking + structured logs в Loki или CloudWatch — минимум для проекта, который вы планируете поддерживать.
Что вы получите (deliverables)
После завершения проекта мы передаём:
- Документацию: архитектурные схемы, ERD, описание API (OpenAPI/Swagger), инструкцию по деплою
- Исходный код в приватном репозитории (GitHub/GitLab) с защитой main-ветки и ревью
- Доступы: к хостингу, панели управления, мониторингу (Sentry, Grafana), к CRM и CMS (если применимо)
- Обучение: 2–3 сессии для администраторов и редакторов контента
- Поддержка по SLA: гарантийный период 1 месяц (критические баги — 4 часа, остальные — 24 часа)
Опыт и гарантии
- Опыт: 8 лет на рынке разработки, 150+ завершённых проектов
- Гарантия: фиксируем SLA в договоре; при нарушении сроков компенсируем скидкой на дальнейшее обслуживание
- Сертификаты: партнёрские статусы по Laravel, React, облачным провайдерам (AWS, Selectel)
- Безопасность: лицензированное ПО, соглашение о неразглашении (NDA) и обработка персональных данных по 152-ФЗ
Наши решения позволяют сократить расходы на хостинг на 30–50% — это экономия $150–300 в год для среднего проекта. Закажите разработку сайта под ключ — получите консультацию инженера и точную оценку сроков. Свяжитесь с нами, чтобы обсудить ваш проект.