en
Feedback
Антон Тарасенко | IT-ментор для фаундеров

Антон Тарасенко | IT-ментор для фаундеров

Open in Telegram

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

Show more
The country is not specifiedThe category is not specified
182
Subscribers
-124 hours
No data7 days
No data30 days
Posts Archive
Пятница - отличный день вспомнить одну из моих любимых историй из ИТ. В 2011 году команда Netflix придумала очень необычную практику: Chaos Monkey. Это специальный инструмент, который… ломает их систему в продакшене. Причём специально и в рабочее время. Да-да, он просто случайным образом «вырубает» сервисы, и команда должна быстро восстанавливаться. Логика у них была простая: если всё будет падать только «по-настоящему» и неожиданно, это всегда будет стресс и проблемы. А если падения происходят постоянно и предсказуемо команда учится держать систему устойчивой. Сначала идея казалась безумной. Но потом именно благодаря такому подходу Netflix сделал свою инфраструктуру настолько надёжной, что сбои стали редкостью. 📌 Для меня в этой истории есть хороший урок: иногда лучше потренироваться на «мини-хаосе» и научиться работать с проблемами, чем ждать, когда настоящий хаос застанет вас врасплох. И да, пятница - тоже неплохой день, чтобы проверить, насколько система готова к неожиданностям 🙂 Хотя лить на продакшен все-таки не стоит.

🔥 ГЛАВНЫЕ ИНСАЙТЫ эфира с Антоном Тарасенко Сооснователем YotaPhone, экс-CTO Yota Devices, создателем DNA Team 🚀 О старте и философии YotaPhone: «Ничего невозможного нет» — ключевой принцип, который Антон вынес из работы над первым российским смартфоном с двумя экранами. Идея родилась на выездной сессии с участием всех отделов — от бухгалтерии до дизайнеров. Сняли все ограничения: «Что может быть через 20 лет?». Были и другие концепты — например, телефон без единого разъема (беспроводная зарядка тогда только зарождалась). 💡 Почему YotaPhone не стал «российским Apple»: Ключевая ошибка заключалась в том, что проект перестали финансировать и развивать. Вместо того чтобы продолжать инвестировать в продукт и российские команды, создавая и укрепляя внутренние компетенции, финансирование было остановлено. В результате не удалось сформировать устойчивую экспертизу и экосистему для дальнейшего роста Возможность была: создать экосистему устройств (планшеты, роутеры, USB-донглы) и компетенции для импортозамещения не в виде «переклеивания бирок», а реальной разработки. 🤝 Как заходить в крупные компании (ВТБ, Касперский, Aviasales): Важно быть открытым к общению, не пренебрегать небольшими задачами, не ждать сразу крупных проектов и не стремиться сразу взобраться на Эверест. Сначала стоит пройти путь с малого — попробовать свои силы на небольшой высоте, постепенно наращивая опыт и компетенции Глубокий бесплатный пресейл: 3-4 созвона, чтобы выявить боли, предложить решения «в стол» и стать своим. ⚠️ Топ-3 ошибки в IT-стартапах (на примере своего провала): Создавать продукт без проверки гипотез — «нужен ли он кому-то, кроме тебя?». Делать сложное MVP — вместо минимальной версии, которая закрывает боль. Не искать ментора — особенно если нет опыта в разработке. Иначе — слив денег и времени. 🛡️ Как не наступать на грабли в tech-бизнесе: Технологическая часть — главный риск: юридические вопросы, права на код, передача продукта между командами. Ищите того, кто уже прошел этот путь — иначе рискуете утонуть в «невидимых» проблемах. Time to market должен быть минимальным — но без потери качества. 💬 Финальный совет от Антона: Если вы хотите создать tech- или IT-продукт, начните с максимального упрощения идеи. Определите, какое именно ключевое решение вы предлагаете и какую проблему оно закрывает. Отбросьте всё второстепенное и прежде, чем приступать к реализации, пообщайтесь с целевой аудиторией, чтобы убедиться: проблема действительно существует, а предложенное вами решение востребовано. И только после этого начинайте разработку. Оптимально — найти опытного IT-наставника, который поможет избежать лишних затрат и облегчит прохождение этого пути.

🚀 Через 20 минут встречаемся на прямом эфире! Говорим о том, как делать технологичные продукты мирового уровня в России 📅 Дата: СЕГОДНЯ Время: 19:30 (по Москве) 🎙 Ведущий: Роман Дусенко — консультант, психолог, экс-банкир. Разбирает бизнес-стратегии и психологию принятия решений. 💡 Гость: Антон Тарасенко — Экс-CTO Yota Devices, со-изобретатель первого в мире смартфона с двумя экранами, основатель студии DNA Team (ВТБ, Касперский, Aviasales, Эрмитаж). На эфире разберем по косточкам: ✔️ Создание иконы: Как рождался YotaPhone — самый необычный российский гаджет, покоривший мир. ✔️ Работа с гигантами: Секреты сотрудничества с ВТБ, «Лабораторией Касперского» и Aviasales. Как попасть в их число подрядчиков? ✔️ Запуск своих сервисов: Честно о взлетах и падениях с CoActivity и LookLink. ✔️ Менторство: Как технологическому предпринимателю не наступить на грабли и решать сложные операционные задачи 🔗 Подключайтесь к эфиру по ссылке: https://t.me/DuLinksBot

Всем привет! Хочу поделиться важной новостью — мы в DNA team запустили новое направление, о котором меня часто спрашивали пос
Всем привет! Хочу поделиться важной новостью — мы в DNA team запустили новое направление, о котором меня часто спрашивали последние месяцы. Мы сделали ставку на внедрение ИИ под ключ. Это ИИ-агенты, цифровые ассистенты, RAG-решения, которые реально разгружают команды и приносят экономию. Сначала мы считаем выгоду, исследуем бизнес, и только потом начинаем разработку. Такой подход уже позволяет существенно снизить риски пустых затрат. Более подробно и красочно рассказали здесь: https://dnateam.ru/ai На сайте можно пройти тест и получить мой крутой авторский PDF-материал «Внедрение ИИ: от идеи к измеримым результатам» Если вы долго думали с чего бы начать внедрение ИИ в свой бизнес — там для вас есть готовые шаги и пример с кейсом. Для нас это новый этап, а для вас — возможность за 4 недели увидеть, как ИИ работает именно в вашем бизнесе.

🔥 ПРЯМОЙ ЭФИР: Как запустить технологичный продукт и не сгореть? 📅 Дата: 21 августа ⏰ Время: 19:30 (МСК) 🎙 Ведущий: Роман Дусенко — бизнес-консультант, психолог, экс-банкир. Автор стратегий для предпринимателей. 💡 Гость: Антон Тарасенко — экс-CTO Yota Devices, один из создателей легендарного YotaPhone, основатель DNA Team (проекты для ВТБ, Касперского, Aviasales, Эрмитажа). 🔗 Жми, чтобы получить ссылку на эфир

🎙 ПРЯМОЙ ЭФИР: Психология решений + Технологии = Устойчивый IT-бизнес 📅 21 августа ⏰ 19:30 (МСК) 📌 Ведущий: Роман Дусенко
🎙 ПРЯМОЙ ЭФИР: Психология решений + Технологии = Устойчивый IT-бизнес 📅 21 августа19:30 (МСК) 📌 Ведущий: Роман Дусенко — бизнес-консультант, психолог и коуч. Знает изнутри мир финансов и управленческих решений. 📌 Гость: я, Антон Тарасенко — экс-CTO Yota Devices, один из создателей YotaPhone, основатель студии разработки DNA Team (проекты для ВТБ, Касперского, Aviasales, Эрмитажа). 💬 Почему я очень хочу, чтобы вы посмотрели этот эфир Роман — не просто раскрывает гостей, а помогает людям глубже понять себя, выстраивать личные стратегии и находить точки роста. С ним разговор уходит за рамки «как сделать продукт» и затрагивает то, что реально влияет на успех — наши решения, мышление, внутренние установки и ресурсы. 📌 О чём поговорим: • Как психология принятия решений помогает создавать устойчивые технологичные продукты. • Мой опыт создания YotaPhone — что стояло за первым российским смартфоном с двумя экранами. • Кейсы DNA Team и работа с крупнейшими брендами. • Как не выгореть в стартапе и сохранить энергию на длинной дистанции. • Какие советы я даю как ментор IT-бизнеса. 🚀 Эфир будет полезен, если вы: • Запускаете или развиваете технологичный продукт. • Хотите работать с крупными клиентами и понимать, как они выбирают подрядчиков. • Ищете баланс между ростом бизнеса и своим ресурсом.

Есть у меня одно наблюдение - самые сложные и важные переговоры часто лучше назначать на пятницу. Почему? В пятницу люди как будто становятся мягче. Рабочая неделя позади, планы на выходные уже где-то в голове, кофе вкуснее обычного, а категоричность… растворяется. Чаще слышишь «давайте попробуем» вместо «нет, так не пойдёт». И даже если обсуждаешь сложные условия, спорные моменты или цифры в договоре - всё идёт как-то спокойнее. Не знаю, есть ли этому научное объяснение, но в пятницу у людей в среднем выше готовность искать компромисс и договариваться. Наверное, просто потому что впереди два дня, когда можно выдохнуть. Хотя бывали ситуации, когда важные встречи и звонки были в пятницу и после 19:00. Но тут, как говорится, надо смотреть в цель - иногда лучше со всем разобраться до выходных, чем тащить в понедельник тот же вопрос, но уже с потерянным темпом. Так что если на горизонте важный разговор - возможно, лучше дождаться пятницы. Шанс выйти из переговорки с результатом сильно выше. Но все равно, старайтесь такие вещи не назначать на пятницу после 18:00 - там уже не переговоры, а планёрка по выбору пиццы. Поэтому может возникнуть обратный эффект - вроде договорились, а в понедельник все окажутся как в фильме Люди в черном (да такого не было!) Всем хорошего вечера пятницы и выходных!

Я давно тянулся к музыке — играю на гитаре, но петь всегда хотелось отдельно. И при этом был страх: зажимы, неуверенность, ощ
Я давно тянулся к музыке — играю на гитаре, но петь всегда хотелось отдельно. И при этом был страх: зажимы, неуверенность, ощущение, что «это не моё». В итоге решился пойти на вокал. И оказалось, что всё не так плохо, как я себе рисовал. Сначала было вообще непонятно, как можно контролировать голос только дыханием и какими-то микродвижениями. Но постепенно, с каждой репетицией, начинают появляться новые нейронные связи — и вдруг ты уже чувствуешь то, что раньше не ощущал. Очень многое зависит от преподавателя. Мне повезло: спокойно объяснили, как быть, на что обратить внимание, что важно, и путь стал гораздо легче. А ещё я заметил параллель с запуском IT-проекта. В начале — ничего не понятно, слишком много деталей, страшно ошибиться. Но если партнёр опытный, он объяснит, как действовать, на чём сосредоточиться, что критично, а что подождёт. И тогда с каждым днём проект двигается вперёд, а пазл постепенно собирается. Ищите тех, с кем ощущаете с самого начала, что паззл обязательно соберется 😌

Сегодня воскресенье, для большинства день отдыха и расслабления. А я вот хочу поделиться одной мыслью, которая в последнее время меня часто сопровождает. Когда-то у какого-то иностранного блогера (уже и не вспомню, у кого именно) я увидел интересный подход к возрасту. Он воспринимает каждый свой год как версию. Например, 37 лет — это версия 3.7, 38 лет — 3.8. Смысл простой — перестать воспринимать возраст как нечто грустное или ограничивающее, а думать о новой версии как о более продвинутой, улучшенной, переработанной. Как с приложениями: в апдейте всегда есть улучшения, исправления багов, иногда — полное переосмысление функций. Конечно, появляются и новые баги (куда уж без них), но всё же это новый этап — с опытом, с изменениями, с какими-то внутренними апгрейдами. В этом году у меня вышел релиз 4.0. До этого были версии 3.1, 3.2, 3.3… и вот теперь — переход на новую «ветку». Как мы знаем из мира технологий, если релиз большой и заметный, то почти всегда вскоре выходит версия 4.0.1, 4.0.2 — чтобы поправить то, что сразу не предусмотрели. У меня примерно так же: глобальные изменения есть, но в связи с ними, очень много багов еще в работе. Наверное, поэтому мне этот подход так близок. В ИТ-продуктах мы тоже редко делаем что-то «и навсегда». Всегда идёт доработка, улучшение, исправление. Если вам откликается — попробуйте посмотреть на свой возраст так же. Не бойтесь думать о растущем номере версии. Думайте о том, что с каждым годом вы становитесь интереснее, глубже, опытнее. А баги — их мы всегда поправим в следующем апдейте.

Всем привет! Последнее время постов было немного. То проекты сдаём, то новые запускаем. Где-то баги, где-то презентации, где-то срочные звонки вечером в пятницу. Вроде бы ничего необычного - обычная операционка. Но зато ежедневная и довольно плотная. Плюс у большинства проектов NDA. Причём не просто подписали и забыли, а такие настоящие, когда даже намеками сложно делиться. Иногда, если подумать, можно рассказать про подход или решение в отрыве от названия клиента, но времени вычленить это всё не так много. Подумал вот о чём, а интересно ли вам было бы читать про айтишную «бытовуху»? Что-то из закулисья разработки: как люди сдают проекты, какие возникают мелкие (и не очень) ситуации, как выбираются инструменты, где автоматизируем процессы, а где наоборот — возвращаемся к ручной работе? Если интересно - напишите. Может, буду делать такие «бытовые» посты А пока снова иду в Zoom 😩

Сегодня искусственный интеллект стал модным словом. Каждый второй говорит о «революции», «нейросетях», «будущем». Но если приглядеться, то очень многие проекты (сразу уточню - далеко не все, но многие!) заканчиваются одинаково: генерировать симпатичные картинки или собирать примитивных чат-ботов, которые в лучшем случае повторяют заскриптованное «чем могу помочь?» - и даже не пытаются быть чем-то большим, а являются банальной пересылкой запроса в ChatGPT. Мы в DNA Team тоже делаем ИИ проекты. Но для нас это не про красивые слова. Не про волшебные технологии ради презентаций. Мы всегда ищем простое место в бизнесе, где ИИ может быть по-настоящему полезен здесь и сейчас. Такое место, где результат виден не «когда-нибудь», а уже через месяц - в цифрах, времени, деньгах. На первой встрече мы обычно не рассказываем про «тренды» и «видения». Мы показываем, как помогли другим: где именно нашли слабое звено, использовали там ИИ (точнее набор методов и технологий) - и через пару недель люди видели, что их работа стала проще, а бизнес - эффективнее. Никакой магии. Никакой показухи. Просто настоящая работа технологии там, где она действительно нужна. Искусственный интеллект - не про мечты. Он про здравый смысл и результат. И в этом он гораздо красивее любых картинок. Если интересно - напишите, покажем как мы всего за месяц и очень небольшой бюджет внедрили ИИ решения клиентам, и они уже стали эффективнее как в плане трудозатрат, так и расходов.

Как проверить, что ваш подрядчик понимает задачу так же, как и вы Частая история: проект стартует бодро, все улыбаются, «мы всё поняли, приступаем». А через месяц выясняется, что под «сделать чат» клиент имел в виду одно, а команда - совсем другое. И начинается: «так мы же это не обсуждали», «а мы думали, что вы это имели в виду» и так далее. Чтобы таких ситуаций не было - вот 5 простых вещей, которые помогут на старте: ✅ Попросите подрядчика своими словами сформулировать задачу и результат. Даже если вам кажется, что всё очевидно. Иногда формулировка уже выдаёт недопонимание. ✅ Попросите показать этапы работы и критерии готовности. Если они мутные или общие, значит, дальше тоже будет «на глазок». ✅ Попросите примеры «а как вы это делали в других проектах?». Хороший подрядчик сможет хотя бы в общих чертах показать, как он решал похожие задачи. ✅ Зафиксируйте приоритеты. Часто заказчик называет 10 хотелок, но 2 из них критически важны, а 8 только «если успеем». Лучше сразу это проговорить. ✅ И наконец - договоритесь, как будете вносить изменения. Потому что в любом проекте они будут. И важно заранее обсудить, как считать время и бюджет на доработки. Всё это совсем не про «бюрократию». Это про то, чтобы потом не тратить силы на споры и переделки. Лучше 2 часа на старте на уточнения, чем 2 недели на «это не то, что мы хотели».

Когда ИТ-продукт работает не только в будни Есть такая категория проектов — когда ИТ-продукт не просто «запустился и живет», а поддерживает реальное оффлайн-мероприятие. И вот тут особенно важна не только сама разработка, но и готовность команды быть вовлечённой и на связи не по графику, а когда это действительно нужно — в выходные, вечерами, в «боевом режиме». Мы делали один из таких проектов для Недели московской моды (BRIKS Fashion Summit). Разрабатывали сайт и приложение для сбора заявок на участие. Казалось бы — функционал понятный: регистрация, анкеты, проверка данных. Но весь проект был завязан на конкретные даты и живую работу с людьми. На момент старта мероприятий было очевидно — любые сбои или даже небольшие ошибки могут сорвать процесс. И да, проблемы, конечно, возникли (а куда уж без них), но мы быстро их находили и оперативно устраняли прямо на месте. Технический менеджер от нас был на площадке лично, держал связь между клиентом и командой и помогал решать все вопросы «в бою». 📌 Вот почему в таких проектах важно: • заранее продумывать, кто из команды будет на связи и где • учитывать, что у мероприятия нет «переноса на завтра» • помнить, что поддержка — это не только про код, но и про ответственность • проговорить с клиентом (а клиенту - с подрядчиком), что такая помощь в принципе нужна, это далеко не очевидно, и должно быть учтено в процессах и договоре Такие истории хорошо показывают: быть настоящим партнёром — значит быть готовым вовремя подхватить, когда что-то идёт не по плану. А еще понимать истинные задачи того, что ты делаешь.

Что такое ИТ-менторство и кому оно нужно? ИТ-менторство — это формат, когда вы привлекаете опытного технологического эксперта, чтобы: • понять, что именно нужно разрабатывать • понять, какими ресурсами создать тот продукт, который вы хотите получить (собственная команда, аутсорс, фриланс) • оценить реальные бюджеты и сроки • избежать лишних трат и ошибок • правильно выстроить работу команды или подрядчика Но тут есть один важный нюанс: 👉 настоящий эффект будет, если ментор сам предприниматель, у которого есть действующий бизнес, реальный опыт разработки, запуска, провалов и успехов. А не просто «технарь-теоретик». Кому это нужно: 🔹 У вас есть идея, но не понимаете, с чего начать и сколько это может стоить 🔹 Проект уже идёт, но нет уверенности — как построить дальше, где риски 🔹 Хотите защититься от внезапных и необоснованных трат 🔹 Готовитесь к запуску и хотите всё продумать: фичи, архитектуру, бюджеты 🔹 Планируете привлекать инвестиции — и нужно грамотно обосновать трату средств Какая польза: • Экономия 200 000 – 1 000 000 ₽ на старте (по опыту) • Чёткая поэтапная стратегия запуска продукта • Решения не в отрыве от бизнеса — а с учётом реального опыта и продуктовой насмотренности. Если актуально — напишите. Первая встреча — без каких-либо коммерческих обязательств.

Сегодня рассказывал про наш проект LookLink - сервис для качественного нетворкинга. Это первые публичные питчи проекта и по о
Сегодня рассказывал про наш проект LookLink - сервис для качественного нетворкинга. Это первые публичные питчи проекта и по окончанию сразу понимаешь, о чем не сказал, а где надо было использовать другой термин. В любом случае - очень здорово! Спасибо FranchCamp и Косте Урванцеву за приглашение) PS. Это был не стендап, а стартап)))

Одна из самых частых ошибок при запуске IT-продукта - пытаться охватить всё и сразу. Очень знакомая сцена: клиент приходит и говорит “Мы хотим и авторизацию, и каталог, и аналитику, и чат, и реферальную систему, и веб, и мобайл, и чтобы красиво. И чтоб всё на старте”. Понимаю это желание. Особенно когда проект важный, амбициозный. Кажется, лучше сразу сделать максимум, чтобы не доделывать потом. Но правда в том, что такой подход - это прямой путь к выгоранию команды, просадке бюджета и… очень часто к тому, что продукт просто не выходит. Запуск “всё и сразу” нерабочая стратегия. Потому что: • пока делаете всё, рынок уже уехал • гипотезы не проверены • деньги уходят не туда • фичи могут вообще не пригодиться • отношения с подрядчиками рушатся И наоборот: запуск с минимальным, но сфокусированным набором функций позволяет протестировать идею, собрать обратную связь и только потом наращивать функционал. В моей практике были проекты, которые мы запускали с очень базовым функционалом, и они отлично отработали. А были и те, где клиент полтора года откладывал релиз, потому что “надо ещё кое-что добавить”. В итоге не добавилось и не запустилось. Есть и очень известный всему миру пример: Dropbox. В самом начале у них даже не было работающего продукта. Была просто видеозапись, где демонстрировался пользовательский сценарий - как будто бы всё уже работает. Это был MVP не продукта, а идеи. Видео разошлось по сообществам, люди выстраивались в лист ожидания, и только потом началась полноценная разработка. Так компания поняла, что делает не “ещё один облачный сервис”, а то, чего действительно не хватало пользователям. В наши времена конечно такого уже мало, но есть другие способы сделать меньше, чтобы понять, чтл не надо делать больше :) Так что если на старте вы выбираете между “сделать всё красиво” и “выпустить самое главное”- я всегда голосую за второе. Быстрее выведем, раньше поймём, проще улучшить.

У нас тут вакансия. Если это вы или вы знаете таких людей - пишите. Берем официально в штат.
У нас тут вакансия. Если это вы или вы знаете таких людей - пишите. Берем официально в штат.

Объявляется рубрика - полезная среда! Постараюсь в эти дни давать какие-то практически-полезные моменты, которые вы можете просто взять и использовать, проверить себя. Вы планируете запускать проект с IT-подрядчиком? Есть несколько простых шагов, которые стоит сделать до старта, чтобы потом не было мучительно дорого, долго и непредсказуемо. По опыту в студии я видел, как одни проекты взлетают с первых дней - а другие буксуют ещё на старте, потому что к запуску не были готовы. Что важно сделать до начала работ: ✅ Понять, какую проблему должен решать продукт - и для кого ✅ Сформулировать ключевые сценарии - хотя бы в виде текста ✅ Определиться, кто будет принимать решения и утверждать работу ✅ Прописать, какие есть ограничения - сроки, бюджет, технологии ✅ Понять, кто будет вовлечён со вашей стороны (заказчика) ✅ Продумать, как проверять гипотезы и метрики успеха ✅ И главное - быть готовыми к диалогу, изменениям и уточнениям по ходу работы Это не про «идеальное ТЗ» - его почти никогда нет. Но когда есть базовая проработка, команда быстрее вникает, принимает более точные решения и экономит ваши же ресурсы. И ещё - важно заранее обсудить, как будете взаимодействовать: как часто созвоны, где обсуждать задачи, как принимать итоги спринта. Такие мелочи - это как шестерёнки, которые либо крутятся вместе, либо начинают скрипеть уже через неделю. И создается ощущение, что проект начался, и с первых дней что-то пошло не так. Лучше такого избегать)

Всем привет! Сейчас появилось чуть больше времени, чем обычно, поэтому - небольшой анонс. Я открыт к менторству - особенно для тех, кто только на старте в ИТ-проектах. Если вы давно носите в голове идею IT-продукта, но не знаете, с чего начать? Страшно тратить деньги, непонятно, кому довериться и как не наломать дров? Да и вообще, сколько все может стоить, надо ли идти к фрилансерам, или нанимать студию. Или вообще кодить не надо, соберете все самостоятельно. А может у вас уже традиционный бизнес, но хочется внедрить ИТ-решения, чтобы сэкономить, улучшить процессы и т.и. Я здесь, чтобы помочь - как технологический и бизнес ментор. Без лишнего пафоса, но с глубоким опытом. Коротко обо мне: • ex-CTO Yota Devices (создавали и запускали на рынок тот самый YotaPhone: телефон с двумя экранами и все сервисы на нем). • Со-основатель и CEO студии заказной разработки DNA Team: мы уже 10 лет на рынке, проекты для ВТБ, Касперского, Авиасейлз, Эрмитажа и т.п. • Со-основатель CoActivity - платформа для создания и проведения бизнес-квестов, победитель акселераторов. • Со-основатель LookLink - AI-сервис для качественного нетворкинга и решения бизнес-запросов. • Сертифицированный ментор и бизнес-трекер (CCE ICF). • Много пройдено - и успешного, и ошибочного. Второе, кстати, иногда даже полезнее. Чем помогу: • Разложим идею на понятные шаги • Подскажу, с чего стартовать и как не потратить лишнего • Обсудим форматы MVP, бюджеты, команду, архитектуру • И просто посоветуем - честно, без воды Более подробное описание опыта и имеющейся экспертизы здесь. Первая встреча - без каких-либо коммерческих обязательств, просто чтобы вы поняли: “да, это мой вектор”. Пишите в личку (тг в профиле канала) или отвечайте на этот пост, если на старте - или просто хотите услышать мнение. Иногда одного разговора достаточно, чтобы начать.