Продуктовая студия · работаем по России

Из задачи бизнеса —
в ясную систему.

Проектируем и запускаем CRM, сервисы, приложения и франшизы. Сначала разбираемся в задаче, затем собираем под неё продукт и команду.

От первого сценария до работающего продукта

Продуктовая модельПроектированиеДизайнРазработкаЗапуск
01 / Принцип

Не начинаем с разработки. Начинаем с того, что должно измениться в бизнесе.

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

Разбираемся в задаче.
Собираем решение.

02 / Выбранные проекты

Шесть кейсов.
За каждым — своя задача.

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

01B2B-сервис · Сделкиdoroge.ru

Дороже

От оценки бизнеса — к готовности к сделке

Собрали сервис предварительной оценки бизнеса: от пошаговой анкеты до диапазона стоимости, оценки качества данных и рекомендаций по подготовке к продаже.

Задача

Перевести сложный процесс оценки и продажи готового бизнеса в понятный цифровой маршрут.

Что внутри

  • Анкета с сохранением и личный кабинет
  • План роста и подготовки к продаже
  • Три расчётных подхода и факторы риска
  • Качество исходных данных и история оценок
Открыть проект
Деловой городской пейзаж проекта Дороже
01 Оценить02 Подготовить03 Продать
План сделкиСледующий шаг понятен От оценки до подготовки к продаже
Подробности проектаКак мы это собрали: Дороже

Продуктовая логика · интерфейс · расчётное ядро · серверная часть

01 Интерфейс · frontend

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

02 Серверная часть · backend

Разработали API анкеты и оценки, хранение результатов и расчётное ядро. Оно объединяет доходный, сравнительный и мультипликаторный подходы, учитывает отрасль и факторы риска.

03 Что было сложным

Одна и та же прибыль не делает два бизнеса одинаковыми. На оценку влияют зависимость от собственника, концентрация клиентов и качество исходных данных. Эти различия нужно учитывать, не превращая анкету в экзамен по финансам.

04 Как решили

Разделили ввод данных, нормализацию и расчёт. Вместе с диапазоном стоимости показываем качество данных и рекомендации — чтобы собственник понимал не только сумму, но и то, над чем работать дальше.

Что получилось

Получился цифровой маршрут от описания бизнеса к расчётному диапазону стоимости и плану подготовки. Это инструмент для предварительного анализа, а не обещание продать бизнес по указанной цене.

  • TypeScript
  • Hono
  • JavaScript
  • PostgreSQL-адаптер
02Premium SaaS · AIzelenynefrit.ru

Зелёный нефрит

Сложные расчёты. Понятный личный опыт.

Спроектировали премиальный сервис китайской метафизики: точные расчёты выполняет система, а AI помогает человеку понять результат и применить его к своей ситуации.

Задача

Соединить профессиональную глубину трёх систем с ясным клиентским опытом.

Что внутри

  • Ба-цзы, Цзы Вэй Доу Шу и Ци Мэнь
  • Детерминированные расчёты
  • AI-интерпретация и уточняющие вопросы
  • Личный кабинет и история карт
Открыть проект
Персональная карта
Интерфейс персональной карты Ба-цзы в сервисе Зелёный нефрит
3системы
в одном сервисе
Подробности проектаКак мы это собрали: Зелёный нефрит

Сайт · личный кабинет · расчёты · AI-интерпретация

01 Интерфейс · frontend

Собрали публичный сайт и интерфейсы сервиса: регистрацию, личный кабинет, карты Ба-цзы, Цзы Вэй и Ци Мэнь, историю, диалог и экспорт. У каждой системы — своя форма представления, но общая навигация.

02 Серверная часть · backend

Реализовали API на Python, модели пользователей и карт, расчётные модули и слой AI-интерпретации. История и исходные данные карты сохраняются отдельно от текста ответа.

03 Что было сложным

Свести разные традиционные системы в один продукт и не поручать языковой модели вычисление самой карты. Отдельная инженерная задача — календарные границы, часовой пояс и поправка на местное солнечное время.

04 Как решили

Вынесли расчёты в отдельное ядро, а в AI передаём уже рассчитанные данные. Так исходная карта не зависит от формулировки ответа модели. Расчётные значения и традиционная интерпретация разделены по роли в продукте.

Что получилось

Собран сервис, в котором пользователь может построить карту, вернуться к ней в кабинете и получить объяснение в диалоге. Расчётное ядро, история и интерпретация работают как части одного пользовательского сценария.

  • Python / FastAPI
  • SQLAlchemy
  • HTML / CSS / JavaScript
  • AI + база знаний
03TravelTech · В разработкеtaiga-more.ru

Тайга.Море

Целая поездка, а не только бронирование дома

Создаём региональный сервис бронирования загородного отдыха: жильё, места и занятия складываются в целую поездку.

Задача

Помочь гостю выбрать отдых по желаемому опыту, а владельцу — управлять предложением и бронями.

Что внутри

  • Каталог домов и впечатлений
  • Карта и география Приморья
  • Сценарии гостя, партнёра и администратора
  • Бронирование и Telegram-коммуникация
Открыть проект
Побережье Приморского края
База отдыха у моря в каталоге Тайга.Море
Отдых у моряДомик + маршрут + впечатление
Приморье
Подробности проектаКак мы это собрали: Тайга.Море

Продукт в разработке · сайт · три кабинета · бронирование

01 Интерфейс · frontend

Разработали каталог, карту, страницы объектов и мест, избранное и личный кабинет гостя. Для владельца предусмотрены управление объектами, календарь и брони; для администратора — модерация и контроль заявок.

02 Серверная часть · backend

Собрали серверные маршруты, модель данных в PostgreSQL, проверку доступности дат и расчёт стоимости проживания с дополнительными услугами. Реализованы роли, загрузка изображений и уведомления.

03 Что было сложным

Бронирование — это не просто форма заявки. Два гостя могут выбрать одни даты одновременно, стоимость зависит от календаря и услуг, а разные участники должны видеть только свою часть процесса.

04 Как решили

Стоимость рассчитывается на сервере. Бронирование выполняется в транзакции с блокировкой объекта и ограничением занятых дат в базе. Сбой отправки уведомления не должен отменять уже созданную бронь.

Что получилось

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

  • Next.js / React
  • TypeScript
  • PostgreSQL
  • S3 / Telegram
04Франшиза · Сайт · CMSokna-balkony.com

Окна и балконы

Бизнес-модель, готовая к масштабированию

Упаковали предложение для будущего партнёра и собрали сайт с управляемым содержанием: от состава франшизы и этапов запуска до материалов и заявок.

Задача

Сделать бизнес-модель понятной партнёру и дать команде возможность обновлять предложение без переделки сайта.

Что внутри

  • Упаковка и сайт франшизы
  • Структура пакета и этапы запуска
  • Управление блоками, файлами и изображениями
  • Заявки и уведомления команды
Открыть франшизу
Окна и балконыВсё связано
Схема системы
  1. 01
    Предложение

    Модель, состав пакета и условия

  2. 02
    Упаковка

    Материалы, этапы запуска и поддержка

  3. 03
    Сайт и CMS

    Управляемые блоки и обращения партнёров

Следующий уровеньГотовая модель для партнёра

Содержание можно обновлять по мере развития франшизы.

Подробности проектаКак мы это собрали: Франшиза «Окна и балконы»

Упаковка предложения · сайт франшизы · CMS · заявки

01 Интерфейс · frontend

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

02 Серверная часть · backend

Реализовали сервер сайта и систему управления контентом: блоки страницы, изображения, файлы и обращения. Данные хранятся в SQLite; для заявок предусмотрены уведомления по почте и в Telegram.

03 Что было сложным

Превратить опыт действующей компании в предложение, которое можно изучить и сопоставить со своими возможностями. При этом состав пакета, условия и материалы должны обновляться без переписывания страницы.

04 Как решили

Разделили содержание франшизы на управляемые блоки. Связали сайт с материалами по продажам, этапам запуска и устройству бизнеса; добавили административную часть для обновления предложения.

Что получилось

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

  • Node.js / Hono
  • SQLite
  • HTML / CSS / JavaScript
  • CMS / уведомления
05E-commerce · Развитие магазинаgreenjade-market.ru

Зелёный нефритМагазин

От торговой витрины — к системе работы с каталогом

Интернет-магазин изделий из камня и предметов для дома. Для его развития подготовили контентную структуру и расширения для обмена товарами, остатками и заказами.

Задача

Развивать содержание и связи магазина с внешними системами, сохраняя действующие покупательские сценарии.

Что подготовлено

  • Структура статей с переходами к товарам
  • API каталога и заказов
  • Расширение для изображений и остатков
  • Проверки повторных запросов и прав доступа
Открыть магазин

Схема продукта · не скриншот

Зелёный нефритПредмет.
История.
Выбор.
МатериалКаталогТовар
Подготовленный слой интеграций
ТоварыОстаткиЗаказы
Подробности проектаКак мы это собрали: Магазин «Зелёный нефрит»

Интернет-магазин · контентная структура · подготовка интеграций

01 Интерфейс · frontend

В центре проекта — торговая витрина с каталогом и карточками изделий. Для её развития подготовлена структура тематических материалов: статья помогает разобраться в предмете и ведёт к подходящей категории или товару.

02 Серверная часть · backend

Подготовлен код расширения API для каталога и заказов, создания и обновления товаров. Отдельное расширение добавляет работу с изображениями и остатками. Подключение этих расширений к рабочему магазину требует отдельной проверки.

03 Что было сложным

Расширять действующий магазин, не затрагивая без необходимости корзину и оплату. Повторный запрос внешней системы не должен создавать дубликат товара или повторять уже выполненное действие.

04 Как решили

В подготовленном API предусмотрены права доступа по операциям, проверка входных данных, ключи повторных запросов и контроль SKU. Для внедрения описан порядок небольших изменений с резервной копией и откатом.

Что получилось

Подготовлены контентный план и интеграционный слой для развития магазина: работа с товарами, заказами, изображениями и остатками. Следующий этап — проверка подключения расширений к действующей витрине.

  • JavaScript / Node.js
  • SQLite
  • API товаров и заказов
  • Контентная структура
06B2B-платформа · Направление «Дороже»doroge.ru/broker

Дороже Брокер

Объявление становится началом управляемого процесса

Собрали отдельное направление платформы: предложения бизнеса, франшиз и инвестиций, кабинеты участников, модерацию и работу с обращениями.

Задача

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

Что внутри

  • Каталог, фильтры и карточки предложений
  • Кабинет и управление публикациями
  • Модерация и разграничение прав
  • Статусы обращений и история событий
Открыть направление

Схема продукта · не скриншот

Дороже / БрокерУ каждого шага
есть статус.
  1. 01
    ПредложениеБизнес · франшиза · инвестиции
  2. 02
    Проверка и публикацияМодерация перед выходом в каталог
  3. 03
    ОбращениеКвалификация и дальнейшие переговоры

Публичная витрина + рабочий кабинет

Подробности проектаКак мы это собрали: Дороже Брокер

Отдельное направление платформы «Дороже» · каталог · кабинеты · API

01 Интерфейс · frontend

Собрали отдельный сценарий для предложений готового бизнеса, франшиз и инвестиций: каталог, карточки, поиск и фильтры. В кабинете — свои предложения, избранное, отправленные и входящие обращения.

02 Серверная часть · backend

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

03 Что было сложным

Каталог сделок нельзя устроить как обычную доску объявлений. Черновик не должен попадать в публичную выдачу, участники имеют разные права, а обращение проходит несколько этапов до переговоров.

04 Как решили

Разделили публичный каталог, кабинет участника и административную часть. Публикация проходит через модерацию; обращения имеют свои статусы и защиту от повторного активного запроса на тот же объект.

Что получилось

Получился отдельный продуктовый сценарий внутри «Дороже»: от размещения предложения до учёта заинтересованных покупателей. Это самостоятельный кейс по задаче и интерфейсу, на общей технологической основе платформы.

  • TypeScript / Hono
  • React
  • Модерация и роли
  • История событий
03 / Что собираем

Берём задачу целиком.
Команду собираем под неё.

Можно прийти с готовым запросом, сырой идеей или процессом, который давно пора перестать вести вручную.

01

Продукт с нуля

Проверяем логику, проектируем сценарии, создаём интерфейс и запускаем первую рабочую версию.

Сервис · приложение · SaaS
02

Система внутри бизнеса

Оцифровываем продажи, производство, расчёты и управленческий контур без лишней сложности.

CRM · кабинеты · автоматизация
03

Платформа или маркетплейс

Связываем стороны рынка, правила, каталог, платежи и операционные роли в единой системе.

Каталог · бронирование · платежи
04

Франшиза под запуск

Собираем предложение, экономику, процессы, материалы и цифровые инструменты для партнёра.

Модель · упаковка · запуск
04 / Как работаем

Сначала ясность.
Потом сборка.

У проекта появляется один маршрут и одна точка ответственности — от первого разговора до работающей системы.

  1. 01

    Разобраться

    Фиксируем задачу, контекст бизнеса, ограничения и критерий полезного результата.

  2. 02

    Спроектировать

    Собираем продуктовую модель, роли, сценарии, структуру данных и интерфейс.

  3. 03

    Собрать

    Подключаем нужных специалистов и ведём разработку по понятным этапам.

  4. 04

    Запустить

    Проверяем на реальной работе, выпускаем и развиваем на основании обратной связи.

05 / О компании

Небольшое ядро.
Нужный масштаб под проект.

Продуктовая студия с личным участием основателя в каждом проекте.

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

Один ответственный за целое. Нужные специалисты — для каждой части.

06 / Коротко о важном

До первого разговора

Нужно ли готовое техническое задание?+

Нет. Достаточно описать проблему своими словами. Техническую и продуктовую постановку мы соберём вместе.

Можно заказать только разработку?+

Можно, если логика продукта уже проверена. Если нет — сначала коротко разберём её, чтобы не автоматизировать ошибку.

Как формируется команда?+

Под конкретную задачу. Небольшой проект не оплачивает лишнюю структуру, а для большого собирается полноценная команда.

Можно начать с небольшого этапа?+

Да. Первый этап может закончиться концепцией, прототипом или планом реализации — результатом, по которому легко принять следующее решение.

Первый шаг

Есть задача, которую пора собрать в работающий продукт?

Опишите её своими словами. Без готового ТЗ и технических терминов — этого достаточно, чтобы начать разговор.

Написать о задаче