Стартапы крутятся, коды мутятся, разве что денег с этого пока нет 😁 классика )

Но речь пойдет не о доходах, а о нюансах процесса. У любого стартапа с мультиплатформенным продуктом всегда встает дилемма - какие технологии применить, чтобы сократить time-to-market. Мне как инженеру должно быть просто, подумаете вы, и ошибетесь. Инженеру-предпринимателю еще сложнее. Как инженер я не боюсь технической сложности, но как предприниматель боюсь быть втянут в решение технических, а не продуктовых проблем

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

Опытным путем доказано - Kotlin не является кроссплатформенным решением, экономически выгодным для стартапа. Ниже ряд причин:

- Родная среда для Kotlin - JVM и Android. Понадобятся годы, чтобы инструментарий для разработки под другие среды стал годен к использованию из коробки. Всё, что сейчас есть для разработки под iOS и Desktop предельно сыро - на iOS нет интеропа со Swift, а на десктопе тут и там торчат волосатые уши Java Swing. Тут и там нужны какие-то плагины к компилятору, настройка в Gradle - черная магия.

- Compose Multiplatfrom - безбожно тормозит на прокрутки даже простых списков, а Kotlin Multiplatform в быстрорастущих проектах обрастает такой сложностью, что нужна отдельная команда, вникающая в нюансы сборки и платформенной интеграции

- Единственным местом где можно что-то взять и сделать на Kotlin - это бекенд. Тут правят Spring и Quarkus. Вероятно, их использование было бы оправдано в all-in Kotlin стеке. Но как мы поняли концепция провалилась, а значит и корпоративных тяжеловесов из мира Java в стартап тянуть смысла нет.

Kotlin на беке больше Java чем Koltin: корутинами даже не пахнет, тащить в проект родные Kotlin-зависимости резона нет.

Еще один минус - JVM не для экономных. Даже оптимизированный Dockerfile на выходе дает образ минимум в 250-300 МБ. В рантайме инстанс тоже не мал и не блеснет производительностью. Нативные компиляторы типа GraalVM чтобы удешевить владение инфраструктурой -
лишние приседания, вредные для стартапа.

В итоге весь написанный Kotlin-код был заархивирован. Опыт получен. Бекенд был переписан с кучей новых фич Golang за 1,5 недели. Продуктивность стартаперская, docker-образ 9Мб, производительность чудовищная.

Мобильное приложение будет нативное. На Swift. Потому что я в нем эксперт.

Вывод. Берите то, что хорошо знаете или способны адаптировать в кратчайшие сроки. И если это не Kotlin, то он не станет для вас универсальным решением.

#стартап_в_соло@machine_head_ru

Риторической идеи пост

В предпоследнем комментарии, отчаянный борец за кибер-демократию и наш соотечественник Павел Дуров, объявил об эксклюзивном партнерстве с TON Foundation, в качестве финансовой инфраструктуры для экосистемы Телеграм.

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

Итак, что же нам предложил Павел в качестве новой альтернативной площадки для приложений и бизнеса:
- прием оплат только звездами где, например, уже заложена 30% комиссия Apple/Google
- 4% административные расходы Телеграм
- шкурный обменный курс из TON в фиатные деньги в официальном кошельке

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

Для честного бизнеса, предложение, мягко говоря, не про жизнь. Амбиции построить экосистему не дают Павлу покоя, на с «налогом Apple» бизнес модель не масштабируется дальше хомячьих тапалок. На этом фоне, похоже, родилось решение доить то, что есть не дожидаясь лучших времен, и теперь, все движения только через единственную платежную систему. Где-то такие требования мы уже видели. Ах да, в AppStore и GooglePlay.

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

Как сказал John Gall “Системы стремятся провалиться сразу же после своего величайшего триумфа”.

БДУИ или как мы решали одну проблему, а получили 10 других

Ребята из Авито в этой статье поделились описанием их реализации Backend-driven UI.

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

Какую проблему решали в Авито, по версии автора статьи:

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

Перевожу:

- Менеджеры хотят рулить интерфейсом самостоятельно
- Инженеров мало и их фокус нужно сохранять на том, что считается более приоритетным
- Хочется обновляться на входе в приложение, а не когда юзер обновится из стора

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

Классно же звучит, не так ли? Кажется, все проблемы решены.

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

- Обучение людей работе с конструктором. Так как внутренние решения не блещут отлаженностью, есть масса нюансов, которые знают кодеры, но очень туго воспринимают менеджеры.
- Бесконечные тикеты на апдейты конструктора и добавление новых фич в БДУИ
- Менеджеры стремятся абстрагивать всё что можно от программистов, в итоге на bdui переезжает столько интерфейса сколько возможно
- Создается отделый цикл релиза, контроля и тестирования где программист уже не имеет необходимого контекста, но должен присутствовать ибо менеджеры всё еще не знают всех нюансов - в итоге упускается масса проблем уходящих в продакшн.
- Менеджеры накручивают А/Б тесты, виджеты интерфейса под сложными условиями отображения, в итоге не ясно какой интерфейс видит пользователь

И самая большая проблема, от которой бежали, но в которую напоролись: BDUI также развивается как любой продукт, который надо обновлять. Его инфраструктура обновляется через сторы: фиксятся баги, добавляются фичи. Через какое-то время возникает чудовищная фрагментация возможностей фреймворка на девайсах юзеров. А JSON-то общий! Как для любого API приходится вводить фолбеки и версионирование. На практике же логгеры сыплют ошибками парсинга, интерфейс на глазах у юзера моргает и откатывается к дефолтному, написанному руками без всяких bdui, ну или к предыдущему стабильному макету, а это уже, напомню, возврат к третьей проблеме доставки фич в разное время.

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

BDUI, кто бы его не начал пилить, всегда лежит между нативом и кроссплатформой, вроде React Native, который, к слову, решает те же проблемы примерно тем же подходом. Но вместо объединения преимуществ, объединяются недостатки:

- Новый уровень абстракции и сложности в коде
- Новые процессы и люди там где их раньше не было
- Обновления через сторы не обойти
- Ухудшение стабильности и пользовательского опыта
- Энтропия ранее понятного и оттестированного нативного решения.
- Разработчики фреймворка становятся носителями уникальной экспертизы и создают риски в случае увольнения.

Как говорится, не хотели привлекать 1 разраба для решения тривиальных задач, теперь нужно 10, чтобы решать нетривиальные.

Напомню, что ios приложение Telegram практически полностью написал 1 человек. Это недостижимый уровень доверия и менеджмента, на который многие известные компании просто неспособны. Отсюда и БДУИ.

Яндекс за всё платит. Или обосрался. Смотрите видео, комментарии излишни 😂😂😂

Проверьте, у кого еще так же работает )

С праздником Великой Победы!

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

Рассказывайте своим детям о подвиге наших дедов и прадедов, о героях этой невообразимой по масштабам войны. 100-летие Победы организовывать им!

#80летпобеды

Фулстеков не бывает?

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

На заре популяризации профессии (я считаю 2000-2010 этим периодом) стек типичного программиста был… любой! Я после школы спокойно кодил на Си утилиты для MS-DOS/Windows, десктопные приложения на Delphi, в универе автоматизацию БД на FoxPro, анимировал на ныне почившем ActionScript в Macromedia Flash, вдохновляясь роликами Happy Tree Friends 💀. Помню, написал приложение на J2ME под Symbian, чтобы искать и качать музыку с зайцев.нет с возможностью дозагрузки при обрыве (из-за обрывов мобильной связи в Opera Mini приходилось постоянно перекачивать, а мегабайты недешевые, особенно для студента). Принцип был простой: стало интересно, пошел ковырнул совершенно ублюдскую на вид документацию, (если вообще была) написал 20-30 классов, собрал с матюками и готово. И уж чего я не припомню, так это желание пройти курсы по новому языку или фреймворку, чтобы что-то с ним закодить.

Так какая у меня тогда была специализация? Правильно, тыжпрограммист. Фуллстеками тогда и не пахло. Придумали их позже не программисты, а HR-ы. Им комфортнее всех разделить по департаментам, по скилам, по грейдам, чтобы стало проще понимать кто перед ними. В период с 2010-го по 2015-ый, на который пришелся резкий рост запроса на кодеров, оказалось, что на рынке совершенно отсутствуют кадры. В компаниях осознали, получить “Symphony/Angular/Android/Spring/<название фреймворка>” разработчиков можно быстрее, чем дожидаться магистров информатики.

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

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

Фуллстек это или нет, решайте сами или поделитесь мнением в комментариях.

Тот случай, когда смотришь на тень и видишь пиксели виртуальной реальности, в которой мы живем 😏

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

Но первый комментарий вообще не об апдейтах. Вот что неприятно, WWDC воспринимают как очередную консюмерскую презентацию и народ бухтит: мало фич, всё не то, редизайны нам не нужны, пук-пук-пук… А на самом деле, под капотом просто лавина крайне значимых изменений. К концу года половина приложений будет в новом дизайне. Это вам не бездарный Material 3 Expressive, от одного вида которого хочется сдать смартфон обратно в магазин.

Благодаря редизайну обычные юзеры накатят ios 26 если не публичной бете, то сразу после релиза. Adoption rate новой iOS снова побьет все рекорды. Это значит, разрабочики могут внедрять новые api практически сразу, а не через 3 года. Или через 6 как в андроиде. Какой смысл накидываться на компанию за несостоявшийся апдейт Siri. Все такие умные, наслушались мастеров поджигать пердаки с ютуба и вторят за ними. Google тоже бесконечно что-то обещает. Сколько из вас пользуется Google Assistant? Много приложений уже интегрировали Gemini? Камон, никто больше не дает такой девелоперский опыт и драйв рынка как Apple.

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

Попросил ChatGPT 4.1 сгенерировать изображение как он меня видит на основе наших чатов.

Неожиданно. 🫣

Блеск и нищета AI стартапов

Еще 2 года назад стартаперы были полны оптимизма вступить технологическую AI гонку и хорошенько заработать, то сейчас в воздухе витают тревожные ожидания: «а не напрасны ли усилия», «не убьет ли новый будничный апдейт Perplexity наш стартап <впишите название>.

Почему так происходит

Благодаря колоссальному притоку инвестиционных денег AI технологии: LLMs и архитектура вокруг них (RAG, векторные базы, MCP, Memory Management и тд), в невероятно короткий срок достигли своей технологической зрелости. Разница между «голой» моделью и нишевым применением в кастомизации обвязки вокруг этой модели. На BigTech тут действуют все те же силы что и раньше. Их платформа всё также должна быть достаточно универсальной.
Тем не менее для них, более нишевый AI — это не R&D на годы, а задачка на квартал.
Стартапам же приходится собирать всё с нуля, настраивать архитектуру, вечно что-то интегрировать. И, когда они что-то находят, крупняк заходит и просто встраивает этот функционал в свою экосистему предлагая апдейт за старый прайс.

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

И вот, когда 95% рынка уже распилены на годы вперед, нам остается искать возможности в оставшихся 5%. Но именно тут и могут на руках оказаться реальные козыри:

- Эксклюзивные данные: то, чего нет ни у одного облака, постоянно пополняемые up-to-date данные.

- Нишевые инструменты: умение решать проблему именно так как этого ждет клиент, подобая стандартам и правилам принятым в его области.

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

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

Ценность теперь не в технологиях, а в данных и знаниях о реальной боли пользователя.

Цифрови… ИИ-зация!

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

Согласно отчету Росстата за 2023 год, только 27,4% малых предприятий используют CRM-системы для управления взаимодействием с клиентами. ERP решения, обеспечивающие интеграцию внутренних бизнес-процессов, внедрены лишь у 12,1% представителей малого предпринимательства. По данным PwC, в среднем один цифровой проект на малом предприятии реализуется с бюджетом 0,8–1,2 млн рублей. В конечном счете, цифровизация в малом бизнесе преимущественно имеет фрагментарный и реактивный характер. Вместо целенаправленных стратегий используются разовые инициативы, не вписанные в общую управленческую модель.

Источник

В то же время, ИИ быстрее всего адаптируется в потребительском сегменте откуда протекает в бизнес среду. По данным исследования аналитического центра НАФИ:

В каждом третьем предприятии МСП (30%) руководители использовали инструменты на базе искусственного интеллекта.

То есть, ИИ однозначно дал толчок рынку, но низкий уровень цифровизации является ключевым барьером на пути интеграции ИИ в реальные бизнес-процессы. По данным исслевателей, основные препятствия – ограниченные бюджеты (до 60% МСБ не могут инвестировать более 3% выручки в ИТ) и нехватка квалифицированных кадров (65% компаний испытывают трудности с наймом ИТ-специалистов).

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

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

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

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