... Но, как обычно, есть нюанс. Matrix — это скорее инженерное решение, чем массовый продукт. Такие системы чаще используют компании, open-source-сообщества или организации с высокими требованиями к контролю инфраструктуры. Для обычных пользователей это всё ещё немного сложнее, чем просто установить мессенджер из App Store и написать «привет».
Следующим сценарием, если у вас позволяют ресурсы, будет собственная разработка. Такие решения обычно строятся вокруг идеи полного контроля: данные хранятся внутри инфраструктуры компании, доступ управляется корпоративными политиками безопасности, а сама коммуникация может интегрироваться с внутренними системами — от документооборота до CRM.
Звучит, конечно, серьёзно. И это действительно серьёзно. Потому что в этот момент мессенджер перестаёт быть приложением и превращается в IT-проект: его нужно развернуть, поддерживать, обновлять, защищать и администрировать. Зато появляется то, чего не может дать ни один публичный сервис — полный контроль над инфраструктурой коммуникации.
Поэтому такой сценарий обычно выбирают компании, для которых коммуникация — это не просто чат между сотрудниками, а критическая часть бизнес-процессов.
И, наконец, есть ещё один сценарий. Самый простой. И, если честно, скорее всего, он и останется самым массовым.
Ничего не менять.
Просто продолжать пользоваться Telegram — но уже через VPN. Технически это самый короткий путь: установить VPN и работать дальше примерно так же, как раньше. Для личных чатов это вообще почти незаметное изменение. Но для компаний всё немного сложнее. Во-первых, не все готовы постоянно использовать VPN. Во-вторых, в корпоративных сетях такие решения нередко запрещены политиками безопасности. А в-третьих, инфраструктура, которая работает «через обход», всё-таки остаётся инфраструктурой с дополнительным слоем сложности. Поэтому для частного использования этот сценарий вполне реалистичен. А вот для рабочих процессов он обычно рассматривается скорее как временная мера.
Если посмотреть на все эти сценарии вместе, становится понятно: скорее всего, не появится одного сервиса, который просто заменит Telegram. Скорее коммуникации начнут распределяться между разными инструментами. Чаты могут жить в одном месте, сообщества — в другом, корпоративные процессы — в третьем. Это будет менее удобно, чем когда всё собрано в одном окне. Но, возможно, и более устойчиво: инфраструктура, распределённая между несколькими платформами, переживает любые дальнейшие блокировки гораздо спокойнее.
Следующим сценарием, если у вас позволяют ресурсы, будет собственная разработка. Такие решения обычно строятся вокруг идеи полного контроля: данные хранятся внутри инфраструктуры компании, доступ управляется корпоративными политиками безопасности, а сама коммуникация может интегрироваться с внутренними системами — от документооборота до CRM.
Звучит, конечно, серьёзно. И это действительно серьёзно. Потому что в этот момент мессенджер перестаёт быть приложением и превращается в IT-проект: его нужно развернуть, поддерживать, обновлять, защищать и администрировать. Зато появляется то, чего не может дать ни один публичный сервис — полный контроль над инфраструктурой коммуникации.
Поэтому такой сценарий обычно выбирают компании, для которых коммуникация — это не просто чат между сотрудниками, а критическая часть бизнес-процессов.
И, наконец, есть ещё один сценарий. Самый простой. И, если честно, скорее всего, он и останется самым массовым.
Ничего не менять.
Просто продолжать пользоваться Telegram — но уже через VPN. Технически это самый короткий путь: установить VPN и работать дальше примерно так же, как раньше. Для личных чатов это вообще почти незаметное изменение. Но для компаний всё немного сложнее. Во-первых, не все готовы постоянно использовать VPN. Во-вторых, в корпоративных сетях такие решения нередко запрещены политиками безопасности. А в-третьих, инфраструктура, которая работает «через обход», всё-таки остаётся инфраструктурой с дополнительным слоем сложности. Поэтому для частного использования этот сценарий вполне реалистичен. А вот для рабочих процессов он обычно рассматривается скорее как временная мера.
Если посмотреть на все эти сценарии вместе, становится понятно: скорее всего, не появится одного сервиса, который просто заменит Telegram. Скорее коммуникации начнут распределяться между разными инструментами. Чаты могут жить в одном месте, сообщества — в другом, корпоративные процессы — в третьем. Это будет менее удобно, чем когда всё собрано в одном окне. Но, возможно, и более устойчиво: инфраструктура, распределённая между несколькими платформами, переживает любые дальнейшие блокировки гораздо спокойнее.
❤3🤝3🔥2
На прошлой неделе знакомый прислал запрос на аутстаффинг React-разработчиков для одного своего клиента. Оказалось, что это стартап. Причём на казенных деньгах — с дедлайнами, отчётностью и всеми вытекающими. Дальше больше: на вопрос, какую именно команду нужно усиливать, выяснилось, что усиливать, в общем-то, некого. Нет ни тимлида, ни разработчика, ни девопса — вообще никого, кто хотя бы делает вид, что понимает, как всё это должно работать. Бэклога, декомпозиции задач, ТЗ — тоже нет. Есть Figma и дизайнер, который, как выяснилось позже, ещё и кофаундер. В этот момент, у нормального человека включается базовый инстинкт самосохранения и он вежливо ссылается на 100% загруз и невозможность взять проект в работу. Но мне стало очень интересно, что же такое скрывается за всей этой ситуацией…
(спойлер: всё было ровно так, как я и предполагал).
После разговора с товарищем (сам фаундер, разумеется, был очень занят и встретиться не смог) картина начала проясняться. Идея была высоко оценена государством, под неё выдали грант. Полгода назад.
Дальше — всё по учебнику. Фаундер, не сильно разбираясь в разработке, находит программиста. Одного (классика). Программист что-то делает и в какой-то момент просто исчезает (опять классика). На текущий момент: до дедлайна и отчётности — полтора месяца. Из результатов — Figma (процентов тридцать от того, что вообще должно быть) и заготовки речи перед контролирующими органами, почему “не шмогла”.
Эх… ладно… Описали проект, определили то, как за оставшееся время выполнить полугодовой объем работ (благо опыт есть). Трижды отдельно проговорили одну простую мысль: «если стартуем не сейчас — не успеем» и отправили коммерческое.
Дальше начинается мое любимое — тишина. Понимая, что, скорее всего, напугали ценой и с проектом нам не по пути, спрашиваю у знакомого, как там дела? Ответ прекрасный: «ждёт коммерческие от других». Конкуренция — это хорошо. Рынок, все дела. Ждём ещё несколько дней — ничего. Убедившись, что дальше не поедем, все же решаю выяснить, как ответит фаундер. А фаундер… перестал выходить на связь.
Мораль? В таких историях проблема не в разработчиках, которые «пропали». Не в продукте и не в сроках, которые внезапно стали критичными. Проблема в отношении. Когда проект изначально запускается без команды, без структуры и без понимания, кто за что отвечает — это не временные сложности. Это способ работы. Когда полгода проходят без результата, без фиксации решений и без какого-либо контроля — это не «не повезло с подрядчиком». Это предсказуемый итог отсутствия управления. А когда в критической точке вместо решений начинается ожидание, сравнение и исчезновения — это уже не сбой. Это закономерное продолжение той же самой модели.
В такой конструкции не имеет значения, кто зайдёт в проект следующим. Можно сменить подрядчика, можно увеличить бюджет, можно поменять технологии. Не изменится только одно — подход. Ведь как там говорил то ли Энштейн, то ли какой-то алкоголик: «Безумие — это делать одно и то же снова и снова, ожидая иного результата»
(спойлер: всё было ровно так, как я и предполагал).
После разговора с товарищем (сам фаундер, разумеется, был очень занят и встретиться не смог) картина начала проясняться. Идея была высоко оценена государством, под неё выдали грант. Полгода назад.
Дальше — всё по учебнику. Фаундер, не сильно разбираясь в разработке, находит программиста. Одного (классика). Программист что-то делает и в какой-то момент просто исчезает (опять классика). На текущий момент: до дедлайна и отчётности — полтора месяца. Из результатов — Figma (процентов тридцать от того, что вообще должно быть) и заготовки речи перед контролирующими органами, почему “не шмогла”.
Эх… ладно… Описали проект, определили то, как за оставшееся время выполнить полугодовой объем работ (благо опыт есть). Трижды отдельно проговорили одну простую мысль: «если стартуем не сейчас — не успеем» и отправили коммерческое.
Дальше начинается мое любимое — тишина. Понимая, что, скорее всего, напугали ценой и с проектом нам не по пути, спрашиваю у знакомого, как там дела? Ответ прекрасный: «ждёт коммерческие от других». Конкуренция — это хорошо. Рынок, все дела. Ждём ещё несколько дней — ничего. Убедившись, что дальше не поедем, все же решаю выяснить, как ответит фаундер. А фаундер… перестал выходить на связь.
Мораль? В таких историях проблема не в разработчиках, которые «пропали». Не в продукте и не в сроках, которые внезапно стали критичными. Проблема в отношении. Когда проект изначально запускается без команды, без структуры и без понимания, кто за что отвечает — это не временные сложности. Это способ работы. Когда полгода проходят без результата, без фиксации решений и без какого-либо контроля — это не «не повезло с подрядчиком». Это предсказуемый итог отсутствия управления. А когда в критической точке вместо решений начинается ожидание, сравнение и исчезновения — это уже не сбой. Это закономерное продолжение той же самой модели.
В такой конструкции не имеет значения, кто зайдёт в проект следующим. Можно сменить подрядчика, можно увеличить бюджет, можно поменять технологии. Не изменится только одно — подход. Ведь как там говорил то ли Энштейн, то ли какой-то алкоголик: «Безумие — это делать одно и то же снова и снова, ожидая иного результата»
2❤4🔥2😁2
В конце прошлой недели у меня была встреча с потенциальным клиентом. Не стартап. Не студент с презентацией на 15 слайдов. Вполне серьёзная, окологосударственная структура. Обсуждали новый цифровой продукт и, как это водится, в воздухе снова повисло это нечистоплотное понятие “MVP”. И вот что меня каждый раз искренне забавляет. MVP в таких разговорах произносится с тем же выражением лица, с которым люди говорят “давайте возьмём эконом” — как будто речь идёт о тарифе, а не о решении, которое потом будет которое, при неправильно заложенной архитектуре, сожрет всю вашу экономию и два изначальных бюджета на всю разработку.
MVP — это не способ торговаться с реальностью. Это способ с ней договориться. Когда вы делаете MVP, вы на старте принимаете несколько ключевых решений: какие сценарии критичны — и должны работать безупречно, какие можно упростить или временно выбросить, какие риски допустимы, а какие — нет. И вот здесь начинается то, о чём обычно предпочитают не думать. Потому что архитектура, технологии и команда — это не “опции, которые можно докрутить потом”. Это база! Можно упростить интерфейс, можно отложить вторичные функции, можно не делать часть интеграций. Но если вы экономите на архитектуре, вы не упрощаете продукт — вы закладываете ограничения. Ограничения на масштабирование, ограничения на скорость изменений, ограничения на саму возможность развития. И в какой-то момент они перестают быть техническими. Они становятся проблемой всего бизнеса. Потому что продукт начинает упираться не в рынок, а в собственную конструкцию и на выходе у нас классический сценарий:
— MVP
— допилили
— почему так сложно менять?
— переписываем.
Правильный MVP — это не “сделать проще”. Это сделать нормальный продукт, в котором сейчас реализована только малая часть. С самого начала должно быть понятно:
— как будет расти продукт,
— куда ляжет новый функционал,
— как система переживёт увеличение нагрузки,
— что произойдёт, когда количество сценариев удвоится.
Это не значит “сразу делать всё”. Это значит — проектировать так, чтобы потом не пришлось ломать. Хороший MVP всегда выглядит проще, чем он есть на самом деле. Потому что снаружи — минимум функций, а внутри — конструкция, рассчитанная на развитие. И если выбирать, на чём экономить, ответ всегда один: на объёме, а не на фундаменте.
MVP — это не способ торговаться с реальностью. Это способ с ней договориться. Когда вы делаете MVP, вы на старте принимаете несколько ключевых решений: какие сценарии критичны — и должны работать безупречно, какие можно упростить или временно выбросить, какие риски допустимы, а какие — нет. И вот здесь начинается то, о чём обычно предпочитают не думать. Потому что архитектура, технологии и команда — это не “опции, которые можно докрутить потом”. Это база! Можно упростить интерфейс, можно отложить вторичные функции, можно не делать часть интеграций. Но если вы экономите на архитектуре, вы не упрощаете продукт — вы закладываете ограничения. Ограничения на масштабирование, ограничения на скорость изменений, ограничения на саму возможность развития. И в какой-то момент они перестают быть техническими. Они становятся проблемой всего бизнеса. Потому что продукт начинает упираться не в рынок, а в собственную конструкцию и на выходе у нас классический сценарий:
— MVP
— допилили
— почему так сложно менять?
— переписываем.
Правильный MVP — это не “сделать проще”. Это сделать нормальный продукт, в котором сейчас реализована только малая часть. С самого начала должно быть понятно:
— как будет расти продукт,
— куда ляжет новый функционал,
— как система переживёт увеличение нагрузки,
— что произойдёт, когда количество сценариев удвоится.
Это не значит “сразу делать всё”. Это значит — проектировать так, чтобы потом не пришлось ломать. Хороший MVP всегда выглядит проще, чем он есть на самом деле. Потому что снаружи — минимум функций, а внутри — конструкция, рассчитанная на развитие. И если выбирать, на чём экономить, ответ всегда один: на объёме, а не на фундаменте.
1❤3🤣1
На прошлой неделе менеджер отрабатывал очередное возражение в духе “Конкуренты предлагают навайбкодить нам в три раза дешевле”. И это всегда звучит как отличная новость. Почти как если бы сложные системы внезапно перестали быть сложными, а многолетний опыт архитекторов вдруг обесценился до уровня рилсов в инстаграмах. Проблема в другом: любые аргументы перестают работать, когда вопрос логики превращается в вопрос веры.
Пользуем ли мы сами ИИ в работе? Конечно. Как и любая вменяемая компания сегодня. Более того, не трогать его — это примерно как продолжать писать код в блокноте и гордиться этим. Вопрос давно не в самом факте использования, вопрос в том, как именно это делается. Курсор, Клауд и еже с ними уверенно пишут код, уверенно предлагают решения, уверенно поясняют за “best practice”. И, что самое пугающее, ты начинаешь им верить.. если у тебя нет понимания, а как все устроено на самом деле.
А на самом деле все не совсем так, как говорят вайб-кодинг гуру. ИИ не просто помогает писать код. Он начинает формировать систему — кусок за куском, решение за решением. И если в этот момент нет жёсткого понимания архитектуры, границ и правил — система собирается не как спроектированная, а как.. да только космос знает как. И в этом-то и трагедия ситуации.
Сначала это незаметно. Наоборот, всё идёт быстрее. Легче. Даже приятнее. А потом появляется странное ощущение, что код как будто сопротивляется. Любое изменение затрагивает неожиданные части, ломает то, что “не должно было” ломаться, требует заново разбираться, как это вообще работает или вообще переписывать все с нуля, потому что ИИ забыл то, что делал два дня назад.
Разница между проектированием и генерацией примерно такая же, как между продуманной системой и набором решений, которые просто не успели друг другу помешать. Генерация даёт скорость. Проектирование — управляемость. И вот здесь начинается самая дорогая часть, о которой, обычно, забывают: сгенерированный код нужно проверять, встраивать в архитектуру, ограничивать, переписывать или просто выбрасывать в окно. ИИ не берёт на себя эту работу. Он не следит за целостностью системы. Не отвечает за последствия. Не думает о том, что будет с этим кодом через полгода.
Это делает человек. И это не джуненок, который “в целом разобрался” по ютубу. Это дорогой разработчик с опытом, который видит, где система может полететь к чертям. Ирония в том, что именно это время и пытаются сэкономить. Хотя по факту все с точностью до наоборот: чем больше генерации без контроля — тем дороже потом стоит вернуть системе управляемость.
Поэтому все споры про “вайб-кодинг заменит разработку” обычно заканчивается одинаково: либо у вас есть архитектура, ограничения и люди, которые держат систему под контролем, либо у вас есть генерация. В первом случае ИИ действительно даёт ускорение, во втором — более быстрый способ накопить проблем.
Пользуем ли мы сами ИИ в работе? Конечно. Как и любая вменяемая компания сегодня. Более того, не трогать его — это примерно как продолжать писать код в блокноте и гордиться этим. Вопрос давно не в самом факте использования, вопрос в том, как именно это делается. Курсор, Клауд и еже с ними уверенно пишут код, уверенно предлагают решения, уверенно поясняют за “best practice”. И, что самое пугающее, ты начинаешь им верить.. если у тебя нет понимания, а как все устроено на самом деле.
А на самом деле все не совсем так, как говорят вайб-кодинг гуру. ИИ не просто помогает писать код. Он начинает формировать систему — кусок за куском, решение за решением. И если в этот момент нет жёсткого понимания архитектуры, границ и правил — система собирается не как спроектированная, а как.. да только космос знает как. И в этом-то и трагедия ситуации.
Сначала это незаметно. Наоборот, всё идёт быстрее. Легче. Даже приятнее. А потом появляется странное ощущение, что код как будто сопротивляется. Любое изменение затрагивает неожиданные части, ломает то, что “не должно было” ломаться, требует заново разбираться, как это вообще работает или вообще переписывать все с нуля, потому что ИИ забыл то, что делал два дня назад.
Разница между проектированием и генерацией примерно такая же, как между продуманной системой и набором решений, которые просто не успели друг другу помешать. Генерация даёт скорость. Проектирование — управляемость. И вот здесь начинается самая дорогая часть, о которой, обычно, забывают: сгенерированный код нужно проверять, встраивать в архитектуру, ограничивать, переписывать или просто выбрасывать в окно. ИИ не берёт на себя эту работу. Он не следит за целостностью системы. Не отвечает за последствия. Не думает о том, что будет с этим кодом через полгода.
Это делает человек. И это не джуненок, который “в целом разобрался” по ютубу. Это дорогой разработчик с опытом, который видит, где система может полететь к чертям. Ирония в том, что именно это время и пытаются сэкономить. Хотя по факту все с точностью до наоборот: чем больше генерации без контроля — тем дороже потом стоит вернуть системе управляемость.
Поэтому все споры про “вайб-кодинг заменит разработку” обычно заканчивается одинаково: либо у вас есть архитектура, ограничения и люди, которые держат систему под контролем, либо у вас есть генерация. В первом случае ИИ действительно даёт ускорение, во втором — более быстрый способ накопить проблем.
1❤3💯2
На прошлой неделе участвовали в очередном тендере. За пару часов до окончания закупки требования переписали. Потом ещё раз. Потом ещё. Финальную версию ТЗ прислали в пятницу вечером — с дедлайном в утро понедельника. В таких ситуациях обычно остаётся два варианта: либо подрядчик уже определён и тендер — это формальность, либо внутри компании абсолютно нет понимания, что именно они выбирают и как вообще должен этот выбор проходить. И да, оба эти сценария периодически мэтчатся в рамках одного проекта.
Но проблема даже не в этом. В сложной разработке на старте обычно нет ни архитектуры, ни полной картины рисков — есть только гипотеза и написанное кем-то, кто не собирается его реализовывать, ТЗ. В этот момент попытка провести тендер начинает выглядеть примерно как: выбрать подрядчика на строительство дома, не определившись с тем, сколько в нём будет этажей.
В такой конструкции тендер выбирает не лучшего подрядчика. Он выбирает либо того, кто смелее пообещал, либо того, кто сильнее занизил оценку. При этом от всех участников ожидается, что они на основании неполного ТЗ, без нормальной проработки и даже без разговора с заказчиком, дадут точную оценку системы на 5–6 месяцев разработки. И обязательно зафиксируют окончательный бюджет без рисков.
А риски эти никуда не делись и начинают проявляться уже в работе — когда бюджет зафиксирован, сроки согласованы, а пространство для манёвра отсутствует начисто. В этот момент часть решений приходится упрощать, часть — откладывать, а где-то искать компромиссы, которые изначально не планировались. И дальше вопрос уже не в том, будет ли деградировать качество, а в том, когда это станет заметно.
В сложной разработке подрядчика нельзя выбирать «вслепую» — по ТЗ, презентации и цифрам в коммерческом предложении. Потому что в этот момент сравниваются не команды, а их интерпретации задачи, причём без нормальной синхронизации с заказчиком. Без разговора, без проработки, без понимания, как команда думает и принимает решения, выбор неизбежно смещается в сторону тех, кто лучше продаёт неопределённость.
В результате выбирается не тот, кто лучше справится с задачей, а тот, кто убедительнее описал, как он с ней справится. А это разные вещи. Сложные проекты не покупаются как коробка — они собираются в процессе. И если до старта не было нормального контакта с командой, не было обсуждения решений, подходов и ограничений, то на выходе почти всегда получается кривой результат. Не потому что подрядчик плохой, а потому что его выбрали не за способность сделать, а за способность пообещать.
Но проблема даже не в этом. В сложной разработке на старте обычно нет ни архитектуры, ни полной картины рисков — есть только гипотеза и написанное кем-то, кто не собирается его реализовывать, ТЗ. В этот момент попытка провести тендер начинает выглядеть примерно как: выбрать подрядчика на строительство дома, не определившись с тем, сколько в нём будет этажей.
В такой конструкции тендер выбирает не лучшего подрядчика. Он выбирает либо того, кто смелее пообещал, либо того, кто сильнее занизил оценку. При этом от всех участников ожидается, что они на основании неполного ТЗ, без нормальной проработки и даже без разговора с заказчиком, дадут точную оценку системы на 5–6 месяцев разработки. И обязательно зафиксируют окончательный бюджет без рисков.
А риски эти никуда не делись и начинают проявляться уже в работе — когда бюджет зафиксирован, сроки согласованы, а пространство для манёвра отсутствует начисто. В этот момент часть решений приходится упрощать, часть — откладывать, а где-то искать компромиссы, которые изначально не планировались. И дальше вопрос уже не в том, будет ли деградировать качество, а в том, когда это станет заметно.
В сложной разработке подрядчика нельзя выбирать «вслепую» — по ТЗ, презентации и цифрам в коммерческом предложении. Потому что в этот момент сравниваются не команды, а их интерпретации задачи, причём без нормальной синхронизации с заказчиком. Без разговора, без проработки, без понимания, как команда думает и принимает решения, выбор неизбежно смещается в сторону тех, кто лучше продаёт неопределённость.
В результате выбирается не тот, кто лучше справится с задачей, а тот, кто убедительнее описал, как он с ней справится. А это разные вещи. Сложные проекты не покупаются как коробка — они собираются в процессе. И если до старта не было нормального контакта с командой, не было обсуждения решений, подходов и ограничений, то на выходе почти всегда получается кривой результат. Не потому что подрядчик плохой, а потому что его выбрали не за способность сделать, а за способность пообещать.
❤1
Представьте ребёнка в кресле стоматолога. Не того, который спокойно открывает рот по команде. А того, который уже в коридоре клиники начинает плакать. Потому что не понимает, что сейчас произойдёт, кто этот человек в маске и почему больно даже когда ещё не начали.
Это не каприз. Это страх от неизвестности. И у детей с особенностями восприятия он в несколько раз сильнее. Скоро заканчиваем веб-сервис для подготовки таких детей к медицинским визитам, который сейчас у нас на этапе интеграции бэка с фронтом. Родитель заранее проходит с ребёнком через весь сценарий: анкета, чек-лист, обучающий контент, социальные истории с фото самого ребёнка. Врач до приёма видит карточку пациента, не просто имя и дату рождения и еще до знакомства понимает: что пугает, к чему готовы, что уже проработали дома.
Звучит как здравый смысл. Но такого сервиса не было. Теперь почти есть — мы на финишной прямой.
Взяли этот проект примерно за половину от того, что обычно стоит разработка такого уровня. Не потому что не умеем считать, а потому что иногда встречаешь задачу, где вопрос денег отходит на второй план. Бизнес должен зарабатывать — я в этом убеждён. Но я также убеждён, что компания, которая никогда не делает ничего просто потому что это правильно, в какой-то момент теряет что-то человеческое.
Про сам сервис расскажу подробнее после запуска — там есть интересные технические решения и неочевидные продуктовые выборы, о которых стоит поговорить отдельно. Если у вас есть проекты, где задача важнее бюджета — напишите: @DChuchulin. Найдем решение.
Это не каприз. Это страх от неизвестности. И у детей с особенностями восприятия он в несколько раз сильнее. Скоро заканчиваем веб-сервис для подготовки таких детей к медицинским визитам, который сейчас у нас на этапе интеграции бэка с фронтом. Родитель заранее проходит с ребёнком через весь сценарий: анкета, чек-лист, обучающий контент, социальные истории с фото самого ребёнка. Врач до приёма видит карточку пациента, не просто имя и дату рождения и еще до знакомства понимает: что пугает, к чему готовы, что уже проработали дома.
Звучит как здравый смысл. Но такого сервиса не было. Теперь почти есть — мы на финишной прямой.
Взяли этот проект примерно за половину от того, что обычно стоит разработка такого уровня. Не потому что не умеем считать, а потому что иногда встречаешь задачу, где вопрос денег отходит на второй план. Бизнес должен зарабатывать — я в этом убеждён. Но я также убеждён, что компания, которая никогда не делает ничего просто потому что это правильно, в какой-то момент теряет что-то человеческое.
Про сам сервис расскажу подробнее после запуска — там есть интересные технические решения и неочевидные продуктовые выборы, о которых стоит поговорить отдельно. Если у вас есть проекты, где задача важнее бюджета — напишите: @DChuchulin. Найдем решение.
❤5👍3
Все свободное время на прошлой неделе я проводил с Claude. Осознанно, методично и без угрызений совести. Разница между ним и ChatGPT чувствовалась также быстро, как улетали токены в более свежей и дорогой модели. Контекст в два раза шире, галлюцинаций заметно меньше, а инструкциям Клод следует практически идеально.
Дошло до того, что я основательно полез в бэкенд. Не с запросом “напиши мне чатик со стикерами”, а в проблемную серверную логику. С ограничениями, запретами доступов и DevOPS на финише.
Еще год назад, как бы грамотно ты ни ставил задачу, насколько подробно не писал промт — модель всё равно понимала по-своему. Снаружи было похоже на правду, но под капотом — сплошной архитектурный джаз с размерами в духе 19/32…
Сейчас модель перестала думать за тебя. Вернее — она думает строго в рамках того что ты задал. Как хороший прораб: получил чертёж, построил по чертежу. Без инициативы перенести несущую стену потому что «так будет лучше смотреться». Ты проектируешь — она исполняет. Именно в таком порядке.
ChatGPT 3.5 помнил от силы несколько страниц диалога, не умел смотреть на картинки и знал мир только до 2021 года. Сейчас модели держат в контексте целые кодовые базы — не файл, а весь проект. Умеют сомневаться и перепроверять себя. Работают автономно: получила задачу, разбила на шаги, выполнила, проверила, исправила. Это не апдейт — это скачок. И за таким всегда стоит что-то конкретное — не гениальность инженеров и не щедрость инвесторов.
Конкуренция сделала за последние два года то, чего не случилось бы за пять лет монополии. Пока Open AI был один — прогресс шёл по его расписанию. Потом появились Anthropic, Google, китайцы с DeepSeek. И внезапно выяснилось что расписание можно переписать.
Монополист оптимизирует маржу. Конкурент оптимизирует продукт. Эта разница хорошо знакома любому кто работал с корпоративными подрядчиками — пока ты один, можно особо не стараться. Как только появляется альтернатива — отношение меняется на глазах.
Я это называю здоровой паранойей рынка. И именно она объясняет почему инструмент который я держу сегодня в руках — принципиально другой чем год назад. И, кстати, он в пять раз дороже ChatGPT, но это не отбило желания оплатить подписку...
Дошло до того, что я основательно полез в бэкенд. Не с запросом “напиши мне чатик со стикерами”, а в проблемную серверную логику. С ограничениями, запретами доступов и DevOPS на финише.
Еще год назад, как бы грамотно ты ни ставил задачу, насколько подробно не писал промт — модель всё равно понимала по-своему. Снаружи было похоже на правду, но под капотом — сплошной архитектурный джаз с размерами в духе 19/32…
Сейчас модель перестала думать за тебя. Вернее — она думает строго в рамках того что ты задал. Как хороший прораб: получил чертёж, построил по чертежу. Без инициативы перенести несущую стену потому что «так будет лучше смотреться». Ты проектируешь — она исполняет. Именно в таком порядке.
ChatGPT 3.5 помнил от силы несколько страниц диалога, не умел смотреть на картинки и знал мир только до 2021 года. Сейчас модели держат в контексте целые кодовые базы — не файл, а весь проект. Умеют сомневаться и перепроверять себя. Работают автономно: получила задачу, разбила на шаги, выполнила, проверила, исправила. Это не апдейт — это скачок. И за таким всегда стоит что-то конкретное — не гениальность инженеров и не щедрость инвесторов.
Конкуренция сделала за последние два года то, чего не случилось бы за пять лет монополии. Пока Open AI был один — прогресс шёл по его расписанию. Потом появились Anthropic, Google, китайцы с DeepSeek. И внезапно выяснилось что расписание можно переписать.
Монополист оптимизирует маржу. Конкурент оптимизирует продукт. Эта разница хорошо знакома любому кто работал с корпоративными подрядчиками — пока ты один, можно особо не стараться. Как только появляется альтернатива — отношение меняется на глазах.
Я это называю здоровой паранойей рынка. И именно она объясняет почему инструмент который я держу сегодня в руках — принципиально другой чем год назад. И, кстати, он в пять раз дороже ChatGPT, но это не отбило желания оплатить подписку...
👍4❤3
Как экономить на рекламе? Делать нормально..
#ITбизнес #разработка #качество #репутация #продажи #CTO #предприниматель #аутсорс #клиенты #маркетинг
#ITбизнес #разработка #качество #репутация #продажи #CTO #предприниматель #аутсорс #клиенты #маркетинг
❤6😁4🔥1
На выходных читал расследование Time про Oracle. В шесть утра без объявления войны 30 000 айтишников были уволены… через рассылку. Но предыстория куда интереснее. Часть этих людей до увольнения месяцами участвовала во внутренних программах по обучению корпоративного ИИ — описывала процессы, передавала экспертизу, размечала данные. Добросовестно готовила инструмент который в итоге сделал их лишними.
У людей на такие новости первая реакция — паника. ИИ убивает. Но подождите. Oracle уволила людей которые выполняли воспроизводимые функции. Описывали процессы, составляли документации, делали то что хорошо формализуется. Именно это машина и забрала. Не профессию — функцию. Как раз об этом я и писал год назад…
Раньше инструментом был программист. Ему ставили задачу — он исполнял. Сейчас инструмент — ИИ. Разработчик нового поколения — это не тот кто пишет код, это тот кто его описывает. И для этого ему не столько нужно знание конкретного языка программирования, сколько четкие понимания:
— как система устроена в целом до того как написана первая строчка
— как разбить задачу на компоненты и предусмотреть где что–то пойдёт не так
— что такое сервер, CI/CD, переменные окружения и реверс-прокси
— где живут данные, кто к ним имеет доступ и почему это критично
— как части системы общаются между собой
— API, очередей, различных типов баз данных
А что взамен? ИИ даёт знание всех языков одновременно.
Барьер входа в профессию сместился. Раньше он назывался синтаксис — выучи язык, набей руку, стань разработчиком. Понятно, измеримо, воспроизводимо. Именно поэтому это и отдали машине. Сейчас барьер — мышление. Системное, творческое, критическое. И его ИИ воспроизводить не научились. По крайней мере, пока…
#ИИ #разработка #ITбизнес #будущееIT #технологии #CTO #программирование #стартап #цифровизация #искусственныйинтеллект
У людей на такие новости первая реакция — паника. ИИ убивает. Но подождите. Oracle уволила людей которые выполняли воспроизводимые функции. Описывали процессы, составляли документации, делали то что хорошо формализуется. Именно это машина и забрала. Не профессию — функцию. Как раз об этом я и писал год назад…
Раньше инструментом был программист. Ему ставили задачу — он исполнял. Сейчас инструмент — ИИ. Разработчик нового поколения — это не тот кто пишет код, это тот кто его описывает. И для этого ему не столько нужно знание конкретного языка программирования, сколько четкие понимания:
— как система устроена в целом до того как написана первая строчка
— как разбить задачу на компоненты и предусмотреть где что–то пойдёт не так
— что такое сервер, CI/CD, переменные окружения и реверс-прокси
— где живут данные, кто к ним имеет доступ и почему это критично
— как части системы общаются между собой
— API, очередей, различных типов баз данных
А что взамен? ИИ даёт знание всех языков одновременно.
Барьер входа в профессию сместился. Раньше он назывался синтаксис — выучи язык, набей руку, стань разработчиком. Понятно, измеримо, воспроизводимо. Именно поэтому это и отдали машине. Сейчас барьер — мышление. Системное, творческое, критическое. И его ИИ воспроизводить не научились. По крайней мере, пока…
#ИИ #разработка #ITбизнес #будущееIT #технологии #CTO #программирование #стартап #цифровизация #искусственныйинтеллект
❤5👍2
Вчера бронировал гостиницу. Картинки в яндекс.путешествия в очередной раз не подгрузились и какой именно номер выбирается, остается загадкой. Полез в поиск… Позвонил в отель напрямую, администратор что-то уточнял пару минут и ответил, что номер нужной категории занят. При этом в онлайне, будто бы, нет..
HoReCa — это, наверное, одна из последних отраслей, где операционка до сих пор живёт в блокноте и excel. Сервисов на рынке, на самом деле, хватает: контур.отель, bnovo, logus. даже Битрикс в ту же степь пробует. Но беда в том, что одного решения под все задачи отеля либо нет, либо цена такая, что позволить его себе может, разве что крупная федеральная сеть.
Собственно, потому в рамках miceсonnect мы и начали разработку большого пакета решений для номерного фонда, который, вполне себе будет доступен как гостиничному комплексу, так и загородному глэмпингу.
Что внутри:
— управление номерным фондом через гибкий конструктор
— не жёсткий шаблон, а настройка под конкретный объект
— шахматка бронирования в реальном времени с динамическими статусами номеров — housekeeping
— статусы уборки синхронизированы с бронированием
— ролевая модель для сотрудников
— от горничной до управляющего сетью
— учёт гостей и история проживания
— дополнительные услуги
— мини-бар, SPA, трансфер и всё что нужно конкретному объекту
— self check-in через Telegram-бота — гость передаёт данные сам, администратор просто принимает
Одно окно. Все процессы. Все сотрудники — от ресепшена до горничной. Без таблиц и звонков про «я уточню».
HoReCa — это, наверное, одна из последних отраслей, где операционка до сих пор живёт в блокноте и excel. Сервисов на рынке, на самом деле, хватает: контур.отель, bnovo, logus. даже Битрикс в ту же степь пробует. Но беда в том, что одного решения под все задачи отеля либо нет, либо цена такая, что позволить его себе может, разве что крупная федеральная сеть.
Собственно, потому в рамках miceсonnect мы и начали разработку большого пакета решений для номерного фонда, который, вполне себе будет доступен как гостиничному комплексу, так и загородному глэмпингу.
Что внутри:
— управление номерным фондом через гибкий конструктор
— не жёсткий шаблон, а настройка под конкретный объект
— шахматка бронирования в реальном времени с динамическими статусами номеров — housekeeping
— статусы уборки синхронизированы с бронированием
— ролевая модель для сотрудников
— от горничной до управляющего сетью
— учёт гостей и история проживания
— дополнительные услуги
— мини-бар, SPA, трансфер и всё что нужно конкретному объекту
— self check-in через Telegram-бота — гость передаёт данные сам, администратор просто принимает
Одно окно. Все процессы. Все сотрудники — от ресепшена до горничной. Без таблиц и звонков про «я уточню».
❤46🤩34🥰12👍10🔥9👏5
Настоящий тест для инструмента — это не песочница и не туториал. Это реальный коммерческий проект где цена ошибки измеряется не оценкой на курсе а деньгами и репутацией. Вчера я настраивал CI/CD инфраструктуру с нуля. Впервые в жизни. На реальном продакшне. Для понимания масштаба моей компетентности в DevOps — до вчерашнего дня единственное что я делал — это оплачивал хостинг.
Первые шесть часов я делал всё руками, исключительно советуясь с ИИ, чтобы ничего не сломать. По шагам, через браузер и терминал. Каждая ошибка была отдельным приключением с непредсказуемой концовкой. SSL сертификат который не обновляли с февраля. CORS который не работал потому что переменная называлась не так. Фронтенд который перехватил порт 80 и решил что теперь он главный. Это было похоже на сборку боевого танка по инструкции от шкафа из HOFF.
В какой-то момент AI начал давать сбои: тупить, забывать, перебирать варианты решений по несколько раз. Контекстное окно выпало, подумалШтирлиц я и выпал следом. Отложив ноут на некоторое время и вернувшись, я решил что хуже уже не будет — и скопировав все исходники дал Claude Code полный доступ к инфре.
Сорок минут. Он не продолжил с того места где я остановился — он начал с начала. Прошёлся по всей инфраструктуре и нашёл то что я не искал. Нашёл Docker Swarm который пробрасывал порты наружу минуя файрвол — тихо, методично, будто так и надо. Обнаружил Apache от хостинговой панели который никто не звал но он уже здесь, сидит на трафике и делает вид что это его дом. Заметил что UFW на первом сервере мы вообще не настроили — это как поставить сигнализацию на машину и забыть закрыть окна. Перед каждым изменением спрашивал разрешения. Что характерно — мои спецы так делают далеко не всегда.
Вчера я сделал работу которую не умел делать. И это лучшее что со мной случилось за последнее время — не потому что поднял продакшн, а потому что стал чуть лучше понимать людей которые делают это каждый день. Что такое конфликт портов на самом деле. Почему DevOps морщится когда видит захардкоженные переменные. Где живёт та самая магия которая превращает код на ноуте в работающий сервис. AI не просто помог — он провёл меня через чужую профессию за один день. Я не стал DevOps. Но теперь я точно знаю что спрашивать.
P.S. для DevOps`ов:
Стек: Docker Swarm, GitLab CI/CD, nginx, Let's Encrypt, MinIO, NestJS, React
Что нашёл и исправил Claude Code:
— истёкший SSL сертификат на GitLab Registry
— не обновляли с февраля
— неправильные названия переменных окружения (VITE_API_URL вместо VITE_APP_BASE_URL)
— из-за этого не работал CORS
— фронтенд контейнер занял порт 80 и перехватывал все запросы включая API домен
— NetAngels панель с Apache перехватывала трафик
— nginx слушал на конкретном IP вместо 0.0.0.0:80
— Docker Swarm пробрасывал порты 3000/3001 наружу минуя UFW
— добавил защиту через iptables DOCKER-USER chain
— FRONTEND_ORIGIN в prod-стеке строился из IP вместо домена
— UFW на DEV сервере вообще не был настроен
— выпустил SSL на оба домена одновременно
— смержил develop→main через GitLab API
— проверил MinIO: PUT/GET/DELETE операции в обоих бакетах с обоих серверов
— написал DEVOPS .md
#DevOps #CICD #клодкод #ИИинструменты #разработка #ITбизнес #вайбкодинг #Claude #инфраструктура #claudecode
Первые шесть часов я делал всё руками, исключительно советуясь с ИИ, чтобы ничего не сломать. По шагам, через браузер и терминал. Каждая ошибка была отдельным приключением с непредсказуемой концовкой. SSL сертификат который не обновляли с февраля. CORS который не работал потому что переменная называлась не так. Фронтенд который перехватил порт 80 и решил что теперь он главный. Это было похоже на сборку боевого танка по инструкции от шкафа из HOFF.
В какой-то момент AI начал давать сбои: тупить, забывать, перебирать варианты решений по несколько раз. Контекстное окно выпало, подумал
Сорок минут. Он не продолжил с того места где я остановился — он начал с начала. Прошёлся по всей инфраструктуре и нашёл то что я не искал. Нашёл Docker Swarm который пробрасывал порты наружу минуя файрвол — тихо, методично, будто так и надо. Обнаружил Apache от хостинговой панели который никто не звал но он уже здесь, сидит на трафике и делает вид что это его дом. Заметил что UFW на первом сервере мы вообще не настроили — это как поставить сигнализацию на машину и забыть закрыть окна. Перед каждым изменением спрашивал разрешения. Что характерно — мои спецы так делают далеко не всегда.
Вчера я сделал работу которую не умел делать. И это лучшее что со мной случилось за последнее время — не потому что поднял продакшн, а потому что стал чуть лучше понимать людей которые делают это каждый день. Что такое конфликт портов на самом деле. Почему DevOps морщится когда видит захардкоженные переменные. Где живёт та самая магия которая превращает код на ноуте в работающий сервис. AI не просто помог — он провёл меня через чужую профессию за один день. Я не стал DevOps. Но теперь я точно знаю что спрашивать.
P.S. для DevOps`ов:
Стек: Docker Swarm, GitLab CI/CD, nginx, Let's Encrypt, MinIO, NestJS, React
Что нашёл и исправил Claude Code:
— истёкший SSL сертификат на GitLab Registry
— не обновляли с февраля
— неправильные названия переменных окружения (VITE_API_URL вместо VITE_APP_BASE_URL)
— из-за этого не работал CORS
— фронтенд контейнер занял порт 80 и перехватывал все запросы включая API домен
— NetAngels панель с Apache перехватывала трафик
— nginx слушал на конкретном IP вместо 0.0.0.0:80
— Docker Swarm пробрасывал порты 3000/3001 наружу минуя UFW
— добавил защиту через iptables DOCKER-USER chain
— FRONTEND_ORIGIN в prod-стеке строился из IP вместо домена
— UFW на DEV сервере вообще не был настроен
— выпустил SSL на оба домена одновременно
— смержил develop→main через GitLab API
— проверил MinIO: PUT/GET/DELETE операции в обоих бакетах с обоих серверов
— написал DEVOPS .md
#DevOps #CICD #клодкод #ИИинструменты #разработка #ITбизнес #вайбкодинг #Claude #инфраструктура #claudecode
🥰55❤28👏14🤩13🔥12👍1
Обновление по теме которую поднимал в начале мая. Наш новый SaaS управления недвижимостью обзавелся брендом (Lobby) и сайтом. 30% готовности, ранний доступ. Бессрочно и без подписки. Welcome!
#HoReCa #отель #гостиничныйбизнес #SaaS #Miceconnect #автоматизация #стартап #ITбизнес #продукт #LobbyPMS
#HoReCa #отель #гостиничныйбизнес #SaaS #Miceconnect #автоматизация #стартап #ITбизнес #продукт #LobbyPMS
❤41🤩27🥰24👍16🔥14👏10
На прошлой неделе в Петербурге обсуждал с заказчиком одну интересную побочку тотальной автоматизации. Чем красивее документация — тем меньше у людей желания в неё лазить. Процессы написаны, задачи декомпозированы, риски задокументированы. Всё структурировано и выглядит законченным. Исполнитель не перечитывает — и так понятно что всё ок. Менеджер не перепроверяет — выглядит профессионально. В итоге никто не смотрит что реально происходит внутри. А реальное состояние проекта обнаруживается позже всех — теми кто за него платит.
Работа аналитика при этом не изменилась. Изменилась цена ошибки. Раньше плохой анализ был виден сразу — кривой документ, противоречивые требования, заказчик который морщится уже на первой презентации. Это был сигнал — копать глубже. Сейчас ИИ убрал этот сигнал. Любой анализ выглядит профессионально. Поверхностная мысль упакована так же красиво как глубокая — и едет дальше по конвейеру. В разработку, в тестирование, в прод. Где и выясняется что красивый документ описывал не ту задачу.
Ценность аналитика сместилась. Не в сторону скорости — ИИ быстрее. Не в сторону оформления — ИИ красивее. В сторону качества вопросов. Умение остановить красивый конвейер и спросить неудобное — вот что теперь дорого стоит. «Подождите — а зачем нам вообще это?» «Мы точно решаем ту проблему?» «Что будет если мы ошиблись здесь?» Эти вопросы раздражают. Замедляют. И они единственное что отличает хорошего аналитика от дорогого генератора документов.
#ITбизнес #бизнесанализ #управлениепроектами #разработка #автоматизация #ИИ #CTO #продукт #стартап #Elgrow
Работа аналитика при этом не изменилась. Изменилась цена ошибки. Раньше плохой анализ был виден сразу — кривой документ, противоречивые требования, заказчик который морщится уже на первой презентации. Это был сигнал — копать глубже. Сейчас ИИ убрал этот сигнал. Любой анализ выглядит профессионально. Поверхностная мысль упакована так же красиво как глубокая — и едет дальше по конвейеру. В разработку, в тестирование, в прод. Где и выясняется что красивый документ описывал не ту задачу.
Ценность аналитика сместилась. Не в сторону скорости — ИИ быстрее. Не в сторону оформления — ИИ красивее. В сторону качества вопросов. Умение остановить красивый конвейер и спросить неудобное — вот что теперь дорого стоит. «Подождите — а зачем нам вообще это?» «Мы точно решаем ту проблему?» «Что будет если мы ошиблись здесь?» Эти вопросы раздражают. Замедляют. И они единственное что отличает хорошего аналитика от дорогого генератора документов.
#ITбизнес #бизнесанализ #управлениепроектами #разработка #автоматизация #ИИ #CTO #продукт #стартап #Elgrow
🥰52❤20🔥17🤩11👏9👍4
Завершили работы по очередному мобильному приложению. И снова — финальный вопрос от заказчика: «А как теперь это публиковать?» С 2022 года мы отвечаем на него стабильно пару раз в месяц.
Казалось бы — остался последний шаг. Но в нашей географии публикация давно перестала быть формальностью. Карты не проходят, аккаунты не открываются с первого раза, советы из интернета гуляют трёхлетней давности. И всё это — после того как основная работа уже сделана.
App Store
Регистрация относительно простая — нужен Apple ID. Если публикуете от юрлица — DUNS-номер: запрашивается прямо через сайт Apple, приходит на почту за пару дней. Все манипуляции лучше делать через VPN.
С оплатой сложнее. С 1 апреля 2026 года по решению Минцифры МТС, Билайн, Мегафон и Т2 отключили пополнение через мобильный счёт навсегда. Российские карты не работают с 2022-го. Что остаётся:
— подарочные карты App Store — счёт зарубежного банка — регистрация Apple ID в регионе Казахстан или Армения и оплата иностранной картой
Последний вариант сейчас самый рабочий.
Google Play
Здесь сложнее — и по регистрации и по монетизации. Аккаунт разработчика стоит $25 разовый взнос. Google верифицирует серьёзнее — паспортные данные плюс документ с именем и адресом. Подойдёт квитанция за интернет. Главное — все данные должны совпадать. Бесплатные приложения публикуются без ограничений, модерация до суток. А вот с монетизацией всё — с 26 декабря 2024 года Google Play прекратил выплаты на российские счета. Последний перевод был 15 января 2025 года. Единственный рабочий путь — иностранное юрлицо. Казахстан, Армения, ОАЭ — наиболее популярные варианты.
RuStore
Если аудитория российская и приложение под Android — вариант реальный. С сентября 2025 года RuStore предустановлен на всех смартфонах продаваемых в России. Аудитория есть, российские платёжные системы работают. Нюанс один: с февраля 2026 года монетизация доступна только для ИП и юрлиц. Физические лица публиковать могут — но платные приложения автоматически скрываются с витрины.
Публикация в 2026 году — это отдельный проект внутри проекта. Со своими сроками, документами и сюрпризами. Это новая реальность — не временная и не исключительная. Хорошая новость: всё решаемо. Плохая: не в последний момент. Закладывайте месяц — и начинайте готовиться параллельно с разработкой, а не после её завершения.
#мобильнаяразработка #AppStore #GooglePlay #RuStore #разработка #ITбизнес #мобильныеприложения #Elgrow #публикация #санкции
Казалось бы — остался последний шаг. Но в нашей географии публикация давно перестала быть формальностью. Карты не проходят, аккаунты не открываются с первого раза, советы из интернета гуляют трёхлетней давности. И всё это — после того как основная работа уже сделана.
App Store
Регистрация относительно простая — нужен Apple ID. Если публикуете от юрлица — DUNS-номер: запрашивается прямо через сайт Apple, приходит на почту за пару дней. Все манипуляции лучше делать через VPN.
С оплатой сложнее. С 1 апреля 2026 года по решению Минцифры МТС, Билайн, Мегафон и Т2 отключили пополнение через мобильный счёт навсегда. Российские карты не работают с 2022-го. Что остаётся:
— подарочные карты App Store — счёт зарубежного банка — регистрация Apple ID в регионе Казахстан или Армения и оплата иностранной картой
Последний вариант сейчас самый рабочий.
Google Play
Здесь сложнее — и по регистрации и по монетизации. Аккаунт разработчика стоит $25 разовый взнос. Google верифицирует серьёзнее — паспортные данные плюс документ с именем и адресом. Подойдёт квитанция за интернет. Главное — все данные должны совпадать. Бесплатные приложения публикуются без ограничений, модерация до суток. А вот с монетизацией всё — с 26 декабря 2024 года Google Play прекратил выплаты на российские счета. Последний перевод был 15 января 2025 года. Единственный рабочий путь — иностранное юрлицо. Казахстан, Армения, ОАЭ — наиболее популярные варианты.
RuStore
Если аудитория российская и приложение под Android — вариант реальный. С сентября 2025 года RuStore предустановлен на всех смартфонах продаваемых в России. Аудитория есть, российские платёжные системы работают. Нюанс один: с февраля 2026 года монетизация доступна только для ИП и юрлиц. Физические лица публиковать могут — но платные приложения автоматически скрываются с витрины.
Публикация в 2026 году — это отдельный проект внутри проекта. Со своими сроками, документами и сюрпризами. Это новая реальность — не временная и не исключительная. Хорошая новость: всё решаемо. Плохая: не в последний момент. Закладывайте месяц — и начинайте готовиться параллельно с разработкой, а не после её завершения.
#мобильнаяразработка #AppStore #GooglePlay #RuStore #разработка #ITбизнес #мобильныеприложения #Elgrow #публикация #санкции
🎉24😁23👍22🔥21❤19
Сегодня утром Anthropic прислал письмо — вышел Fable 5. Новейшая и самая мощная модель Claude. Opus 4.8, между прочим, появился двенадцать дней назад — и уже перестал быть последним словом техники. В конце апреля я писал, что конкуренция моделей разогнала рынок до неприличия. Оказалось — поскромничал. В индустрии, где релиз флагманской модели раньше был событием года, теперь стал событием вторника.
Хронология для понимания масштаба. Opus 4.7 выходит 16 апреля, Opus 4.8 — 28 мая — через 41 день. Это, кстати, рекорд Anthropic — самый короткий интервал между флагманскими релизами в их истории. Fable 5 — 9 июня, ещё через двенадцать дней. Три модели за два месяца. Для сравнения: между прошлыми поколениями проходило по полгода, и это считалось нормальным темпом для индустрии.
Зачем такая спешка? Инженеры Anthropic не стали работать в три раза быстрее. Просто в спину дышат. За этот же период OpenAI обновил Codex, Google выкатил свежий Gemini. Пауза в таких условиях — это подарок конкуренту. Но есть и второй слой: и Anthropic и OpenAI готовятся к IPO в этом году. Скорость релизов перестала быть только инженерной метрикой — теперь это аргумент для инвесторов. Кто чаще выпускает — тот выглядит живее на бирже. Гонка моделей превратилась в гонку капитализаций.
Теперь пара слов о самом Fable 5. Это первая публичная модель класса Mythos — того самого, который Anthropic до последнего держал закрытым. Причина закрытости звучит как синопсис фантастического фильма: модель слишком хорошо находила уязвимости в софте. Настолько хорошо, что компания побоялась отдавать её в открытый доступ и выдавала только проверенным организациям из критической инфраструктуры. Fable 5 — это та же мощь, но с предохранителями: в опасных областях вроде кибербезопасности и биологии модель просто отказывается отвечать.
Вывод из всего этого простой и неудобный. Развитие ИИ — это не прямая, это экспонента. Полгода между релизами, потом 41 день, потом 12. Дальше — меньше. Мы привыкли оценивать технологии в линейной логике: «ну через год станет процентов на двадцать лучше». С ИИ эта логика не работает и уже подводит тех кто на неё опирается. Через год будет не «лучше на двадцать процентов». Будет другая реальность. Готовиться к ней стоит уже сейчас — хотя бы потому что письмо о следующей модели придёт раньше чем вы планируете.
#ИИ #AI #Anthropic #Claude #искусственныйинтеллект #технологии #ITбизнес #будущееIT #конкуренция #CTO #стартап
Хронология для понимания масштаба. Opus 4.7 выходит 16 апреля, Opus 4.8 — 28 мая — через 41 день. Это, кстати, рекорд Anthropic — самый короткий интервал между флагманскими релизами в их истории. Fable 5 — 9 июня, ещё через двенадцать дней. Три модели за два месяца. Для сравнения: между прошлыми поколениями проходило по полгода, и это считалось нормальным темпом для индустрии.
Зачем такая спешка? Инженеры Anthropic не стали работать в три раза быстрее. Просто в спину дышат. За этот же период OpenAI обновил Codex, Google выкатил свежий Gemini. Пауза в таких условиях — это подарок конкуренту. Но есть и второй слой: и Anthropic и OpenAI готовятся к IPO в этом году. Скорость релизов перестала быть только инженерной метрикой — теперь это аргумент для инвесторов. Кто чаще выпускает — тот выглядит живее на бирже. Гонка моделей превратилась в гонку капитализаций.
Теперь пара слов о самом Fable 5. Это первая публичная модель класса Mythos — того самого, который Anthropic до последнего держал закрытым. Причина закрытости звучит как синопсис фантастического фильма: модель слишком хорошо находила уязвимости в софте. Настолько хорошо, что компания побоялась отдавать её в открытый доступ и выдавала только проверенным организациям из критической инфраструктуры. Fable 5 — это та же мощь, но с предохранителями: в опасных областях вроде кибербезопасности и биологии модель просто отказывается отвечать.
Вывод из всего этого простой и неудобный. Развитие ИИ — это не прямая, это экспонента. Полгода между релизами, потом 41 день, потом 12. Дальше — меньше. Мы привыкли оценивать технологии в линейной логике: «ну через год станет процентов на двадцать лучше». С ИИ эта логика не работает и уже подводит тех кто на неё опирается. Через год будет не «лучше на двадцать процентов». Будет другая реальность. Готовиться к ней стоит уже сейчас — хотя бы потому что письмо о следующей модели придёт раньше чем вы планируете.
#ИИ #AI #Anthropic #Claude #искусственныйинтеллект #технологии #ITбизнес #будущееIT #конкуренция #CTO #стартап
1❤104🤩96🥰40🔥19👍13👏5
Последнее время тут было тихо. Каюсь. Но причина веская. Самый сложный заказчик из возможных. Ты сам.
Года два мы подбирались к собственному бренду, и всё как в том анекдоте: то времени нет, то свисток не рабочий, то акула глухая. В мае терпение кончилось и было принято волевое решение — «пока всё не съешь, из-за стола не выйдешь».
Результат: за три недели сделано больше, чем за весь прошлый год. Переосмыслили себя и своё место на рынке, сваяли новый фирменный стиль и запилили новый сайт. Сблэк-джеком и шлю… упоротой совой.
Эти три недели мы не спали. Правки в полночь, споры о шрифтах до хрипоты, двадцатая версия главной страницы, которая вышла хуже первой. Довольны? Безусловно. Хотим повторить? Ни в коем случае. А из побочек осталось единственное желание — сибасья в лес — орать на муравейник..
#Elgrow #ребрендинг #новыйсайт #фирменныйстиль #вебразработка #ITбизнес #enterprise #разработка #брендинг #дизайн
Года два мы подбирались к собственному бренду, и всё как в том анекдоте: то времени нет, то свисток не рабочий, то акула глухая. В мае терпение кончилось и было принято волевое решение — «пока всё не съешь, из-за стола не выйдешь».
Результат: за три недели сделано больше, чем за весь прошлый год. Переосмыслили себя и своё место на рынке, сваяли новый фирменный стиль и запилили новый сайт. С
Эти три недели мы не спали. Правки в полночь, споры о шрифтах до хрипоты, двадцатая версия главной страницы, которая вышла хуже первой. Довольны? Безусловно. Хотим повторить? Ни в коем случае. А из побочек осталось единственное желание — сибасья в лес — орать на муравейник..
#Elgrow #ребрендинг #новыйсайт #фирменныйстиль #вебразработка #ITбизнес #enterprise #разработка #брендинг #дизайн
1🤩121🥰110❤89👏78👍71🔥45
This media is not supported in your browser
VIEW IN TELEGRAM
Не успел я наорать на все муравейники в Манжероке и вернуться в работу, как на внутреннем согласовании уже новый проект от старого заказчика. Иногда мы берём в работу сайты. Особенно когда от «многокодить» уже хочется «крепковыпивать».
🥰97❤64🤩44👏19🔥18👍17
В середине апреля на пресейле отвалился один клиент. Сказал, что решили вести разработку своими силами. В конце июня вернулся с повинной: один из сотрудников убедил руководство, что все можно сделать с помощью ИИ и никакие подрядчики не нужны. В итоге, минус три месяца, какие-то таблички, дашборды, UI-элементы, а продукта как не было так и нет.
И сколько не говори, а ежики кололись, плакали, но продолжали жрать кактус. ИИ — это не специалист, это — инструмент. Разница примерно как между бензопилой и лесорубом. Бензопила — штука отличная. Но если дать её тому, кто не отличает сосну от собственной ноги — результат будет впечатляющим, но в другом ключе.
А таких кейсов становится только больше — тенденция крепчает вместе с хайпом. Казаться стало проще, чем быть: пара недель, немного нейронки — и вот уже есть что показать на демо. Правда, демо и эксплуатация, к сожалению, не одно и то же. Терпение у бизнеса, при этом, ресурс конечный и плохо восполняемый. И когда оно заканчивается, приходится возвращаться к подрядчику.
И таких кейсов, справедливости ради, тоже становится больше...
— Дмитрий Чучулин, Elgrow. Связь: @DChuchulin
#разработка #ИИ #вайбкодинг #заказнаяразработка #ITбизнес #продукт #пресейл #CTO #стартап #Elgrow
И сколько не говори, а ежики кололись, плакали, но продолжали жрать кактус. ИИ — это не специалист, это — инструмент. Разница примерно как между бензопилой и лесорубом. Бензопила — штука отличная. Но если дать её тому, кто не отличает сосну от собственной ноги — результат будет впечатляющим, но в другом ключе.
А таких кейсов становится только больше — тенденция крепчает вместе с хайпом. Казаться стало проще, чем быть: пара недель, немного нейронки — и вот уже есть что показать на демо. Правда, демо и эксплуатация, к сожалению, не одно и то же. Терпение у бизнеса, при этом, ресурс конечный и плохо восполняемый. И когда оно заканчивается, приходится возвращаться к подрядчику.
И таких кейсов, справедливости ради, тоже становится больше...
— Дмитрий Чучулин, Elgrow. Связь: @DChuchulin
#разработка #ИИ #вайбкодинг #заказнаяразработка #ITбизнес #продукт #пресейл #CTO #стартап #Elgrow
1🤩36❤21👏8👍6🔥5🥰4