О студии
ЧБ-studio — студия заказной веб-разработки. Делаем веб-сервисы, личные кабинеты, интернет-магазины и B2B-порталы, автоматизируем процессы и связываем системы обменом данными.
Четыре направления, на которых держится любой наш проект. Мы вышли из серверной разработки, поэтому начинаем с данных и архитектуры, а интерфейс собираем как следствие.
Python: Django и FastAPI, включая проекты, которые стартовали на Django 1.4 и Python 2.7. Go — для сервисов, где важны нагрузка, отказы и предсказуемость. Значительная часть работы приходила в виде чужого кода, который нужно понять, не сломать и развивать дальше, — это отдельный навык, и он у нас есть.
PostgreSQL и Redis в основе; MSSQL, MySQL, MariaDB, MongoDB и ClickHouse — когда задача требует другого хранилища, а не моды на него. Схему, индексы и правила миграции проектируем до интерфейса: это дешевле, чем переделывать после первых жалоб на скорость.
Linux, Docker, Kubernetes, CI/CD. Развёртывание, обновления, журналы и мониторинг — наша часть работы, а не то, что передаётся отдельному подрядчику после сдачи. Поэтому при сбое мы понимаем, где смотреть, а не выясняем это вместе с вами.
Vue 3 и Nuxt. До этого — jQuery, Pug и Sass на десятках сайтов, поэтому чужую вёрстку читаем и поддерживаем, а не требуем переписать её целиком. Интерфейс для нас — слой над сценариями и данными, а не отправная точка проекта.
Команды, в которых мы работали, делали системы для оптовой торговли, общепита, промышленности, недвижимости и финтеха. Это не портфолио студии, а практика, которую мы приносим в проекты.
Интернет-магазин канцелярских товаров: каталог на десятки тысяч позиций, цены, заказы и обмен с учётной системой.
Архитектура системы учёта и акций для сети быстрого питания: правила расчёта, скидки и отчётность по точкам.
Наблюдение за техпроцессом на заводе: сбор данных с оборудования и контроль хода процесса. Отвечали за техническую часть проекта.
Три внутренних сервиса для застройщика: передача квартир покупателю, гарантии и инвестиционный контроль с 3D-моделью объекта и отчётами по срокам и стоимости.
Сервис на ГОСТ-криптографии, через который проходят банковские операции. Требования к надёжности и проверкам здесь выше, чем в обычном проекте.
Парсеры, телеграм-боты и мини-приложения, интеграции с кассами, 1С, Битриксом и службами доставки.
Из этой практики — работа с производительностью. Переезд импортёра с Python на Go заметно ускорил загрузку и снизил потребление ресурсов. Самый тяжёлый импорт каталога на 30 000+ позиций проходит меньше чем за минуту, потому что обновляются только изменения, а не весь справочник.
Пять направлений, которые чаще всего пересекаются в одном проекте: интерфейс, бизнес-логика, данные и обмен между системами.
Внутренние и клиентские продукты с нестандартной логикой, ролями и данными. Подробнее — заказная разработка.
Перенос заявок, документов и статусов из Excel, почты и мессенджеров в одну систему. Раздел — автоматизация.
Обмен с 1С, CRM, ERP, платежами, доставкой и внешними API. Раздел — интеграции.
Каталог, поиск, заказ, личный кабинет и индивидуальные условия. Разделы — интернет-магазины и B2B-порталы.
Сайт можно заказать за цену обеда, и иногда это правильный выбор: лендингу на одну акцию не нужна студия. Разница проявляется позже — когда появляется вторая интеграция с учётом, третий тип цен, импорт каталога на десятки тысяч позиций и вопрос «почему сумма считается неверно».
Дальше проект либо переписывают, либо он живёт с ограничениями, о которых уже никто не помнит. Мы приходим из инженерии, а не из вёрстки: схема данных и индексы обсуждаются до интерфейса, миграция планируется заранее, а «работает у меня локально» не считается результатом.
Если задача проще — мы так и скажем. Нам интереснее системы, которые работают и развиваются, а не собираются за вечер и разваливаются на втором изменении.
Модель данных и архитектура — до первой строки кода
Отклик держим в пределах 500 мс, а не «как получится»
Чистый SQL там, где он даёт выигрыш; ORM — для скорости разработки
Обмен проектируем с отказами, повторами и сверками
Развёртывание и эксплуатация — наша часть работы
Правила, по которым строятся проекты. Они не зависят от размера задачи и не меняются от этапа.
Начинаем с того, как процесс устроен сейчас: кто принимает заказ, где хранятся данные, что происходит после оплаты. Технологию выбираем под эти ответы, а не наоборот.
В описании работ фиксируем, что входит в первую версию, а что остаётся за рамками. Так порядок цен понятен до того, как появятся первые экраны.
Приёмка идёт по действиям пользователя: найти товар, оформить заказ, сверить остатки, повторить покупку. Красивый экран без рабочего сценария не считается готовым.
После запуска остаются обновления каталога, правила цен, новые интеграции и исправления. Мы продолжаем вести проекты, которые развиваются.
Стек не самоцель, но он определяет, насколько предсказуемо проект будет развиваться через год. Здесь перечислено то, что мы используем в собственных проектах.
smolevakuator.ru — сайт службы эвакуации и спецтехники в Смоленске: услуги, цены, парк техники и приём заявок круглосуточно.
Проекты, которые делали команды до того, как мы собрали студию, описываем как опыт: что за задача была и как её решали. Показывать их как своё портфолио было бы неправдой.
Как мы обращаемся с данными посетителей сайта, описано в политике конфиденциальности.
Следующий шаг
Расскажите, какой продукт или систему нужно реализовать. После обсуждения подготовим предварительную оценку и уточним её, когда согласуем функции, интеграции и объём первой версии.
