Задача выбирает технологию
Мы не начинаем с любимого фреймворка. Сначала разбираем процесс: сколько пользователей, какие данные, нужен ли офлайн, кто будет это поддерживать. Стек — следствие ответов, а не начальное условие.
Обсудить проектСтек, на котором мы собираем системы
От десктопных приложений и корпоративных сайтов до веб-ERP. Подбираем технологии под задачу, а не задачу под технологии.
Ниже — не список логотипов, а объяснение, в каких ситуациях мы берём тот или иной инструмент. Если вам не хочется в это вникать — не нужно: выбор стека наша ответственность, а страница существует для тех, кто хочет понимать, за что платит.
Frontend
Интерфейсы веб-приложений и сайтов
Next.jsReactTypeScriptJavaScriptHTML5CSS3TailwindThree.js
Next.js и React берём, когда интерфейс должен быть быстрым и при этом хорошо индексироваться: страницы отдаются готовыми с сервера, а сложные экраны остаются интерактивными. TypeScript отсекает целый класс ошибок ещё до запуска — на длинной дистанции это дешевле, чем ловить их в проде.
Backend
Серверная логика и API
NestJSNode.jsPythonTypeScriptREST APIGraphQL
NestJS даёт строгую модульную структуру: у сервиса, который будет расти модулями годами, границы между частями должны быть заданы фреймворком, а не договорённостями в команде. Python выбираем там, где нужны обработка данных, интеграции и скрипты автоматизации.
Базы данных
Хранение и работа с данными
PostgreSQLSQLiteMySQLRedis
PostgreSQL — основа для систем, где данные связаны между собой и важна целостность: сделки, документы, остатки, история. SQLite ставим в офлайн-приложения, где вся база должна жить одним файлом рядом с программой. Redis — для очередей и кэша, когда появляется нагрузка.
Инфраструктура
Запуск, доставка и надёжность
DockerNGINXVPSLinuxCI/CDGit
Docker фиксирует окружение: система одинаково ведёт себя на машине разработчика и на сервере. NGINX закрывает HTTPS, отдачу статики и защиту, CI/CD убирает ручной деплой — а вместе с ним и типовую причину падений при выкладке.
CMS и контент
Управление контентом без кода
StrapiHeadless CMS
Headless CMS подключаем, когда команда клиента должна сама менять тексты, новости и карточки, не обращаясь к разработчику. Контент живёт отдельно от кода, поэтому обновление страницы не требует релиза.
AI и данные
Интеллектуальные функции
OpenAI APIAI-ready архитектураVector SearchАналитика
AI подключаем точечно и под конкретный сценарий: разбор входящих обращений, поиск по внутренним документам, черновики ответов. Архитектуру закладываем «AI-ready» заранее — чтобы добавить такой модуль позже можно было без переписывания системы.
Десктоп
Офлайн-приложения
Python Desktop UIOffline-firstЭкспорт Excel/PDF/Word
Десктоп выбираем там, где интернет ненадёжен или не нужен вовсе: пост охраны, склад, стоянка. Программа работает локально, база лежит рядом, а выгрузки в Excel, PDF и Word закрывают отчётность без отдельного сервиса.
Подход
Как мы строим
Modular monolithКонцепция и ТЗ до кодаПрототип до вложенийИстория и надёжность данных
Сначала концепция и архитектура, потом код: переписывать документ дешевле, чем систему. Modular monolith даёт скорость старта без операционной сложности микросервисов, а разделить его на сервисы можно позже — когда нагрузка действительно этого потребует.
Как мы выбираем технологии
Скучные решения там, где важна надёжность
В основе систем стоят зрелые инструменты с большим сообществом и предсказуемым поведением. Эксперименты уместны в изолированных местах, а не в фундаменте, на котором держится учёт компании.
Систему должно быть кому поддерживать
Мы избегаем редких технологий, под которые сложно найти разработчика. Проект не должен оказаться в заложниках у одного человека — включая нас.
Данные важнее кода
Код можно переписать, потерянные данные — нет. Поэтому история действий, резервные копии и понятная схема базы закладываются с первой версии, а не добавляются после первого инцидента.
Не уверены, что подойдёт вам?
Это нормально — выбор технологий наша забота, а не ваша. Расскажите задачу, а мы предложим решение и объясним выбор простыми словами.
Обсудить проект