Писал пост про ценности No-code, и обнаружил интересный парадокс.

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

Увидели? Заказчик платит меньше, а исполнители получают больше. Как такое возможно?

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

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

Над этим мы и работаем.

а есть еще те для кого
3. Получить свой вебсервис в котором можно вносить изменения за пару минут
(я вот сам не ставя тз айтишнику вносил изменения на этой недели каждый день почти, при этом у меня есть и другой сервис на коде на движке moodle, на котором сидят все универы в рф, в котором части тз я не могу дождаться от кодера уже с декабря)

Мы учимся на чужих ошибках

Конструктор Bubble недавно изменил принцип образования цен. Это уже вторая их попытка (первая была год назад). Обе попытки сообщество восприняло очень негативно, потому что это не просто подорожание, а именно изменение принципа, при котором некоторые проекты могут начать стоить в разы дороже.

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

Мы выбирали между двумя принципами образования цен:

Первый, когда мы считаем выполнение каждой операции, количество строк в базе данных поштучно, как это сделано в Make (ранее Integromat) и как это работает у нас на сайтах сейчас.

Второй, когда мы каждому клиенту выделяем определенноге количество ресурсов (процессор, память, диск, сеть и т.д.), в рамках которых клиент делает что хочет, и вокруг этого строим экономику.

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

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

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

Другими словами, можно будет делать проекты с большой нагрузкой и не бояться, что эта нагрузка приведет к неадекватным ценам. Можно будет масштабировать проекты до бесконечности, оплачивая только стоимость лицензии и сервер (свой или в нашем облаке).

Важно отметить, что все что я пишу про цены тут - это именно к приложениям относится, а не к сайтам.

Сайты ≠ Приложения!

Весь текущий функционал останется рабочим - интеграции с Google таблицами, Make, Directual и так далее. Работа с пользователями на сайтах в текущем виде - все это будет продолжать работать.

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

Другими словами, скоро в личном кабинете появится разделение по типам проектом: сайты (текущий функционал, текущие цены) и приложения (новый функционал, новые цены).

Я записался на курс по питчингу и бизнес-английскому. Английский у меня есть на уровне B1-B2, но я никогда не презентовал свой проект инвесторам.

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

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

Зачем нам вообще инвесторы?

У нас хорошо идут дела как в России, так и на Creatium International. Мы растем и там и там, несмотря ни на что. У нас есть определенная репутация, и многие нас знают. Мы окупаем свои расходы, и даже в чате почти не пишут “а вдруг вы загнетесь”, как это было несколько лет назад, как только мы запускались.

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

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

Поэтому и думаем об инвестициях, чтобы был хороший старт на новом рынке.

Новая версия старого мема.

Попытка установить верную цену для нового продукта - это ад.

1. Сделать бесплатно - остаться без средств на развитие и вообще на жизнь.
2. Сделать дешево - не построить экономическую модель нормально.
3. Сделать дорого - лишить себя большого количества “маленьких" клиентов.
4. Сделать средне - а сколько это вообще "средне”? Ответы разные будут.
5. Модель “плати сколько хочешь” - не работает, проверено (не нами).
6. Бесплатно для некоммерческого использования - будут использовать для коммерческого.
7. Бесплатно для личного, платно компаниям - то же самое.

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

Исключения есть, но это ошибка выжившего.

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

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

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

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

Иногда это доходит до абсурда. На Cloudflare если ты купил домен, то собственные NS сервера указать можно только на тарифе за $250. И кстати, у компании дела идут отлично.

Creatium - ошибка выжившего?

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

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

Первым был LPGenerator, который казался мне большой компанией, с которой я и не думал конкурировать, потому что мы маленькие и на многое тогда не претендовали. Потом пришли наши первые клиенты и сказали, что мы лучше. Из-за внутренних конфликтов LPG перестал развиваться. Ходят слухи, что там все еще есть живые пользователи.

Еще был конструктор Spagece, который потом переименовался в Bloxy. Они несколько раз полностью переписывали весь функционал, и может быть это их погубило, а может быть что-то другое. Мы даже обсуждали возможность слияния их с Платформой LP, но этого не случилось. Сейчас у них даже сайт не работает.

Примерно в одно время с нами запускались коснтрукторы LPTrend, Borstch, которые тоже остались в прошлом.

Еще помню БМ Пулю, которую хорошо продвинули в Бизнес Молодости, и мне казалось, что с такой поддержкой у них все будет просто прекрасно.

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

Я не злорадствую. Я все эти продукты считал сильными и перспективными. Просто я не всегда понимаю, почему мы выжили, а они - нет. Иногда думаешь: “вот у них классно, а у нас не очень”. А потом видишь как эти “они” закрываются. Это очень странно, и каждый раз удивляет меня.

Хотели бы вы, чтобы Creatium купила большая компания?

У нас пока нет предложений, просто интересно мнение. С одной стороны может быть больше ресурсов на развитие, с другой - фокус развития может измениться.

Вчера было 720 подписчиков, сегодня 745. Никакой активности не было, репостов вроде бы тоже.

Откуда эти 25 подписчиков, может кто знает? Боты? Инвесторы?

Для новых подписчиков расскажу, что тут происходит, и что мы делаем.

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

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

Мы хотим увеличить процент “выживших” и успешных компаний. Для этого мы модернизируем конструктор сайтов Creatium и на его основе делаем No-code платформу для разработки полноценных MVP, таких как маркетплейсы, личные кабинеты, соц-сети и так далее, любые проекты с личным кабинетом.

Ключевая ценность - быстрый Time-to-market, чтобы тестировать больше идей, запуская рабочие MVP с функционалом и приемом платежей от пользователей (подписка, разовые платежи, любая другая логика). Больше идей проверили - больше шансов найти “ту самую”.

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

Возможности не ограничены одним MVP, если ваша идея “выстрелит”, вы можете его развивать до полноценного продукта, не покидая платформу. Она построена так, чтобы выдерживать большие нагрузки (результаты стресс-тестов будут позже). Безопасность персональных данных тоже учли.

Сейчас все в бета-версии, из которой мы планируем выйти в начале лета.

Как мы пришли к No-code

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

Но в какой-то момент количество “хотелок” становится таким, что понимаешь, что реализовать все это невозможно.

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

Стало понятно, что подход “просто добавлять больше функций в конструктор” приводит к тому, что требований становится только больше.

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

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

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

Масштабируемая No-code платформа

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

Но что если посетители выражают умеренный интерес, но когда вы даете им рабочий продукт, этот интерес пропадает, и они не платят?

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

Решение - рабочий прототип, MVP, собранный на коленке. Требования следующие: (1) прототип должен быть собран быстро, (2) он должен иметь рабочий функционал и (3) он должен брать деньги за этот функционал, чтобы проверить спрос.

С этого набора требований мы и начинали 2 года назад, когда сделали связку Creatium + Google Таблицы + Integromat. Даже несмотря на то, что задержка в обновлении данных была несколько секунд, оно работало и давало результаты.

Правда тот факт, что больше, чем MVP на тот момент сделать было нельзя, многих клиентов огорчал, и останавливал - потому что в случае успеха проект пришлось бы переделывать в коде, чтобы он работал быстро.

Получив обратную связь, мы начали разработку новой версии Creatium, которая помимо указанных требований выше, включала бы:
(4) Высокую скорость работы (операции выполняются за милисекунды)
(5) Отказоустойчивость (один сервис вместо трех)
(6) Защиту персональных данных (полный контроль, где что хранится, тариф с self-hosted)
(7) Масштабируемость (работа с сотнями тысяч и миллионами строк в базе данных)

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

Если я верно оцениваю, то наш новый рынок просто огромный. Это весь рынок заказной разработки всего, что “сложнее чем просто сайт”. И нам есть, что предложить этому рынку.

13 человек делают SaaS на Creatium

Хотя это и наименее “популярный” пункт согласно результатам голосования, он хорошо показывает, что наши усилия по модернизации конструктора не проходят даром.

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

Потребовалось с нуля разработать собственный движок сценариев, язык формул, благодаря которым можно делать сложную логику.

В итоге мы видим голоса за пункт “SaaS”.

Помните, я писал что записался на курс по питчингу?

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

Если мы будем говорить про базы данных, сценарии и формулы - нас не поймут. Нужен другой язык. Что с того, что у нас все это есть? Что с того, что классическая разработка дорога? Если человек с этим не сталкивался, то ему должно быть безразличо, что у кого-то там что-то дорого и медленно.

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

Ведь самое важное для любой новой компании - найти Product-Market fit, или по-русски “Соответствие продукта рынку”. Это когда продукт соответствует требованиям на рынке, его готовы покупать.

Что нужно, чтобы найти этот Product-Market fit? Тестировать разные идеи. Адаптировать продукт под изменения на рынке, быть гибкими и быстрыми, проверить максимальное количество гипотез, пока не кончились все деньги. С этим мы и помогаем.

Возможно, это не последний вариант, но он определенно мне нравится. И его можно объяснять без этих всяких “Product-Market fit”, “MVP” и так далее - простыми словами.

No-code и AI

Это 2 современные технологии, которые некоторое время назад начали пересекатсья. No-code показал, что можно разрабатывать и без кода, а AI показал, что можно код писать просто запросами.

К сожалению, достоверно неизвестно, есть ли пределы мощностей у AI. Будет ли у нас через 10 лет какой-нибудь GPT 8, который просто по текстовому описанию проекта будет задавать правильные вопросы, на основании которых уже генерировать проект целиком - неизвестно.

Неизвестно так же когда появятся достойные аналоги GPT, которые можно использовать в РФ.

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

Не зовется использовать ИИ только чтобы говорить, что мы используем ИИ. Хочется найти максимально эффективное и эффектное примененние.

Понимаю, что тут про ноукод а не программирование, но среди нас есть и программисты тоже.

Кто-нибудь уже пробовал Kotlin Multiplatform? Есть отзывы? Сравнение с Flutter, React Native?