Технологии, которые делают сайты и софт быстрее, безопаснее и поддерживаемыми годами.
Next.js, React и TypeScript на фронтенде. .NET и Node на бэкенде. Azure, CI/CD и observability в эксплуатации. LLM-интеграция, RAG и guardrails для AI. Каждый выбор обоснован — не модный.
- Next.js · React · TypeScript
- .NET · ASP.NET Core · Node · PostgreSQL
- Azure · Docker · GitHub Actions · observability
- LLM · RAG · vector DBs · evaluation · guardrails
Решения о стеке — бизнес-решения, а не вопрос вкуса.
Выбор технологии решает, насколько быстро грузится ваш сайт, насколько безопасно лежат данные, насколько легко команда развивает систему — и насколько дорого она обходится через пять лет. Мы относимся к стеку как к архитектурному вопросу: задокументировано, обосновано, обратимо. На этой странице — инструменты, на которых мы строим сайты, веб-приложения, desktop- и мобильные приложения и AI-интеграции — и почему.
Для кого эта страница про технологии.
Мы пишем здесь для тех, кто оценивает решения о стеке, а не просто читает маркетинг. Если у вас одна из этих ролей — здесь будут конкретные ответы.
CTO и tech lead
Вы оцениваете, подходит ли наш стек вашей инженерной команде: найм, существующие системы, build-пайплайны, долгосрочная поддерживаемость. Вы хотите понять, почему мы зафиксировались на тех или иных решениях.
Head of digital / product
Вы отвечаете за продукт или платформу и ищете партнёра, который не просто «делает круто», а через два года всё ещё поставляет поддерживаемый код — с путями, которые ваша команда сможет взять.
Руководство с техническим уровнем
Вы знаете цену плохих решений по стеку: дорогая поддержка, сложный найм, хрупкие системы. Вы хотите партнёра, который относится к этим затратам серьёзно.
Внутренние инженерные команды
Вы хотите, чтобы внешние модули чисто вставали в ваш репозиторий, были задокументированы и следовали вашему стандарту. Мы поставляем архитектуру и код, который ваша команда сможет вести дальше.
Типовые проблемы со стеком — и как мы их избегаем.
Большинство проблем со стеком — не от «неправильных» инструментов, а от отсутствующих решений. Вот что мы чаще всего видим — и как с этим работаем.
Стена логотипов вместо архитектуры
Стек как набор модных лого долго не живёт. Мы фиксируем чёткий архитектурный центр (Next.js + TypeScript + .NET или Node + PostgreSQL) и добавляем только то, что реально нужно.
Скрытый lock-in
Платформы, на которых легко стартовать, дорожают, как только нужен рост (кастомный CMS, проприетарные билдеры, непрозрачные хостинги). Мы предпочитаем элементы стека с понятной exit-стратегией.
Тупики по найму
Экзотические языки или фреймворки оставляют проект без людей после запуска. Мы выбираем технологии (Next.js, React, TypeScript, .NET, Node, PostgreSQL), под которые реалистично нанимать.
Безопасность и compliance — слишком поздно
GDPR, расположение данных, модели ролей и прав, audit trail — мы решаем эти вопросы на этапе архитектуры, не на аудите перед запуском.
AI без стратегии данных
LLM добавляют, не определяя: какие данные идут на вход, что допустимо на выходе, как оценивать качество и кто несёт ответственность. Мы строим AI-интеграции с классификацией данных, evaluation и guardrails — не как tech-demo.
Performance- и SEO-проблемы после запуска
Плохая гидратация, отсутствие оптимизации изображений, огромные бандлы — обычно следствие пропущенных архитектурных решений. Мы задаём бюджеты производительности и SEO с самого начала и проверяем их в CI.
Стек p24.co — общая картина.
Шесть блоков, которые подходят друг к другу. Каждый блок заменим, когда есть обоснование, — но не «по моде».
Web-frontend · Next.js, React, TypeScript
Next.js (App Router) с React и TypeScript как стандарт для сайтов и фронтендов веб-приложений. SSR/SSG под SEO, семантичный HTML, компоненты с прицелом на WCAG AA, явные токены и дизайн-система. Бюджеты производительности под Core Web Vitals, изображения через next/image, чёткая стратегия кэширования. Astro — когда контент превалирует и JS-нагрузка должна быть минимальной.
Backend · .NET / Node, API, БД, auth, роли
.NET / ASP.NET Core, когда важна доменная логика, долговечность и интеграция с Windows-/enterprise-окружениями. Node (TypeScript) — когда фронтенд и бэкенд живут рядом или достаточно небольшого сервиса. PostgreSQL как стандарт, миграции в репозитории, REST или GraphQL по потребителям. Auth через зрелые провайдеры (Azure AD, Auth0, собственный OIDC), роли и права моделируются явно.
Cloud & DevOps · Azure, Docker, CI/CD, observability
Azure как стандартное облако (с чётким EU-region-сетапом), Docker для воспроизводимых контейнеров, GitHub Actions для CI/CD с quality gates (тесты, линтеры, typecheck, размер бандла). Несколько окружений (dev/stage/prod), infrastructure-as-code там, где это окупается, логи/метрики/трейсинг через зрелые инструменты, задокументированная стратегия бэкапа и восстановления.
AI-стек · LLM-интеграция, RAG, evaluation, guardrails
OpenAI- и совместимые LLM API как стандартный путь, локальные/EU-опции для чувствительных данных. RAG с vector-DB (например, pgvector, Qdrant) по корпоративным знаниям. Evaluation-набор (gold set, регресс, классы ошибок) вместо «на чутьё». Guardrails (prompt-фильтры, валидация выходов, rate limits, логи) и явные потоки данных: что уходит наружу, что остаётся внутри.
Mobile & desktop · PWA, React Native, .NET / WPF
PWA для веб-приложений, которые должны ощущаться «как приложение», без оверхеда сторов. React Native — когда нужны реальные native-функции или присутствие в сторах. .NET / WPF — для Windows-desktop в enterprise или специализированных задачах. Канал выбираем под use-case, а не под тренд.
Архитектурные принципы · поддерживаемость, безопасность, стоимость
Доменная модульность, ясные слои между UI, прикладной логикой и persistence. Тесты как контракт (unit для логики, integration и E2E — для критических путей). Модель безопасности задокументирована явно (auth, роли, secrets, бэкапы). Стоимость — архитектурный фактор: избегаем сетапов, которые дорожают непропорционально при росте.
Сопутствующие артефакты
Architecture Decision Records (ADR), диаграммы потоков данных и auth, задокументированные деплои, бюджеты производительности и SEO, стратегия тестов и бэкапов. После запуска — передача вашей команде или другому партнёру: выбор стека без lock-in.
Как мы принимаем решения о стеке и архитектуре.
Мы используем набор критериев, чтобы решения по стеку шли из вашего бизнес-контекста, а не из моды.
- 01
1. Уточняем use-case и срок жизни
DiscoveryДо разговора об инструментах: как долго система должна жить? Кто её поддерживает после запуска? Какие нагрузки и объёмы данных мы ждём? Эти вопросы решают больше, чем любой тренд.
output → Профиль требований и срока жизни - 02
2. Сверяемся с реальностью найма и команды
Архитектурная фазаКакие языки и фреймворки знает ваша команда? Насколько сложно нанимать? Мы предпочитаем элементы стека с большим talent pool — без экзотики без пути найма.
output → Оценка рисков найма и поддержки - 03
3. Задаём рамку безопасности и compliance
Архитектурная фазаGDPR, расположение данных, модели ролей и прав, audit trail, бэкапы, secrets management — до того, как пишем код. Мы определяем план безопасности и потоков данных, который формирует архитектуру.
output → План безопасности и потоков данных - 04
4. Задаём бюджет производительности и SEO
Дизайн-система и разработкаМы фиксируем цели по Core Web Vitals, размер бандлов, время ответа и SEO-предпосылки. Эти бюджеты мониторятся в CI — не измеряются впервые на аудите.
output → Бюджет производительности и SEO - 05
5. Architecture Decision Record на каждое значимое решение
На протяжении проектаКаждое значимое решение по стеку получает короткую письменную фиксацию: контекст, альтернативы, решение, последствия. Так через два года остаётся понятно, почему так — даже если p24.co уже не в проекте.
output → ADR в репозитории - 06
6. AI-интеграция с классификацией данных и evaluation
AI-архитектураДо первого LLM-вызова: какие данные допустимы на входе? Какие ответы приемлемы? Как мы оцениваем качество? Мы строим gold set, guardrails и логирование — не просто промпты.
output → План потоков данных AI · evaluation-набор - 07
7. План эксплуатации и передачи
Перед запускомДо go-live: кто эксплуатирует систему? Кто ротирует secrets? Кто смотрит логи и бэкапы? Мы поставляем план эксплуатации и план передачи — чтобы ответственность за стек была однозначной.
output → План эксплуатации и hand-off
Архитектурные принципы, которые мы применяем последовательно.
Это не слайды — они видны в наших репозиториях, архитектурных схемах и CI-конфигурациях.
Поддерживаемость выше «умного кода»
Читаемый, проверенный код побеждает элегантные трюки. Мы строим так, чтобы через три года разработчица могла продолжать без нас.
Модульность с ясными границами
Доменные модули с явными интерфейсами. UI, прикладная логика и persistence остаются разделены — и тесты становятся надёжными.
Безопасность как default, а не дополнение
Auth-потоки, secrets-management, классификация потоков данных, логи и бэкапы — часть минимальной поставки. Думать о безопасности после запуска — поздно.
Performance и SEO — инженерная дисциплина
Core Web Vitals, семантичный HTML, технический SEO, доступность (WCAG AA) — мы относимся к этому как к функциональным требованиям, а не как к маркетингу.
Найм как архитектурный критерий
Выбираем элементы стека с большим talent pool. Так проект остаётся независимым от отдельных людей.
Стоимость как архитектурный фактор
Строим сетапы, которые масштабируются при успехе, не дорожая непропорционально. Облако, кэширование и модель данных проектируются вместе с бюджетом.
Как мы несём технологическую ответственность.
Вы работаете напрямую с основателем и небольшой инженерной командой — без архитектурного слоя, который рисует слайды, пока другие пишут код. Мы рано называем риски, фиксируем решения письменно и поставляем стек, который вы сможете вести сами.
- 01Вы общаетесь напрямую с инжинирингом — не с продажами «про инжиниринг».
- 02Архитектурные решения живут в ADR — не в чьей-то голове.
- 03Мы говорим «нет» ненужному lock-in, экзотическим инструментам и решениям ради хайпа.
- 04Стек и модель безопасности видны в репозитории — не только на слайдах.
- 05Общение — на немецком, английском или русском, как удобно вашей команде.
- 06После запуска ваша команда получает всё, чтобы вести стек самостоятельно.
Частые вопросы про стек и архитектуру.
Почему Next.js как стандарт для сайтов и фронтендов?
Next.js (App Router) покрывает SSR, SSG и ISR, имеет сильные дефолты под SEO и производительность, большую экосистему и очень широкий talent pool. Для контентных страниц SEO-поведение хорошее, для фронтендов веб-приложений — чистая компонентная и data-flow архитектура. Для чисто статического контента с минимумом JS мы рассматриваем Astro.
Почему .NET на бэкенде, а не только Node?
.NET / ASP.NET Core силён в доменном моделировании, долговечности и интеграции с Windows-/enterprise-окружениями, где живут многие наши клиенты. Node (TypeScript) используем, когда фронтенд и бэкенд близко или достаточно лёгкого сервиса. Оба варианта зрелые и поддерживаемые.
Какая БД по умолчанию?
PostgreSQL — реляционная, надёжная, зрелая, с pgvector пригодна и для AI-кейсов. Под конкретные задачи (полнотекстовый поиск в большом масштабе, vector-search с большим объёмом, time series) точечно добавляем специализированные хранилища.
Как работаете с auth, ролями и GDPR?
Auth через зрелые провайдеры (Azure AD, Auth0, собственный OIDC), роли и права моделируем явно и держим в коде, а не «прячем в UI». Для GDPR проясняем расположение данных (часто Azure West Europe), договоры обработки, логирование с персональными данными, концепции удаления и audit trail. Это попадает в архитектурный документ, а не «всплывает на аудите».
Как устроен cloud/DevOps-сетап?
Azure как стандартное облако с чётким EU-region-сетапом, Docker для воспроизводимых контейнеров, GitHub Actions для CI/CD с тестами, линтером, typecheck и бюджетами бандла. Несколько окружений (dev/stage/prod), задокументированные деплои, логи/метрики/трейсинг, план бэкапов и восстановления. Если вы уже на AWS или GCP — подстраиваемся, облако не самоцель.
Как безопасно встраиваете AI / LLM?
До первого LLM-вызова определяем: какие данные допустимы, какие ответы приемлемы, как мерить качество. Строим RAG по корпоративным знаниям, evaluation-набор (gold set, регресс), guardrails (prompt-фильтры, валидация выходов, rate limits) и логирование. Для чувствительных данных рассматриваем EU/локальные LLM-опции.
Когда уместна PWA, когда React Native, когда .NET-desktop?
PWA — когда опыт остаётся близким к веб, важны быстрые обновления, и присутствие в сторе не обязательно. React Native — когда нужны реальные native-функции, offline или присутствие в сторах. .NET / WPF — когда нужна Windows-интеграция, долговечная специализированная программа или enterprise-деплой. Выбор по use-case и поведению пользователей, а не по моде.
Как обеспечить поддерживаемость стека без вас?
Три вещи: зрелые технологии с большим talent pool, задокументированные решения (ADR) и структурированная передача с руководством по поддержке, архитектурной документацией и воспроизводимыми деплоями. Систему можно вести своими силами — или с другим партнёром.
Можете встроиться в существующий стек?
Да. Если вы уже на Next.js, React, .NET, Node, PostgreSQL, Azure или сопоставимом — мы подключаемся напрямую. Для legacy-систем начинаем с архитектурного аудита и предлагаем пошаговый путь модернизации — без big-bang-переписываний.
Что, если у вас нет нужной нам технологии?
Говорим об этом честно. Мы не берём проекты «лишь бы взять». Если другой партнёр технически подходит лучше (например, глубокая iOS-native экспертиза или очень специфический промышленный софт), честно рекомендуем — и при необходимости помогаем только на архитектурной фазе.
Связанные услуги и темы
Давайте честно оценим вашу архитектуру.
Кратко напишите, что у вас работает сейчас и что планируется дальше. В первом разговоре разберёмся, где стек устойчив, где риски и какие следующие шаги действительно помогут. Напрямую от основателя, без продажного слоя.