Обновить
111.3

Развитие стартапа

Главное не размер стартапа, а умение его развивать

Сначала показывать
Порог рейтинга

Портфель продуктов⁠⁠

Я всё больше прихожу к мысли, что моя стратегия - это не «ставка на одного единорога», а портфель продуктов.
Я постоянно запускаю новые проекты. Да, не все они находят рынок. Но зато всегда есть шанс, что один или два "выстрелят".

Почему не один?
Потому что меня не драйвит идея "сидеть на одном продукте до посинения". Мне нравится запускать, проверять гипотезы на реальном спросе, а не тратить месяцы на интервью и бесконечные обсуждения проблем пользователей. Минимальный прототип -> рынок -> обратная связь. И вперёд.

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

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

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

И знаете что? Пока мне нравится сам процесс. Запускать, смотреть реакцию, делать выводы и идти дальше. Это даёт мне больше мотивации, чем идея "строить идеальный продукт годами" (это уже проходили).

Кстати, я регулярно пишу о своих продуктах, экспериментах и запусках в телеграме 👉 https://t.me/debug_leg

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

LLM умрут, а бизнесы на API рухнут⁠⁠

35 лет подряд Янн Лекун угадывает повороты в ИИ.
В 80-х он говорил про распознавание изображений, в нулевых - про нейросети, в 2016 - про самообучение.
И вот сейчас он заявляет самое радикальное: LLM в том виде, в каком мы их знаем, мертвы.

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

А теперь подумай, сколько сейчас продуктов держится только на API OpenAI.
Чат-боты, резюмирование документов, генерация текстов.
Все эти проекты живут лишь потому, что можно позвать API.

Но новая волна придёт не от «больше параметров», а от моделей, которые учатся «как дети»: через видео, восприятие и понимание мира.
И тогда поддерживать бизнес на API старых LLM станет бессмысленно. Новые модели будут быстрее, точнее и дешевле.

Лекун прямо говорит: закрытые модели исчезнут, открытые и распределённые — победят. Meta уже вкладывает $20 млрд в перестройку стратегии. Сроки короткие: 3-5 лет до первых моделей мира, и около десятилетия до ИИ уровня человека.

Для корпораций это вызов. А для indie-hacker’ов - шанс.
У больших игроков всё завязано на старых API и инерции.
А у нас есть свобода пробовать новое. Пет-проекты — это маленькие лаборатории, где можно тестировать идеи будущего и учиться жить «после LLM».

Когда рынок перетрясёт, выиграют те, кто уже умеет мыслить продуктом, а не строками API.

Я как раз пишу о своих экспериментах в инди-хакинге и пет-проектах у себя в телеге 👉 https://t.me/debug_leg

Теги:
Рейтинг0
Комментарии2

Про курьера, швейную машинку и почти полтора ярда

Я люблю читать и писать про всякие разные крутые менеджерские находки, креативные решения и к чему они приводят. На глаза попался интересный кейс парня, который в 19 лет стартовал свою компанию, а потом стал чуть ли не самым молодым миллиардером. Кейс известный и в нем видны совершенно простые, но оч крутые бизнес решения. Но по порядку.

Это вообще не «очередной IT стартап, который опять стрельнул не пойми откуда и, возможно, туда же и пропадет». Хотя было бы вполне логично и в духе времени.

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

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

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

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

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

Поэтому он сделал очевидный, но очень умный ход конем: начал рассылать свою продукцию своим же кумирам с личными письмами, где рассказывал про то, как тот или иной блоггер его вдохновил/помог и предложением посмотреть, что они там нашили. Ну то есть одно размещение ему стоило баксов 30 (продукт плюс отправка) при гигантской теплой аудитории. 

Так как спорт комьюнити очень вменяемое и дружное, инфлуэнсеры с удовольствием рассказали о полученном продукте и своем опыте. А то, что писал им персонализированные сообщения - добавили желания рассказать про его проект.

Но самый фурор был, когда GymShark принял участие в выставке BodyPower в 2013 году. Сам предприниматель до конца не верил, что из этого что-то получится. Но сразу после открытия их стенд взяли штурмом атлеты, блоггеры, представители залов. Не удивительно: все об этом слышали от чуваков, на которых ты не просто подписан, а кому доверяешь. Ну и дальше понеслась… были победы и поражения, но по итогу на сегодняшней день компания GymShark оценивается в 1.3 млрд. Долл и конкурирует с такими гигантами, как Nike и адик….

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

Часто предприниматели вместо того, чтобы юзать простые и понятные инструменты оптимизаций, улучшений и т.д за бешеные деньги покупают советы и решения, которые, как и они, использует весь рынок. А как можно выиграть у кого-то, если бежишь с ними с одной скоростью? 

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

Если понравилась статья - буду рад вам на канале

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Стабильная нестабильность

В последнее время я всё больше думаю об инди-хакинге и пассивном доходе от своих поделок. Мне нравится идея быть IT-предпринимателем. Но у меня семья, кредиты, ипотека и обязательства. Зарплата лида в найме это всё покрывает, ещё остаётся на «приколюхи» и путешествия. У найма есть большой плюс — деньги падают на карту два раза в месяц.

И всё же сегодня утром я проснулся с мыслью: мне уже 32 года. А разработчиков и тимлидов старше 40 я встречал всего пару раз. Всё чаще в IT-каналах пишут про сокращения и то, что нас заменит ИИ. Вчера я засыпал с уверенностью, что могу найти работу за неделю и ещё поторговаться за оффер. Сегодня проснулся и впервые усомнился в этом.

Почему?

Во-первых, возраст. Эйджизм в IT никуда не делся. Я сам сталкивался с ним ещё на старте, когда на собесах искали «горящих 18-летних джунов». А потом уже в роли интервьюера видел, как кандидаты за 50 спокойно проходили технический этап, но дальше их не брали.

Во-вторых, конкуренция. У лида зарплата ниже, чем у техдира, у мидла ниже, чем у лида. Но компаниям нужно много мидлов и чуть-чуть сеньоров. А вот техдиров и тимлидов нужно по пальцам пересчитать. Никто не строит «армию лидов».

И вот так постепенно вырисовывается карьерная ловушка: потребности растут, конкуренция за позиции, которые эти потребности покрывают, усиливается, а сверху давит возраст.

Пишу этот пост, чтобы пригласить к обсуждению. Интересно услышать мнения — как вы смотрите на это?

P.S. Я ещё веду канал в телеге, где рассказываю о своих инди-поделках.

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии7

На сайте Сколково вышла история о том, как мы перестраиваем культуру от проектной к продуктовой.
Главный инсайт — технологии сами по себе мало чего стоят. Важно проверять спрос, быстро тестировать идеи и выводить на рынок только то, что реально нужно клиентам.
В итоге мы выстроили систему R&D, научились работать с гипотезами и запустили собственные продукты. Это не только про рост бизнеса, но и про смену культуры внутри команды.

Каждая идея проходит определённые этапы: исследования, прототипирование, планирование продукта и реализация MVP. Идеи "отваливаются" на каждом этапе и это позволяет сделать процесс более дешевым и не "тащить" за собой идеи, которые в последствии не примет рынок.
Таким образом, повышается вероятность продукта на рынке.
На картинке ниже схематично представлена воронка идеи от этапа к этапу. Из 100 идей до вывода на рынок доходят примерно 7, это среднее значение по акселераторам крупных компаний.

Ссылка на публикацию: https://lnkd.in/ez3Qx26y

Теги:
Рейтинг0
Комментарии0

ImageSorcery 05 - автотесты; просто покажи ему пример

Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.

ImageSorcery 01 - Как я свой open source вайбкодил
ImageSorcery 02 - Превращение ImageWizard в ImageSorcery
ImageSorcery 03 - шаг за шагом: PoC, Initial commit
ImageSorcery 04 - README.MD

В прошлой серии мы поговорили про важность README для вайбкодинга. В этой не менее важная тема - автотесты. 

Не поленюсь ещё раз всем напомнить что я джун в python, а это значит что даже с самым качественным README я не могу на 100% утверждать что понимаю как работает проект написанный целиком ИИ. Из-за чего я не могу полностью доверять ИИ, когда он его меняет. Это приводит нас к выводу о необходимости автотестов. Не только как к способу повысить качество, надёжность и прочие пафосные метрики. А как к единственно возможному способу реализовать, а в дальнейшем развивать проект через вайбкодинг.

Вперёд вайбкодить автотесты!

Сказано - сделано. Cline + Gemini flash:

“Прочитай @README.MD для понимания проекта. Напиши автотест, который будут проверять наш единственный hello world tool.”

Тест на pytest готов ваншотом. Он passed 🎉! Казалось бы, пора открывать шампанское. Но как говорится: доверяй, но проверяй. На проверку это оказался юнит тест. Он конечно технически проверяет что функция написания в файле hello_world.py работает. Но он не проверяет, объявляет ли такой tool мой MCP сервер, возможно ли вызвать этот tool, вернёт ли он значение в ожидаемом MCP клиентом формате. 

Я совершил классическую для вайбкодера ошибку - поставил задачу не достаточно чётко.

Ок, откатываем все изменения (благо я с самого начала завёл git - обязательную вещь для вайбкодинга и обычной разработки) и промптим заново: 

“Прочитай @README.MD для понимания проекта. Напиши e2e автотест, который будут проверять наш единственный hello world tool подключаясь к этому MCP серверу как MCP клиент

Я знал что ImageSorcery в своём зачаточном виде работает через stdio - стандартный протокол для MCP серверов работающих локально. Это значит что его можно запустить как подпроцесс и, отправив в него нужные данные, получить ответ.

Правда это не звучит как простая типовая задача? Вот и я так подумал. Вот и Gemini Flash так подумал. И облажался. И Pro облажался. И o3-mini. И Sonnet.

Ну мне не привыкать к тому как ИИ лажают. Взял дело в свои руки. И тоже облажался 🤦. Целый день я потратил в тщетных попытках отправить по stdio хоть что-то и получить хоть какой-то ответ. А разгадка одна - безблагодатность нужно звать батю. Благо такой батя в виде коллеги python senior software developer у меня имелся. Я пришёл к нему в слезах со словами что в попытках покрыть автотестами MCP сервер работающий по stdio что только не испробовал и на этом мои полномочия всё, закончились. Он, взглянув одним глазом на проект и ситуацию в целом сказал: “Просто покажи своей ИИшке пример MCP сервера покрытого автотестами. Таких что ли нет на GitHub? У нас в python фиг найдёшь задачу, которую до тебя ещё не решили и не обернули в удобную либу.”

Просто возьми пример с Github - И покажи его ИИ
Просто возьми пример с Github - И покажи его ИИ

А официальная документация тем временем имела ссылку на GitHub с официальными примерами. А в этих примерах используется либа FastMCP. Я скормил пример Cline - отличный результат ваншотом. Попросил переписать всю реализацию на FastMCP - так же ваншот, и тесты не упали. Попросил актуализировать в связи изменениями README. git commit.

Этот шаг готов ✅

Я уже точно не помню, но где-то в процессе (до или после тестов) добавил ещё и линтер ruff. Но это было так просто что я даже не запомнил где и как это случилось. Линтер нужен, чтобы держать код в едином стиле. Полезно для вайбкодинга и в целом.

Теперь я готов приступать к реализации MVP.

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

Но это уже в следующий серии.

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии0

Я писал комментарий к статье про неудавшийся стартап и случайно написал пост :)

Так случилось, что я запустил с 10-к своих стартапов, в перерывах между работами.

Или другими словами - у меня есть свое небольшое кладбище стартапов..

И вот что я понял для себя, может кому пригодится:

1. MVP + кастдев(+Сначала спроси маму) может помочь, но не гарантирует успеха, и не гарантирует верную экспертизу, и не гарантирует верных выводов по итогу, все равно все остается субъективным. (Эти инструменты и курсы по ним что-то вроде, техник и инструментов что впаривают вайтишникам на курсах, т.е. инструменты для заработка на инструментах в первую очередь, ну и вера в них еще дает личное успокоение, хотя риски остаются рисками :))

2. Делая для себя - ты делаешь для других, делая для других - ты делаешь для себя, и не важно чью проблему ты решаешь.

3. В продажах решает не продукт или его фичи и качество. В продажах решают продажи. Вот и все. Ты можешь продать любой продукт если будешь заниматься его продажей. И ты не продашь даже самый лучший продукт, если не будешь заниматься его продажами.

4. Есть момент удачи, завируситься, попасть в нужное время, в нужное место. Для этого подобно продажам, нужно заниматься "удачным попаданием". И верить в то что это возможно. И что сейчас тоже на самом деле удача.

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

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

7. Мое счастье не зависит от успешности стартапа, работы и кол-ва денег.

А скольким стартапам дали жизнь и похоронили вы и какой опыт из этого всего извлекли? :)

Теги:
Всего голосов 5: ↑5 и ↓0+8
Комментарии2

ImageSorcery 01 - Как я свой open source вайбкодил
ImageSorcery 02 - Превращение ImageWizard в ImageSorcery
ImageSorcery 03 - шаг за шагом: PoC, Initial commit
ImageSorcery 04 - README.MD

Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.

В прошлой серии был готов PoC в виде набора python скриптов для определения объектов на изображении и обрезки изображения по координатам этих объектов. А так же initial commit репозитория с hello world MCP.

Как я уже говорил, я предпочитаю двигаться небольшими шагами - так проще и ИИ реализовать изменения и человеку их понять. А так же я говорил, что в python я джун и с пониманием проекта мне нужна была помощь. Поэтому следующим шагом я попросил Cline тщательно заполнить README.MD в котором подробно описать проект. Это описание понадобится в будущем не только мне, но и самому Cline  для реализации задач. 

Первая версия README
Первая версия README

Всем разработчикам, а особенно вайбкодерам настоятельно рекомендую держать README.MD актуальным и подробным, так как он позволяет легко вгрузиться в контекст и понять что где лежит, как делать типичные изменения, каким правилам следовать и т.п.

Многие инструменты имеют собственные аналогичные решения Rules у Cursor, CLAUDE.MD у Claude-code, GEMINI.MD у gemini-cli и т.п. Но я рекомендую использовать старый добрый README.MD или CONTRIBUTING.MD так как 

  1. Это уже давно зарекомендовавший себя метод устоявшийся в нашей индустрии

  2. К README.MD особое отношение у git-хостингов и прочих инструментов

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

Учитывая что ИИ инструменты платные и я изначально планировал делать этот проект open source, последний пункт для меня ключевой. Сейчас у меня во всех gemini.md, README.MD и т.п. просто одно правило "At the beggining of any task read README.MD"

Конечно ваншотом этот шаг не получился, так как я изначально не знал что именно мне нужно в README.MD видеть. Но как только в нём стало достаточно информации о проекте чтобы даже мне джуну он стал абсолютно понятен - и этот шаг был сделан. git commit.

А дальше я его постоянно дополнял, обновлял и развивал. Сейчас https://github.com/sunriseapps/imagesorcery-mcp/blob/master/README.md - самый проработанный README.MD из тех которые я когда-либо писал. Теперь это не просто инструмент получения контекста для разработчика или ИИ-агента, но и лицо проекта для всего интернета.

Со временем, когда проект разросся, от главного README.MD отпочковалось ещё несколько аналогичных документов.

Их количество множится по мере развития проекта. Сейчас я подумываю о разделении их на README.MD и CONTRIBUTING.MD. Но пока что это просто мысли. Буду рад если в комментариях поделитесь своими на этот счёт.

Теги:
Рейтинг0
Комментарии0

Одноразовый код⁠⁠

LLM-модели подарили нам новый тренд в инди-хакинге. В соцсетях пишут, что «ИИ заменит программистов», а разработчики разбирают код от нейросетей и почти всегда приходят к выводу: поддерживать это будет очень больно.

Я сам пишу на Kotlin и считаю его лучшим языком для продакшн-разработки. Но для vibe-кодинга он подходит слабо: слишком мало данных, и модели плохо справляются с нетиповыми задачами. Поэтому почти все мои сайд-проекты сегодня живут на JS и Python.

Ещё недавно для меня это было пыткой. Я привык к статической типизации, и писать на языках с рантайм-проверками казалось болью. Но с появлением GPT всё изменилось. За меня код пишет нейроджун, а я больше внимания уделяю структуре базы, архитектуре и взаимодействию компонентов. В духе «чтобы под транзакцией не ходить по HTTP» и тому подобное.

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

У такого подхода есть минусы. Всё держится на тестах: контрактные тесты, сценарные тесты, чёткие спецификации взаимодействий. Без них это превращается в хаос. Поэтому главный совет для vibe-кодеров звучит так: сначала пишем тесты, а потом генерим код нейросетью.

Я пробую этот подход на своих пет-проектах и делюсь результатами в телеграме 👉
https://t.me/debug_leg

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Опубликованы результаты конкурса «Студенческий стартап» (Очередь VI) от Фонда содействия инновациям

В этом году на конкурс поступило 11 600 заявок: их подали 345 университетов из 81 субъекта РФ и 31 страны. В результате отобрали 2500 лучших проектов, среди которых 68 стартапов — из Физтеха. 

🎓🎓🎓 Отдельно хотим отметить и поздравить наших студентов и выпускников онлайн-магистратур Центра «Пуск» — ребята со своими стартапами выиграли 12 грантов:

  1. Аликин Александр — разработка интеллектуального ассистента-администратора для бизнеса.

  2. Вагапов Глеб — создание приложения на основе ИИ-ассистента для помощи парам в укреплении отношений.

  3. Жамалов Булат — создание онлайн-платформы для проведения чемпионатов по этичному хакингу с системой автоматического генерирования заданий и базой знаний.

  4. Зайцев Дмитрий — система принятия врачебного стоматологического решения с помощью взаимодействия с пользователем AI DENTIST.

  5. Зимаков Максим — создание веб-приложения для распознавания жестов рук «Сигнум».

  6. Истратова Лариса — создание AI–сервиса диагностики радикулярных кист челюстей с применением ИИ на основе рентгенологического метода ортопантомографии.

  7. Котельников Андрей — создание корпоративной ИИ-платформы (локальный клиент-сервер) для генерации кода по бизнес-требованиям и автоматизации программной разработки AI Junior developer.

  8. Лаврухина Виктория — создание платформы для автоматизации процессов в центрах обслуживания сельскохозяйственной техники «Интеллектуальный инженер».

  9. Озерецкая Любовь — платформа для патоморфологической диагностики Cancer Detection.

  10. Осипов Алексей — стартап MemoryCare.

  11. Савельева Анастасия — создание программного обеспечения для автоматизированного анализа данных кардиотокографии (КТГ) плода и прогнозирования гипоксии плода с использованием методов ML/DL.

  12. Юшаков Дмитрий — финансовый ИИ-ассистент для поиска арбитражных и хороших сделок на российском фондовом рынке.

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

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

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

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Кого нанимать в стартап?

Команда стартапа отличается от команды любого другого бизнеса. Для проекта, который должен “выстрелить” в короткие сроки, людей подбирают не только по их опыту и компетенциям, но и по личностным качествам.

На что обращать внимание:

Высокая адаптивность и умение работать на скорости.   Для стартапа важно не получать сразу идеальный результат, а быстро внедрять новые фичи, делать одну итерацию за другой. Гораздо правильнее сделать 3 попытки внедрения новой функции за неделю, чем “выдать” идеальную за месяц.
Умение адаптироваться к меняющимся условиям позволит сотрудникам легче относиться к переменам и меньше выгорать.

Кросс-функциональность. Да, сотрудник стартапа - “многорукий многоног”, иначе не назовешь! Ваши сотрудники должны уметь закрывать множество компетенций, но самое главное - им должно это нравиться. Сотрудники, которые не любят (не могут) делать сверхзадачи или живут по принципу “это не мои обязанности” в стартапах не приживаются. Есть прекрасное сравнение: в зрелом устойчивом бизнесе сотрудники напоминают гирлянду - цепь из одинаковых лампочек, каждую из которых можно легко заменить. А вот в стартапе каждый - это яркая звезда, которую очень болезненно потерять.

Высокая мотивация. Сотрудник стартапа в идеале должен сам “гореть” идеей проекта. Это будет существенно влиять на результативность труда и атмосферу в команде.

Задавайте “правильные” вопросы на собеседовании и ориентируйтесь больше на soft-skills: в стартапе это самое ценное! 

Теги:
Рейтинг0
Комментарии0

Что будет с человеком, если его перегрузить задачами до предела? Ну конечно - он выгорит.

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

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

  2. Падение качества. Это влияет на количество инцидентов и тогда риски возрастают кратно. Восстановление, репутация, штрафы. Например, утечка персональных данных будет стоить до 15 млн только штрафа. А ошибки в мед- или авиаоборудовании могут стоить кому-то жизни.

  3. Текучка. Если сотрудник выгорел, то время до его заявления на вашем столе уже пошло. И его не отговорить, он уже нашел интересную замену. А найм и адаптация нового сотрудника дорого. И есть угроза цепной реакции в коллективе.

  4. Потеря экспертизы. Каждый сотрудник уже встроен в систему, знает все процессы, технологии, несет какие-то уникальные знания о своих задачах. Нельзя выдернуть одного и вставить другого как деталь. Свой опыт ушедший заберет с собой. Иногда такие потери могут быть весьма значимыми.

На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.

Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.

Со стороны сотрудника:

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

Со стороны бизнеса:

Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.

Берегите себя, и своих сотрудников, коллеги!

И расскажите как у вас с этим?

Теги:
Рейтинг0
Комментарии2

ImageSorcery 01 - Как я свой open source вайбкодил
ImageSorcery 02 - Превращение ImageWizard в ImageSorcery
ImageSorcery 03 - шаг за шагом: PoC, Initial commit

Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.

В прошлый серии мы с Gemini 2.0 flash определили стек: python, OpenCV, Ultralytics и никакого ImageMagic. 

Начал я как обычно с малого. В Cline попросил своего любимого бесплатного друга Gemini накидать скрипт на python который получает данные о размере (ширина, высота в пикселях) изображения. Дальше больше - скрипт crop который обрезает изображение по указанным аргументам. С последним пришлось повозиться и даже переключиться на Pro версию, благо она тоже бесплатная, пусть и с жёсткими лимитами.

😎 one shot изи катка: detect_objects находит координаты объектов, а crop_objects их вырезает
😎 one shot изи катка: detect_objects находит координаты объектов, а crop_objects их вырезает

PoC готов, можно приступать к реализации MVP.

Как вы помните, в python я тот ещё джун. Так что я не стал рисковать своим любимым бесплатным Gemini flash и даже pro, а сразу переключился в бесплатный браузерный Claude (лучший ии-кодер что тогда, что сейчас) и попросил дать мне подробнейшую инструкцию по разворачиванию проекта который будет имплементировать простейший hello world MCP сервер.

Нет смысла ваншотить такой проект за раз даже с Claude Opus 4.1. Что он не вывезет, что я не осилю осознать все нюансы за один заход. По этому предпочитаю действовать по комплиментарным шагам, на каждом из которых получать работающий продукт с небольшими изменениями, пока не получу финальный результат.

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

И так инструкция готова, закидываю её в Cline + Gemini flash и ... получаю ошибку активации. Вы же помните что в python я джун и понятия о venv не имею? Даю ему шанс исправить ошибку самостоятельно, но бесполезно - он не справляется. Откатываю всё назад, переключаю модель на Gemini Pro - результат тот же. Плюю на экономию, переключаю модель на Claude Sonnet - результат тот же, но оно сожрало 3 бакса 🤬

Плюю на этих бестолковых ИИ и беру дело в свои руки. Рано железякам нас ещё заменять!

Пол дня бесполезного рыскания по stack overflow и дебага, во время которого я случайно обнаружил, что venv активируется если git bash terminal открыт в отдельном окне, а не внутри VSCode. Оказывается эта шарманка будучи запущенной внутри IDE в пути C:\Users\titulus\work сочетание \t воспринимает как знак табуляции из-за чего пытается активировать venv в C:\Users    itulus\work 😵‍💫

Очевидного решения или даже упоминания этого бага я не обнаружил, так что просто уехал со всем своим проектом в WSL, благо VSCode отлично с ним работает. В Linux окружении, разумеется, таких проблем не возникло. Cline Gemini flash ваншотом по той самой инструкции от Claude создал MCP сервер, самостоятельно к нему подключился (вот за это я его обожаю) и проверил.

Я завёл git репозиторий и закоммитил initial commit. Первый шаг сделан ✅

Теги:
Рейтинг0
Комментарии0

Ближайшие события

A-Player⁠⁠

Термин A-Player сначала звучит как что-то из спорта, но в IT под этим обычно понимают людей, которые тащат команду на новый уровень. И это не всегда «сеньор с 10 годами опыта». Иногда это может быть джун, который смотрит на работу шире, чем просто строчки кода.

A-Player отличается не количеством выданного кода, а подходом. Он думает о продукте, а не о том, чтобы накрутить ещё один сервис ради красоты архитектуры. Он делает жизнь коллег проще, поднимает планку в команде и берёт на себя задачи так, что другим не нужно держать их в голове. С ним процессы двигаются быстрее, а продукт становится лучше. 🚀

Я понял это на собственном опыте, когда начал активно запускать пет-проекты. Там ты одновременно разработчик, продукт, дизайнер, саппорт и менеджер. Ты не можешь спрятаться за «моя часть готова, дальше не моя проблема». Ты видишь весь цикл: от идеи до первых пользователей. И именно это формирует продуктовое мышление, которое отличает A-Player от «просто хорошего кодера».

В стартапах и небольших командах такие люди решают исход проекта. Один A-Player может дать ценности больше, чем пять «средних». Не потому что он пишет в пять раз больше строк, а потому что думает в пять раз шире. Он видит проблемы раньше, берёт на себя ответственность и фокусируется на том, что действительно двигает продукт вперёд.

По сути, каждый пет-проект — это маленький тренажёр 🏋️ для прокачки этих навыков. Ты учишься брать ответственность целиком, думать о ценности для пользователя и экономить время — своё и потенциальной команды. В карьере это очень заметно: такие навыки ценят куда выше, чем знание конкретного фреймворка.

Хочешь стать ближе к A-Player? Начни с простого вопроса: то, что ты делаешь сегодня, делает ли продукт лучше и жизнь коллег проще? Если да — значит, ты на правильном пути.

Я пишу о своём пути в indie-hacking и пет-проектах в телеграме. Если интересно наблюдать за процессом изнутри - https://t.me/debug_leg  ✨

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии0

ImageSorcery 01 - Как я свой open source вайбкодил
ImageSorcery 02 - Превращение ImageWizard в ImageSorcery

Это серия постов от идеи ImageSorcery до 100+ звёзд на гитхабе и 100+ ежедневных установок с PyPI.

В прошлый раз мы выяснили, что при правильной настройке бесплатных инструментов, бесплатная LLM Gemini может оказаться не хуже Claude в написании документации. И закончили на вопросе, почему никто раньше не привязал MCP к ImageMagic?

А вот почему

Первым делом после звонка с Системным Аналитиком я дал Cline в своём VSCode право на запуск команд в терминале. Затем взял первый попавшийся скриншот мобильного приложения и попросил вырезать NavBar используя ImageMagic. Gemini flash вырезал какую-то случайную часть экрана.

crop "на глаз"
crop "на глаз"

Я переключился на Gemini pro - результат тот же. o3 от OpenAI и Sonnet от Anthropic также облажались.

Долго думал. Я знал что все эти модели мультимодальные и наверняка знают что такое NavBar. Тут явно что-то не сходилось. Я полез раскрывать свёрнутые секции их размышлений и обнаружил что: 

  1. Все они понимают, что изображено и “видят” NavBar. 

  2. Никто из них не способен вычислить точные координаты этого NavBar.

  3. Они даже размеров изображения не знают. 

Из-за чего все они действовали наугад.

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

В этом и крылся ответ на вопрос “а чего раньше это никто не сделал?”. 

С этой дилеммой я пошёл к Gemini. Сокращённая переписка:

👤: какой аналог npmjs.com для питона?
🤖: PyPi

👤: у него сайт есть?
🤖: pypi.org

👤: порекомендуй мне 5 - 10 пакетов для распознавания изображений на python моя задача - определять координаты объектов для будущего crop
ИИ: Pillow, OpenCV, scikit-image, TensorFlow Object Detection API, Detectron2, YOLO, Tesseract OCR, SimpleCV, imutils. Рекомендации:
1) Начните с OpenCV или scikit-image.
2) Если вам нужна более высокая точность или нужно распознавать определенные типы объектов, рассмотрите TensorFlow Object Detection API, Detectron2 или YOLO.
3) Используйте Pillow для загрузки, сохранения и предварительной обработки изображений.
4) Используйте imutils для упрощения работы с OpenCV.
5) Если вам нужно распознавать текст, используйте Tesseract OCR.

👤: расскажи подробней про opencv imutils pytorch и yolo
🤖:
- OpenCV - это фундаментальная библиотека для компьютерного зрения, предоставляющая широкий спектр алгоритмов для обработки изображений и обнаружения объектов.
- imutils - это набор удобных функций, которые упрощают работу с OpenCV.
- PyTorch - это мощный фреймворк машинного обучения, который можно использовать для построения и обучения сложных моделей обнаружения объектов.
- YOLO - это семейство алгоритмов обнаружения объектов в реальном времени, известных своей скоростью и точностью.

👤: важный момент. я не хочу обучать модели сам. мне нужен готовый инструмент
🤖: Начните с OpenCV + YOLO от Ultralytics

Как можно заметить, я не силён в python от слова совсем 😅. Но я выбрал его, потому что осведомлён о его большой экосистеме инструментов ML в общем и компьютерного зрения в частности. 

И так стек найден. И с удивлением для меня, места для ImageMagic в нём не нашлось, ведь все необходимые инструменты для обработки уже есть в OpenCV.

А что стало с названием ImageWizard?

Тут всё банально. Я погуглил - это название уже занято приложением в сфере обработки изображений с ИИ 🤷. Пришлось найти незанятое. Но постарался оставить отсылку на ImageMagic

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

ImageSorcery 01 - Как я свой open source вайбкодил

Скажу честно, я хотел написать статью, для того чтобы рассказать о своём проекте ImageSorcery MCP. Но не хотелось писать рекламный BS о том какой он крутой. Хотелось сделать месседж более личным и искренним. Так статья превратилась в серию постов-заметок о всех тех граблях инструментах и практиках, которые мне удалось попробовать на пути от идеи до 100+ звёзд на гитхабе и ~100 ежедневных установок с pypi. А так как я фанатик экономии, весь стек в основном бесплатный (включая LLM) и часто не самый популярный.

Рост звёзд на гитхабе
Рост звёзд на гитхабе

В компании где я работаю, у меня сложилась репутация, как это принято сейчас говорить, ИИ-энтузиаста. Из-за чего ко мне однажды обратилась Системный Аналитик, которая только начала внедрять RooCode и столкнулась с какой-то проблемой полнейшего тупняка ИИ. Бесплатная веб версия Claude на раз два превращала Верхнеуровневые Бизнес Требования заказчика в детально проработанное Техническое Задание. Но копировать туда-сюда - не продуктивно, а ещё лимиты эти… Решилась она попробовать рекомендованный мною RooCode с Gemini flash. Установила впервые IDE VSCode, запустила и поставила плагин RooCode, подключила Gemini модель и попыталась скормить ему ту же задачу, но в ответ получила какой-то откровенный бред. Вместе мы выяснили, что для адекватной работы RooCode (а ещё его предшественника Cline и, скорее всего, последователя Kilo Code) требуется не просто запустить VSCode, но ещё и создать в нём проект с соответствующей директорий где-то в системе. А если ещё и все материалы сложить в эту директорию - их можно не копипастить и даже не драгндропать, а меньшонить через @ что намного удобней. (Даже мне стало плохо от обилия англицизмов в этом предложении, извините). Кроме того, выяснилось, что промпт содержал помимо текста ещё ссылку на Figma дизайн. А RooCode, несмотря на то что может используя браузер, какую-то осмысленную деятельность с этой ссылкой вести. При наличии у него Figma MCP справляется гораздо эффективнее.

И теперь бесплатный Gemini flash под капотом RooCode засиял во всей красе. Промпты стали проще и читаемей. И благодаря доступу ко всем необходимым файлам (ВБТ и шаблон) и инструментам, RooCode ваншотом не просто создал качественное ТЗ в формате markdown (привет markdown preview плагин), но ещё и наполнил его нужными скриншотами прямо в теле документа, чего Claude не мог. 

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

Фигня война! - сказал я, — наверняка есть MCP который это делает. 

Погуглив вместе минут 15 мы обнаружили, что такого нет. Но так как нарезка экранов на скриншоты - привычная для системного аналитика задача, она поблагодарила меня за получившийся результат и убежала на другой звонок. А я остался сидеть глядя в пустой монитор с непониманием, почему такая простая и очевидная задача ещё не решена.

Так появилась идея ImageWizard - взять ImageMagic и прикрутить к нему MCP протокол.

А почему сейчас проект и называется иначе и никакой связи с ImageMagic не имеет, расскажу в следующей серии.

Теги:
Всего голосов 3: ↑1 и ↓2+1
Комментарии0

Почему no-code ломает проекты⁠⁠

No-code выглядит соблазнительно.
Не надо учиться кодить. Разработчики не нужны. Накликал интерфейс - и запускай единорога.
Звучит красиво.

А на деле - быстро превращается в болото.
Недавно видел пример: ребята сделали приложение для изучения испанского языка на no-code.
Через месяц им пришлось переписать всё на код.
Причина простая - костыли.

И это не открытие. Я ещё лет десять назад видел такие штуки.
Delphi, Microsoft Access, Lotus Notes, позже Oracle APEX — там тоже можно было натыкать кнопочек, набросать интерфейс, и оно даже работало.
Но стоило захотеть что-то серьёзнее - и упираешься в потолок платформы.
В итоге такие проекты либо переписывают, либо бросают.

No-code повторяет ту же историю.
Хочешь добавить функцию - нельзя. Делаешь костыль.
Хочешь ещё - снова костыль.
Через месяц костылей так много, что проект перестаёт развиваться.

Да, есть исключения. Специализированные инструменты работают классно.
Тильда для лендингов. Airtable для таблиц. Retool для дашбордов.
Но это не «замена программистов», а «ускоритель для специалистов».

А универсальные конструкторы «сделай любое приложение без кода» - это мираж.
Ты вроде строишь продукт, а на деле собираешь небоскрёб на болоте.

Я сам часто запускаю проекты и пишу про эти попытки, удачные и не очень.
Так что тема no-code для меня не теория, а наблюдения из практики.

Теги:
Всего голосов 6: ↑5 и ↓1+4
Комментарии2

3 неочевидные ошибки при выводе стартапа на рынок

Поделюсь сегодня опытом по составлению Go-to-market-strategy. Ошибки, которые совершают фаундеры при выводе стартапов на рынок, в целом, однотипны: это попытки сделать все фичи сразу, игнорирование действий конкурентов, некачественный анализ рынка или аудитории, ошибки при расчете Unit-экономики. Об этом мы уже много раз говорили. Поэтому сегодня расскажу о нескольких “подводных камнях”, которые не очевидны сразу, особенно тем, кто запускает стартап впервые.

Распыление усилий на все сегменты ЦА на первоначальных этапах

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

Распределение равных усилий между каналами продвижения

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

Попытки строго следовать намеченному плану

Фаундеру стартапа необходим план. Однако еще больше необходима готовность от него отступить в случае необходимости.  У проекта должен быть план не только на полгода-год, но и на 2-3 года вперед. Это план должен содержать в себе прогноз по рынку - куда будет двигаться ваша сфера и будет ли ваш продукт соответствовать потребностям аудитории? При этом, важно понимать, что любой прогноз может не сбыться, поэтому придется быть подвижным и что-то менять в проекте и своём подходе к его реализации.

Вывод продукта на рынок - самый волнительный и ответственный момент для любого стартапа. Будьте гибкими, но последовательными!

Теги:
Рейтинг0
Комментарии0

Я читал книги про стартапы неправильно - и это убивало мой прогресс⁠⁠

Я тратил часы на «правильные» книги: Lean Startup, Zero to One, Founders at Work.
Читал, выделял цитаты, пересказывал друзьям.
И чувствовал себя молодцом.
Но на деле - стоял на месте.

Ошибка была в том, что я считал чтение действием.
Типа «разобрался в теории - значит сделал шаг вперёд».
А на практике - ноль: ни MVP, ни пользователей, ни метрик.

🔥 Суть в том, что книги нужны не для галочки, а как триггер к действиям:

  • Прочитал про customer discovery? 👉 иди и поговори с людьми.

  • Узнал про MVP? ⚡ собери лендинг за выходные.

  • Прочитал про метрики? 📊 настрой хоть простую табличку, а не сохраняй цитату в Notion.

Я понял: книги - это не знание, это список подсказок к реальным шагам.
Без действий чтение превращается в красивую форму прокрастинации.

Теперь у меня правило: «прочитал → сделал → проверил». ✅
И только так что-то сдвигается.

👉 Я делюсь такими инсайтами про indie-hacking, пет-проекты и запуск мини-SaaS у себя в телеге 🚀

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Потихоньку или “громко”: стратегии вывода стартапа на рынок

Когда все гипотезы проверены, тестирования пройдены, MVP собран, наступает волнительный и ответственный момент - вывод стартапа на рынок. Это не должно выглядеть так: запустили рекламу, сидим и ждем. Момент выхода и все процессы, которые сопровождают его, должны быть тщательно продуманы и собраны в стратегию.

Если рассматривать широко, существует два подхода к этому процессу - мягкий и жесткий. Можно встретить термины Soft Launch и Hard Launch. Они разные, но оба совершенно оправданы и эффективны по-своему.

Мягкий запуск напоминает подъем по лестнице. Ступень за ступенью, шаг за шагом, стартап выходит на новые и новые сегменты аудитории. При таком подходе есть возможность протестировать дополнительные гипотезы и понять, насколько хорошо аудитория на них реагирует. Эта стратегия идеально подойдет тем проектам, которые до конца не уверены в позиционировании или необходимости тех или иных фичей. Всегда есть шанс тихонько “откатить” какие-то детали продукта без последствий.

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

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

Теги:
Рейтинг0
Комментарии0