"Просто мелкий фикс" — а на деле полгода рефакторинга

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

И это повторяется чаще, чем кажется.

1️⃣ Разработчику больно смотреть на старый код.

Он хочет переписать «как надо». Это нормально — каждый инженер внутри себя борется за чистоту.
Но если фича только проверяется, и шансы на её выживание — 20%, такой рефакторинг превращается в роскошь.
Важно уметь задавать себе вопрос: это инвестиция или попытка почувствовать контроль?

2️⃣ PM видит задачу как точку в таймлайне.

Если ему не объяснить, сколько на самом деле стоит "улучшить процессинг", он не сможет адекватно планировать.
И не потому что глупый — просто внутри команды нет прозрачного механизма оценки глубины изменений.
А значит, нет доверия к аргументу "нам нужно пару недель, чтобы сделать нормально".

3️⃣ CTO — тот, кто держит рамку принятия решений.

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

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

Как я выбираю C-level партнёров (и почему часто отказываюсь)

Это не про найм — это про совместный полёт на нестабильном корабле, где каждый отвечает за свою часть панели управления.
Когда я думаю об инвестициях или вхожу в стартап как CTO, я первым делом смотрю не на продукт и даже не на рынок. Я смотрю на тех, с кем буду сидеть в кабине пилота, когда начнёт трясти.

1️⃣ Главное — кто с тобой в кабине и держит штурвал

Слишком много проектов рушится не потому, что идея была слабая. А потому что внутри команды — перекосы, туман в ожиданиях и старые обиды.
На уровне C-level это особенно критично. Нельзя просто "разойтись тихо". У каждого уже полномочия, репутация, ответственность, доля.
– Были ли у фаундеров конфликты в прошлом?
– Как они решают споры — через диалог или пассивную агрессию?
– Кто за них готов поручиться?
Удивительно, сколько можно узнать, просто копнув на два уровня глубже обычного общения.

2️⃣ Все формальности — это не про недоверие, а про уважение

– Самые разрушительные конфликты не из-за предательства — а из-за недосказанности. Один думал, что CTO «само собой» будет заниматься наймом, другой — что это задача CEO. И каждый был искренне уверен, что прав.
– Поэтому всё, что можно, мы фиксируем письменно на старте: как делим прибыль, кто принимает решения, что будет, если кто-то захочет выйти.
Важно проговаривать даже «неудобные» темы. Это не убивает доверие — это его создаёт.

3️⃣ Due diligence — не только для компаний, но и для людей

– В маркетинге давно поняли: чтобы продать, нужно 7 касаний. Чтобы доверять в партнёрстве — нужно больше. Я всегда стараюсь несколько раз поработать с человеком, прежде чем зайти в проект. Смотрю, как он ведёт себя в сжатые сроки, как реагирует на неопределённость, как слышит команду.
– И, конечно, подключаю нетворк: кто работал с ним раньше? Что говорят те, кто выходил из совместных проектов? Это мощнее любой презентации.

4️⃣ Доверие — это актив, а не эмоция

Все мы взрослые люди, и партнёрство — это не про то, чтобы всем было «по кайфу». Это про то, чтобы в любой момент можно было встать у белой доски и разложить всё по фактам.
Я ценю партнёров, которые не боятся говорить прямо: что их беспокоит, где не хватает ресурса, почему они хотят изменить направление. Такие разговоры — признак зрелости, а не конфликта.

5️⃣ Оцифровывайте не только продукт, но и отношения

Мы привыкли смотреть на метрики продукта: конверсии, retention, ARPU. Но для C-level команды метрики отношений — не менее важны.
– Кто сколько вкладывает времени?
– Кто сколько инвестирует?
– Какие KPI берёт на себя каждый?
Это не про контроль — это про прозрачность. Оцифровка помогает не искать виноватых, а держать курс.


📌 Где кейсы?
Они не для этого случая 🙂 Раскрывать такое на конкретных примерах было бы неэтично — слишком узнаваемо.
Но могу сказать честно: каждый поинт в этом посте — не теоретический. Всё было пройдено на практике, выстрадано, проверено и принято мной как правило.

Если хоть один из этих принципов отзывается — значит, мы с тобой уже на одной волне.

Стартап только на бумаге — а команда уже нужна. Что делать?

Один из самых простых (и в то же время недешёвых на старте) путей — это собрать свою собственную команду. Такой путь хорошо работает, если у вас уже есть инвестиции, вы нашли рабочую бизнес-модель и уверенно движетесь к проверке гипотез и первым продажам.

Это — классика жанра. Особенно на российском рынке: нанимаете 2–5 ключевых людей — разработчиков, тестировщиков, продакта — и строите продукт вместе. Всё под контролем, команда вовлечена, атмосфера старта чувствуется с первых дней. В следующих постах я покажу и альтернативы, но сегодня хочу подробно пройтись именно по этой классической схеме.

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

Но тут же встаёт вопрос:
а как найти сильных кандидатов, если у вас ещё нет репутации, проекта на слуху и мощного HR-бренда?

На первом этапе всё зависит от фаундеров. Нетворк и ручной найм — вот два основных инструмента. У нас в проектах почти всегда фаундеры (или кто-то из C-level) уже давно сидят на HH. Сильный профиль, хорошие отзывы, релевантные вакансии — и вы начинаете привлекать внимание.

Я не публикую вакансии просто в "любой точке страны". Есть список городов, где сильная база по ИТ-школам и хороший поток кандидатов. Публикация идёт в этих регионах с удалёнкой. Хотите — напишите в личку, поделюсь этим списком, в открытую не выкладываю, чтобы никого не обидеть.

Сразу включаем продвижение: 1000₽ на старте, чтобы не ждать откликов неделями. Цена за клик — хороший ориентир: если она в пределах 5–10₽, значит, вы в рынке. Всё, что выше — уже тревожный звоночек. Возможно, вакансия плохо написана или выбрана не та площадка.

Теперь — самый недооценённый инструмент: авторазбор кандидатов.
У многих соискателей отклик автоматизирован, и просто "пара откликов" вам ничего не даст. Поэтому в саму вакансию включаем пару простых, но точных вопросов — по стеку и по зарплате.
Если вы можете, читая анкету и эти ответы, с 80% уверенностью понять, хотите ли общаться с кандидатом — вы сделали хорошую воронку.
Если нет — стоит переформулировать вопросы.

После авторазбора у нас остаются "тёплые" кандидаты. Те, с кем хочется поговорить, и кто максимально замотивирован. Для этого мы используем Reclaim — кандидат сам бронирует удобное время из ваших вариантов.
Первый созвон — технический, если речь о разработчике. Его проводит CTO.
Если это не техническая роль — выходит CEO.
На второй итерации оба фаундера общаются с кандидатом. На старте важно, чтобы каждый нанимаемый человек был "своим".

Когда выбор сделан, оффер отправляет CEO. Это не только про деньги, это про доверие, культуру, ощущения. И да — закрытие одной позиции обычно занимает не больше недели-двух. Главное — не тормозить, иначе лучшие уходят первыми.

Что я хочу донести этим постом:

Если у вас понятный стек, и вы точно знаете, кого хотите нанять — не бойтесь собирать команду сами. Вам пока не нужен HR. Но вам нужна система: авторазбор, быстрые звонки, внятная воронка и готовность быстро делать офферы.

И да, это только первый способ. В следующих постах покажу, как действовать, если времени нет, бюджета мало, а MVP нужен «на вчера».

Писать или не писать документацию в стартапе

Когда только запускаешь проект — всё кажется важнее, чем документация. MVP, гипотезы, поддержка пользователей. Документация всегда «потом».

Но вот приходят новые разработчики — и тратят неделю, чтобы просто разобраться. Появляется баг — и никто не помнит, как должно было работать. И даже продуктовая гипотеза, которую провалили, остаётся без объяснения «почему так сделали».

Даже пару абзацев про то, что и зачем мы делаем — уже могут спасти ситуацию.

Какие есть варианты:

1. В Notion/Confluence — полная спека. В JIRA — задачи по реализации.

2. На каждую задачу — отдельная страница в Confluence, с ссылкой из JIRA.

Первый вариант даёт целостную картину, но быстро устаревает. Второй — проще поддерживать, но фокус теряется. В любом случае, информация устаревает. Это нормально. Стартап — это про быстрые повороты. И это надо учитывать.

Как оформлять документацию:

Или она отражает целевое состояние (куда идём — как бы «будущее»).

Или она фиксирует текущее состояние (что уже реализовано).

Если документация = «будущее», тогда это компас.
Если документация = «настоящее», тогда это карта.

Важно одно: если обновился продукт — обновилась и документация. Иначе всё быстро ломается.

А что с ресурсами?

Ресурсов нет. Ни времени, ни отдельного человека. Все работают с продуктом. Это норма.

Но даже в этом режиме можно:

- Нарисовать схему архитектуры.
- Описать направление развития.
- Сделать короткий гайд для новичков.
- Составить список ключевых задач и ссылок.

Этого хватит, чтобы:

- Снизить входной порог.
- Упростить обсуждения.
- Не теряться при смене приоритетов.

Если даже на верхнем уровне фиксировать, что мы хотели сделать и почему, — через год получится настоящая ретроспектива. Видно, какие гипотезы запускались, какие решения принимались, и как на это влияли метрики.

Получается, документация — не только «про сейчас». Это уже инструмент управления на основе данных. Источник решений. Вехи роста. Основание, чтобы объяснить выборы и избежать повторов.

Как вы подходите к документации? Или пока обходитесь без неё? Поделитесь, как у вас — интересно сравнить.

[НАЧНИ ОТСЮДА ]

Канал для фаундеров, которые хотят вырастить стартап без костылей

В канале разбираю:
– как пройти путь от MVP до масштабируемого бизнеса, не сливая деньги и время
– как балансировать между скоростью, стоимостью и надёжностью разработки
– как не влезать в технический долг, который невозможно закрыть

Подписывайся на канал и забирай материалы по ведению технической части стартапа от CTO с 8-летним опытом и 20-ю стартапами

Что почитать:
• как выбрать архитектуру стартапа, которую недорого поддерживать
• какие тесты писать, чтобы ничего не падало
• как управлять техническим долгом, чтобы не тормозить развитие стартапа

———

Если ты хочешь, чтобы твой стартап стабильно рос и масштабировался, приходи ко мне на бесплатный аудит технологического стека и процессов

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

Мы с тобой созвонимся, обсудим техничку и у тебя появится план, что тебе делать со своим стартапом дальше

А после решишь — нужна тебе моя помощь или ты сделаешь всё силами своей команды 🙂

Для записи пиши мне в ЛС @DmitryCTO слово «аудит» и мы договоримся о встрече

Почему стресс-тесты и автотесты спасают стартапы

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

📌 Кейс
Мы разрабатывали систему без автотестов, небольшая команда, быстрый рост. Всё шло нормально, пока не пришло время обновления фреймворка. И тут началась гонка:
1️⃣ Поддержка старой версии — клиенты продолжают пользоваться продуктом, баги нужно фиксить.
2️⃣ Разработка новой версии — переписываем всё с нуля, но новые фичи приходится добавлять сразу на обе версии.

Это похоже на ситуацию с рельсами и поездами 🚆:
Старые рельсы ещё в деле, поезда (пользователи) ездят, ломаются, их надо чинить.
Новые рельсы строятся, но если всех сразу пересадить на них, есть риск, что первые баги выкинут клиентов из системы.

💡 Как мы вышли из ситуации:

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

✅ Градусный переход клиентов. В микросервисной архитектуре можно постепенно переводить лояльных пользователей на новую систему, собирая фидбэк. Если что-то идёт не так — возвращаем их на старую версию.

⚖️ Вывод: CTO — это про баланс скорости и рисков. Даже если выбранная технология оказалась ошибкой, управляемый выход из ситуации возможен.

❓ А у вас были случаи, когда пришлось поддерживать старую систему, пока строили новую? Делитесь в комментах! 👇

Почему стресс-тесты — первый шаг к выживанию стартапа

Когда стартап выходит в прод, это всегда русская рулетка. Код писали в спешке, фичи выкатывали на «авось», и никто точно не знает, выдержит ли система нагрузку, если завтра в продукт зайдёт толпа пользователей.

Стресс-тесты — это ваш шанс не облажаться.

Как запустить стресс-тесты без боли
Чтобы не делать это в последний момент, просто сразу добавьте стресс-тесты в процесс. Делается это так:

- Выбираем ключевые сценарии
Что в вашем продукте самое критичное? Логин? Оформление заказа? Оплата? Выберите 2–3 самых важных пути пользователя.

- Определяем инструменты
Я люблю K6 + TypeScript — минимальный вход, хорошая интеграция с Prometheus/Grafana.
Если вам ближе Python — возьмите JMeter, но готовьтесь к боли в настройке.

- Встраиваем в CI/CD
Это важно! Стресс-тесты должны гоняться перед релизом, а не по настроению.
После каждого теста у вас появляются метрики: RPS, среднее время ответа, перцентили 95/99. Всё это загоняется в Grafana, и вы видите, как система реагирует на нагрузку.

Почему это окупается?

💰 Исправить баг до релиза дешевле, чем разбираться с упавшим продом.
📊 Вы накапливаете статистику и можете заранее спрогнозировать проблемы.
🚀 Убираете человеческий фактор — если что-то сломалось, вы узнаете об этом до пользователей.

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

А как у вас с этим? Тестируете нагрузку перед релизами?

Cloud-Agnostic против Проприетарных Ловушек: Разбираем на Примере Elastic Beanstalk

Вы когда-нибудь оказывались в ситуации, когда решение, которое должно упрощать вам жизнь, делает всё наоборот? Мы вот уже три недели боремся с AWS Elastic Beanstalk (хостинг Web-приложений), пытаясь настроить warm pool – механизм, который по идее должен ускорять масштабирование.

🔧 Задача: быстрое масштабирование системы.
⚙️ Решение: используем warm pool в Elastic Beanstalk, чтобы заранее подготовленные инстансы не ждали загрузки с нуля.
💥 Реальность: инстансы поднимаются, но при включении в пул ловят 500 ошибки, не позволяя системе корректно работать.

Что мы сделали?
– Подключили AWS поддержку.
– Провели десятки стресс тестов, создавая изолированные приложения без зависимостей.
– Выяснили, что разобраться сможет один инженер в AWS (либо через посредников типа DoIT), который будет ковырять сетап вручную.

В чем проблема?
Проприетарные облачные сервисы типа Elastic Beanstalk заманчиво выглядят на старте: автоскейлинг, упрощенная настройка, минимум DevOps-рутины. Но когда дело доходит до реальных кейсов, вы внезапно оказываетесь в клетке маркетинговых обещаний:

🚫 Проблема, которую можно было бы решить за пару дней в cloud-agnostic решении, здесь превращается в трехнедельный ад.
🚫 Вы жестко ограничены в инструментах – в отличие от Kubernetes, нельзя просто докинуть нужные плагины.
🚫 Вопросы, которые в Open-Source сообществе решаются тикетом в GitHub или Stack Overflow, здесь требуют дорогой поддержки от провайдера.

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

Cloud-Agnostic – это не про «чтобы было модно», а про свободу
Использование Kubernetes и других cloud-agnostic решений даёт ключевые преимущества:

✅ Гибкость – при проблеме с autoscaling мы просто нашли бы другой подход или плагин.
✅ Большое комьюнити – вместо одного AWS-инженера была бы армия разработчиков, уже решивших похожие кейсы.
✅ Экономия бюджета – стартовое вложение может быть выше, но в долгосрочной перспективе вы не платите за поддержку и несменяемый стек.

💡 Вопрос для CTO и основателей:
Вы выбираете шашечки (красивую маркетинговую обёртку) или ехать (реальную работоспособность и масштабируемость)?

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

❓ Если хотите разобраться, какой сетап лучше для вашего проекта – напишите в личку, обсудим.

🔥 Когда хакеры не спят, а ты катаешь в Японии

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

Был январь, я катал в Японии. Отличный день, сил почти не осталось, швырнул телефон рядом с кроватью и отрубился.

Но… случайно не включил авиарежим.

📲 3 ночи. Телефон начинает вибрировать. Сообщение от команды.

🔴 Аларм от антивируса — уязвимость нулевого дня на одном из виртуальных серверов (EC2).

🤨 Но стоп. У нас же всё EC2 в приватной сети, порты закрыты! Откуда оно проникло?!

🚪 Открытые двери там, где их не должно быть
Пока экстренно гасили заражённый сервер, нужно было понять три вещи:
✅ Проник ли вирус на другие машины?
✅ Ушли ли переменные окружения наружу? Есть ли среди них критические секреты?
✅ Как вообще вирус попал внутрь? Какие порты были раскрыты?

💀 Итог:
EC2 по ошибке оказался в публичной сети. Представьте, что вы сняли офис в закрытом бизнес-центре, у вас охрана, пропускная система, всё по правилам… но вдруг оказывается, что одна дверь (порт) в ваш кабинет открыта прямо на улицу. Без замка. И первый же проходящий нашёл, чем воспользоваться.

Мы моментально скрыли машину за балансировщиками, но вывод был очевиден – ошибка в конфигурации чуть не стоила нам данных.

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

⚠️ Когда твоя система становится интересна хакерам?
Этот случай — напоминание, что чем успешнее ваш сервис, тем больше он привлекает внимание не только пользователей, но и злоумышленников.

Если у вас ещё не было аудита угроз и оценки рисков утечки данных – самое время этим заняться. Проверьте:
🔹 Какие "двери" у вас могут быть открыты?
🔹 Какие секреты лежат на "столе" в зоне видимости?
🔹 Есть ли "камеры", которые вовремя дадут сигнал об угрозе?

🚀 Вывод: Безопасность — это не то, чем стоит заниматься "потом". Если не хакеры, то случайное упущение может устроить вам бодрое утро в 3 ночи 😅

P.S. После этого случая я немного пересмотрел свой подход к "режиму не беспокоить". Теперь у меня специальный фильтр, который пропускает только суперважные звонки от ключевых людей и сервис ilert.com . Так что баланс между отдыхом и безопасностью — возможен 😉

А у вас есть уверенность, что все "двери" закрыты? Делитесь в комментах 👇

🔥 Когда Elastic Beanstalk говорит: «I have a surprise for you»

За пару минут до старта масштабной маркетинговой кампании с «именем, которое называть нельзя» (NDA, дружище) казалось, что всё продумано до мелочей. Инфраструктура подготовлена, стресс-тесты пройдены, автоскейлинг настроен.

Но, как это бывает, жизнь внесла свои коррективы.

🟢 Картинка идеального мира
📞 Общий созвон с партнёрами, DevOps-ами и контракторами. Всё работает, все системы взаимосвязаны, сквозная аналитика по таймингам – красота!

Elastic Beanstalk (AWS-сервис для автоматического развертывания и масштабирования веб-приложений) должен был сделать всю работу за нас: если трафик растёт, он поднимет новые инстансы, балансировщик всё раскидает, и пользователи ничего не заметят.

Мы готовимся к плавному росту нагрузки, словно пилоты перед взлётом – полный контроль, приборы в норме.

Но потом...

🔴 БАХ!
📈 Нагрузка выстрелила экспоненциально за 3 минуты вместо ожидаемых 5–10. Наши триггеры автоскейлинга были настроены на 5-минутные интервалы.

Elastic Beanstalk начал поднимать новые серверы (EC2 – виртуальные машины в AWS), но тут начались сюрпризы:

❌ Поднятые инстансы оказались с некорректными правами – они не могли подключаться к критичным сервисам.
❌ Балансировщик не добавлял их в рабочую группу, потому что они не проходили Health Check.

🕰️ Результат: трафик растёт, а мощностей для обработки нет.

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

⚡ План B (а потом C, D, E…)
В экстренном режиме пришлось:
🔹 Поднять клон окружения, отключить Enhanced Health Check, чтобы пропускать инстансы быстрее.
🔹 Врубить туда дополнительную мощность с запасом и оперативно перевести трафик.
🔹 Переключить балансировщик, чтобы нагрузка распределилась равномерно.

Elastic Beanstalk – штука крутая, когда всё идёт по плану. Но когда он начинает "думать за тебя", иногда проще перехватить управление вручную.

🎯 Не учебник, а чистый боевой экспромт. Но этот манёвр спас нас от катастрофы. Контракт в безопасности, клиенты довольны, а мы – почти без нервных срывов.

🛠 Выводы для CTO и DevOps
✅ Нагрузка может вырасти мгновенно – моделируйте жёсткие сценарии.
✅ Держите в запасе несколько планов действий. Если бы у нас не было второго плана, последствия были бы печальными.
✅ Elastic Beanstalk – удобно, но требует контроля. Не надейтесь на "мы же тестили" – в проде всё сложнее.

🚀 В общем, будь готов к любым сюрпризам. Лёгких и плавных запусков твоим проектам!

А у тебя было такое, что облако неожиданно подкинуло проблем? Делись в комментах! 💬

Как я открыл для себя фрирайд — и почему теперь не могу без него

Всё началось на первом курсе, когда друг позвал меня в Шерегеш. Я тогда вообще не знал, что такое сноуборд, кроме кадров с Олимпиады в Нагано-98. Денег на инструктора не было, да и зачем? "Просто берёшь и едешь", — сказал друг.

Ну, я и поехал. Кубарем вниз 😂, собирая все возможные ошибки и синяки. Но что-то в этом зацепило — чувство, что я хочу разобраться, почувствовать контроль.

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

После восьмой-девятой поездки трассы начали казаться скучными. Тогда мы впервые выехали за пределы трасс — в лёгкие редколесья Панорамы 🌲❄️. Тогда это ещё было относительно легально, никто не запрещал фрирайд.

И вот мой первый момент вне трассы: идеально ровный нетронутый снег, доска начала сама делать дуги, снег взрывается за спиной 💭. Это было легко, естественно, будто ты плывёшь. Тогда я понял, что это совсем другое измерение.

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

Я открыл для себя Нисеко, Япония 🇯🇵 — идеальное место для паудера в январе-феврале. Свежий снег каждый день, бездонные сугробы 🏔️, и после каталки — горячий онсен и японская еда 🍜.

А в конце февраля я возвращаюсь в Шерегеш — но уже в фрирайд-туры на ратраке. Это совсем другой уровень: тебя забрасывают на вершины, куда не добраться на подъёмниках, и ты летишь по первому следу.

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

Фрирайд — это не про катание. Это про ощущения, которые остаются с тобой навсегда. 🤍

А где твой идеальный паудер? Делись в комментах 👇😎