Неуспешный неуспех в NO CODE и AI

AiEnglishTeacher traction 4, GPT updates, part 2 4) Настройка модели, с которой работать. Тоже минорная штука, но супер полезная - теперь на фронте можно поставить модельку для обоих юзкейсов - array system или ассистент 5) SAAS версия для юзеров Самая жирная часть работы, на которую у разраба Димы ушло 2 месяца. Клиент захотел сделать SAAS версию - та же самая логика, но для внешних юзеров, по подписке. Работает также как и для школ. Еще не запаблишена. Куда расти: 1) Не затестили еще functions calls - должно раз и навсегда решить проблему редких галлюцинаций форматинга. Особенно актуально для модельки 3.5, где форматинг в 50% кейсов ведет себя как хочет. Можно будет поставить дешевую модельку и держать форматинг functional коллом. 2) Можно затестить другие LMM модели 3) Я хочу поработать с промптингом и за счет него улучшить результат в нашем обычном запросе с system. Сложности с App Master: 1) Сталкиваемся с кучей багов в App Master, в основном на фронте. Он пока очень сырой, но работает уже намного быстрее, чем раньше. После недавнего обновления полетела половина фронта. Но ребята правят и обещали все выровнять. 2) Месяц назад у нас удалились все связи в БД из-за того, что несколько человек сидели в редакторе БД. App Master это не поддерживает пока. Для тех, кто не в контексте - это рип всего проекта. Но ребята из App Master быстро включились и руками за 2 дня восстановили бэкапы и все логики. Было страшно. 3) Почти нет документации. Это самая главная проблема тула. У ребят не хватает времени, чтобы описывать все, что они творят. Чаще всего, чтобы получить ответ на вопрос, надо писать в чат и ждать. 4) И плюс к прошлому пункту: в недавнем времени App Master закрыл все чаты поддержки в ТГ и перешел на веб-форум, как все тулы. Теперь идти в поддержку супер неудобно, не понимаю этого решения. У ребят большинство юзеров - русские с телеграммами. Good point App Master-а, который пока покрывает проблемы выше: Команда App Master и мое общение с фаундером. При жопе я иду напрямую и кричу про проблему. В среднем ребята решают баги быстро и помогают разобраться в системе. И если надо созвониться с их сотрудниками. В bubble, n8n и flutter flow такой плюшки нет. Во всех новых проектах тестируем стэк: - Bubble / Flutter Flow - фронт - N8N - бэк, бизнес-процессы - Supabase - база данных В следующем отчетике расскажу про продвижения в логике и тестах клиента, закончим второй контракт через недели 2 как раз. Кратко: коннект с Google Classroom школ и формирование отчетов GPT ответов и результатов учеников.

AiEnglishTeacher traction 4, GPT updates, part 1 Это не выложенный пост от апреля 2024 года. Сейчас у нас больше апдейтов, но расскажу про них попозже. Напомню про наш ключевой заказной продукт. Ключевой - потому что он запущен в лайве на пару школ США и им пользуется около 500 учеников. Это AI "проверяльщик" домашек по английскому в школах США: - gpt оценивает письмо по системе rubric - gpt дает фидбек ученику - что подправить Прошлые посты о трекшене продукта: ⁃ Как мы сделали альфу версию за 2 недели - Трекшен 2. Как мы добились почти 0 разницы фидбека учителя и AI - AI teacher, project update: первые 300 учеников в апе, лумчик продукта. Hello guys from HH. Этот пост на половину технический, поэтому прикрепляю небольшой словарик: - фронт - frontend, то что ты видишь глазками 👀 - бэк - backend, то что ты не видишь глазками 👀, процессы под капотом - логи - результаты исполнения каких-либо действий в системе. Тут важно смотреть на статус success/error и тем самым отслеживать ошибки - API ключ - штука, которая соединяет 2 системы - Таймаут - время ожидания исполнения процесса. Если действие не успеет завершиться, то оно прерывается. - Лоадер - круглешочек, который крутиться на загрузках объекта или страницы - Ассистент approach - это один из способов вызова GPT. Работает по принципу: создаем в интерфейсе Open AI ассистента, даем ему инструкцию и даже можем прикрепить документы для обучения - Array approach - самый простой способ работы с GPT. Грузите в system сообщение инструкцию и в сообщение юзера запрос к GPT. Array c инглиша - массив сообщений = переписка с GPT. 1) Ассинхронный процесс в GPT: В течение 2 месяцев нам в логи прилетали ошибки - отсутствие API ключа в запросе. Мы были уверены в проблему интеграции Open AP App Master и ждали исправления. Проблему нельзя было отследить при тестах, потому что ни разу процесс не ломался. Недавно это же стало критично: в один день 30 реальных учеников из 100 получили ошибки. Перепроверив все, что можно, Олег (фаундер App Master) рассказал про возможную причину - таймаут* на фронте. Из-за долгого ожидания ответа GPT на фронте. И предложил сделать ассинхронный процесс: - отправляем на фронте запрос на бэк и завершаем его - как только процесс на бэке завершается - отправляем ответ обратно на фронт Интересно, что сценарий подтвердился на колле с проджектом проекта, но немного в другом обличии: Проджект при мне перезагрузила страницу, не дождавшись завершения процесса(конца работы лоадера*). И логично, что в таких кейсах мы получаем ошибку. И тут меня осенило - чуваки просто прерывают процесс, не дожидаясь конца лоадера, потому что ждать 2 минуты - не кайф и кажется, что надо обновить (у меня тоже стандартный паттерн, если при этом нет надписи - не перезагружай). Снова убеждаюсь, что коллы с юзерами и просмотр их UX - лучший способ доставания инсайтов. Вот как работает решение сейчас - записал лум для клиента, делюсь с вами 2) Ассистент* VS Array* approach Мы наконец выкатили процесс с ассистентом, который был гипотезой для решения пары проблемок: - более предсказуемый результат форматинга ответа - чтобы заголовки были жирненькие - сократить затраты на создание ответа GPT - сделать результат более качественным - за счет документов в ассистенте - примеры идеальных проверок писем А также подключили процесс к фронту и сделал наглядный сравнительный пример с 2 результатами: способ array и assistant Процесс тоже ассинхронный - не надо ждать на странице, пока он закончится - можно запустить обработку хоть 10 процессов одновременно. Лумчик для клиента, показываю вам: https://www.loom.com/share/60d6b5ae911d47e3bc4544de690445e6?sid=05184a2b-d3d2-4b99-ade7-4c3d81dc0805 Результат ассистента: Если кратко - провал. Ассистент выходит в 4 раза дороже с последней моделькой из-за большого кол-ва инфы, на которой он учится. Клиенту было важно не сильно поднимать стоимость одной оценки. Ребята решили оставить старую логику Array. 3) Сохранение в БД стоимости токенов Поэтому важно сравнить разные модели в разных типах GPT генераций - array и assistant. Начали все считать.

Sprints-hours VS fix price contract. Трекшен за весну в Hi no code, part 1. Свитч бизнес-модели. Мало сюда пишу = теряю скилл и связь с вами. Буду исправляться. Последнее, про что я рассказывал - быстро сделанные продукты за 7 дней в фабрике 7 days MVP и трекшен в нашем AI-туле для американских школ. В феврале я принял решение закрыть концепт 7 days MVP и изменить позиционирование студии на AI focused no-code агентство. Причины: 1. У стартаперов, как всегда, мало денег на сам продукт и на дальнейшую работу с ним. Тут ничего не изменилось. Я смирился с этим фактом и делал ставки на скорость разработки. 2. 7 дней никогда не было 7. Я называл это так с натяжкой (учитывая 2 выходных это уже 9 дней). Но 3 проекта были сделаны по факту за 12 и 13 дней. 3. После первых быстрых проектов начались MVP посложнее, в которых за 7 дней можно было успеть только дизайн и верстку максимум. Тогда мы начали продавать им несколько 7-дневок. И это превратилось в старую модель с фиксированной ценой за описанный скоуп. Почему fixed-price контракт — плохо в большинстве случаев и когда это выгодно. 1. Студия/разработчик берет всю ответственность за любые задержки в проекте на себя. Тут важно раскрыть все пункты: - Недоэстимейт. Невозможно оценить проект супер точно, если вы не делали точно такой же. Всегда есть свои новые API интеграции/уникальные дизайн элементы/логики. Любой новый опыт = умеренный рандом в части R&D. Тут можно заложить икс 5 условно, чтобы точно не вляпаться в недоэстимейт, но тогда продукт получится скорее всего не в бюджете заказчика. - Задержки от заказчика. Я про это писал ранее. Тестировал гипотезу: внести пункт контракта про задержки и попробовать сделать так, чтобы заказчик знал, что он будет платить за просрочку в днях на тестирование/приемку/задержку данных. Это не сработало. Говорить про эти штрафы = вести к эскалации. А при озвучивании это особо не влияло на скорость. В итоге ты все равно теряешь часы всей команды на ожидании какого-либо действия от клиента. - Поздно отправленные доступы/документация от заказчика. Этот пункт я отделил, потому что тут мы теряем время не только на ожидание, но и на переделки уже собранного дизайна/продукта. Например, если мы соберем БД по изначальной документации и в процессе она поменяется - добавятся сущности/связи — это добавит много часов на переделывание логик. - Ошибки в процессах студии. Заказчик за это не должен платить. Например: - не нашли/подобрали вовремя спеца - продакт поздно сделал документацию или вообще ее не сделал - спецы в расфокусе на другие проекты - мискомуникейшены в команде Пришли к недельным спринтам с включенными часами. Спринт 7 дней, 40 часов спеца + 10 проджекта. 2000$ за спринт. Эта модель решает все 3 пункта выше. Вы удерживаете ответственность за задержки клиента на нем, подсвечивая увеличение срока разработки. А также сохраняете ответственность за увеличенный срок разработки новых для вас фичей. В то же время, 4-й пункт с процессами вы можете брать на себя: Если вы проебались в процессах и, допустим, не нашли дизайнера вовремя или разработчика - вы не реализовали часы(= не посчитали их клиенту) Рекурентность. Такая модель больше похожа на подписку. Тебе не надо менять контракт/делать колл, чтобы добавлять еще недели. В контракте уже есть пункт: "указано примерное кол-во майлстоунов, их кол-во может увеличиться". Заплатили 150$ юристу за рыбу контракта: Осенью я делал контракт с GPT, но верить на 100% GPT в таком важном доке нельзя, надо коммитить с юристом. Тем более, вы делаете эту рыбу 1 раз на год и будете использовать ее для всех клиентов. - Нашел классного юриста по США праву в бизнесе - Описал свой кейс и показал, что настругал с GPT - Получил на выходе идеальный контракт за 150$ Кину контакт юриста, если кому-то надо.

Важность делать точный эстимейт и цепочка джобов: Итак, мы придумали норм бизнес-модель, сделали хорошие для нас условия в контракте, но это не решает основную джобу нас как студии для клиента. Мы защищаем себя от задержек клиента и R&D рандома на новые задачи. Но наша джоба как студии — сделать продукт, решающий джобу клиента. А у них ключевая джоба: - я хочу сделать определенного качества продукт(зависит от вида) - за икс рендж времени - в икс рендже бюджета(даже у ребят с большим бюджетам есть границы) - чтобы решить джобы x, y, z конечных юзеров Старые добрые препейменты: Да, они остаются. Мы работаем только после того, как спринт оплачен. В идеале сразу за 2 спринта, чтобы не дергать с инвойсами клиента каждую неделю. Это очень важный шаг в процессах, который нельзя проебывать. В операционке очень просто пропустить запрос инвойса майлстоуна. В случае пропуска границы контракта сдвигаются = большой риск перейти на пост-оплату, а это супер не гуд, ибо вы в зависите он настроений клиента в таком кейсе. Акты приемки Важная заключительная деталь. Он намного сильнее юридически, чем сообщения клиента в чате, что все супер. Там мы описываем реализованные фичи и потраченные на них часы. Коммитим, что клиент принимает наш репорт и не имеет к нему притензий. Когда хорошо работает fixed price контракт? Когда вы дублируете солюшен или делали супер похожий продукт с такой же технологией. Это шаг развития до SAAS с фиксированной ценой. Profit Margin должна быть в таком кейсе более 80%. Наш последний проект — идеальный пример. Мы заработали $6000 и потратили на это до 10 часов. Стоимость часа = $600 в этом кейсе. Затраты на проект = $600. Profit Margin = 90%. А еще это очень крутой сигнал связки продукта + сегмента - можно поискать такие же кейсы и затем упаковать в SAAS. Расскажу про этот проект в следующем посте!