Содержание
- Всё началось со счёта на $600 в месяц
- Сначала — внутренний инструмент, а не стартап
- Как эксперимент стал публичным продуктом
- Все нужные функции заранее не придумать
- После первого запуска работа только начинается
- Одной модели мало
- Почему календарь сложнее, чем кажется
- Чем в итоге стал 42min
- Что я вынес из этого эксперимента
Как я навайбкодил альтернативу Calendly и довёл её до работающего SaaS
Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.
После курсов университета «Зерокодер» мне захотелось проверить вайбкодинг на чём-то настоящем: на сервисе для собственного бизнеса, с реальными календарями, пользователями и встречами. Так появился 42min. Начинался он как внутренний инструмент для отдела продаж, который тратил около $600 в месяц на Calendly, а вырос в отдельный продукт, которым пользуются чужие компании.
Всё началось со счёта на $600 в месяц
Я много лет занимаюсь SaaS-продуктами, и идея 42min пришла не из поиска ниши, а из бухгалтерии. Отделу продаж нужен был сервис для бронирования демонстраций. Команда росла, лицензий Calendly становилось больше, и в какой-то момент счёт дошёл до $600 в месяц — около $7 200 в год за один инструмент.
К Calendly претензий не было, он работал. Вопрос был в другом: процесс мы понимаем до мелочей, так обязательно ли за него столько платить? Как раз тогда я закончил курсы «Зерокодера», и хотелось применить их не на учебном задании, а на задаче, которая болит.
Вайбкодинг — это когда задачу описываешь обычным языком, а ИИ проектирует, пишет и правит код. Мне было интересно, выдержит ли такой подход не демо-страницу или бота, а сервис, который должен работать каждый день.
Сначала — внутренний инструмент, а не стартап
Повторять весь Calendly я не собирался. Нужен был минимальный, но полностью рабочий сценарий:
- Пользователь подключает календарь.
- Задаёт дни и часы, когда готов встречаться.
- Создаёт страницу бронирования.
- Отправляет ссылку клиенту.
- Клиент выбирает время, встреча появляется в календаре.
Пять пунктов. Под ними — авторизация, API календарей, проверка занятости, часовые пояса, создание видеовстреч (Zoom, Google Meet, MS Teams), уведомления.
Отдельная история — право писать в чужой календарь. Google выдаёт его только после проверки приложения: нужно записать видео, где показано, как сервис использует данные, для чего и почему нужен каждый запрошенный доступ. С их отказами и моими исправлениями все нужные разрешения я получал три недели.
До версии, которой уже могли пользоваться мои сотрудники, ушло около десяти дней: я описывал требования и сценарии, Claude Design собирал интерфейсы, Claude Code — всю серверную логику и интеграции. Но быстро выяснилось, что быстрый код и хороший продукт — разные вещи. ИИ делает то, что сформулировано. Он не решает, что на самом деле нужно пользователю, и не отвечает за архитектуру, безопасность и за то, что будет с сервисом после запуска. Это по-прежнему моя работа.
Стек тоже предложил Claude: NestJS, Prisma, Postgres, всё в Docker на одном VPS. Но перед стартом я показал его паре знакомых бэкендеров, а заодно Gemini и ChatGPT. Второе и третье мнение при закладке фундамента обязательно.
Как эксперимент стал публичным продуктом
Первыми пользователями стали мои же сотрудники: они проводили через 42min настоящие встречи, а я смотрел, как сервис ведёт себя в живых процессах, а не в тестах.
Потом я предложил попробовать друзьям в их компаниях. Они подключили календари, сделали страницы бронирования и поставили ссылки на сайты. И тут заработал простой механизм: каждая ссылка попадает к клиентам, партнёрам, участникам встреч. Кто-то из них интересуется, что это за сервис, и заводит свою страницу. Её видят следующие люди. Так 42min ушёл за пределы моего круга без всякой рекламной кампании.
Довольно скоро набралась первая сотня реальных подключений: страниц бронирования на живых сайтах, через которые идут настоящие встречи. Это важнее числа регистраций. Зарегистрироваться из любопытства может кто угодно, а тот, кто подключил календарь и повесил ссылку на сайт, доверил продукту кусок своего бизнеса. С этого момента 42min перестал быть учебным проектом.
Все нужные функции заранее не придумать
Идеальное ТЗ, в котором предусмотрено всё, написать нельзя. Пока продуктом не пользуются живые люди, основатель видит только свой предполагаемый сценарий. Реальные пользователи всегда делают чуть иначе.
Поэтому почти всё новое в 42min пришло из обратной связи. Люди рассказывают, где неудобно, какого сценария нет, в какой момент привычный процесс ломается. Иногда прямо просят функцию. Иногда описывают проблему, и правильное решение оказывается совсем не тем, что они предлагали.
Так продукт ушёл далеко от простой записи один на один. Сейчас в 42min есть:
- групповые встречи с несколькими участниками;
- round robin — автоматическое распределение встреч между сотрудниками;
- формы маршрутизации: человек отвечает на пару вопросов и попадает к нужному сотруднику или типу встречи;
- опросы для выбора времени, удобного нескольким людям;
- автоматические напоминания и письма после встречи;
- интеграции с календарями и сервисами видеосвязи;
- API и webhooks, чтобы встраивать бронирования в другие процессы;
- несколько языков и часовые пояса.
Но слушать пользователя не значит делать всё, что он просит. За конкретной просьбой нужно найти общую проблему и проверить, есть ли она у других: одна просьба — частный случай, несколько похожих — системная потребность.
После первого запуска работа только начинается
Какая самая частая ошибка начинающего вайбкодера? Считать, что раз приложение запустилось, значит, готово. По моим наблюдениям, почти все новички смотрят только на видимую часть: страница открылась, кнопка нажимается, основной сценарий проходит. О логах, мониторинге, обработке ошибок и безопасности на этом этапе почти никто не думает.
А между «у меня заработало» и «этим могут надёжно пользоваться другие» лежит пропасть. Пользователь нажимает кнопку и видит «успешно», хотя фоновая задача упала. Календарь синхронизируется почти всегда, но ломается после отзыва разрешения или истечения токена. Письмо сформировано, но не доставлено. Ошибка с часовым поясом вылезает только у пользователей одной страны и только в неделю перехода на летнее время.
Без логов об этом не узнаешь. Пользователь просто решит, что сервис ненадёжный, и уйдёт. Поэтому после запуска я обязательно смотрю:
- где и при каких условиях падают ошибки;
- какие фоновые задачи не завершились;
- проходят ли синхронизации с внешними сервисами;
- на каком шаге люди бросают первоначальную настройку;
- какие функции используются, а какие только нарисованы на экране;
- возвращаются ли люди после первой встречи.
Для логов у меня отдельная подсистема: она собирает ошибки nginx, почты, Redis и Postgres, разбирает их и по критическим сразу шлёт мне алерт. Снаружи за сервисом следит Grafana.
Логи показывают то, что пользователи не умеют описать. Обратная связь объясняет то, чего не видно в логах. Только вместе они дают честную картину.
Одной модели мало
У сгенерированного кода есть особенность: модель плохо замечает собственные ошибки (даже если вы делали на Fable Ultracode и потратили все свои лимиты). Попросишь её проверить только что написанное решение в том же контексте — она повторит те же допущения и не увидит слабое место.
Поэтому в 42min я развожу роли между моделями. Одна предлагает и реализует решение (в моём случае это Claude Code, в зависимости от задачи Opus или Fable), другая получает задачу провести независимое код-ревью (Codex Sol): найти пограничные случаи, проверить архитектуру, поискать уязвимости. Это как в обычной команде: автор кода не должен быть его единственным ревьюером. Вердикт второй модели тоже не истина в последней инстанции, найденное надо проверять тестами и на живой системе. Но независимый взгляд регулярно ловит то, что пропустила первая. Иногда прошу мнение у Gemini, но редко: мне не нравится, как он делает ревью кода. Зато он хорош для новых идей на этапе ТЗ.
Отдельная постоянная тема — безопасность. Одного аудита перед запуском мало: продукт меняется, появляются функции, зависимости, интеграции, права доступа, и любое изменение может открыть дыру. Особенно внимательно я проверяю:
- разграничение доступа между пользователями и организациями;
- можно ли через API получить или изменить чужие данные;
- хранение токенов календарей и других секретов;
- входящие webhooks и внешние запросы;
- зависимости и обновления библиотек;
- SQL-инъекции и другие классические уязвимости;
- обработку пользовательского HTML и любого ввода.
Вайбкодинг ускоряет написание кода. Ровно так же он ускоряет появление небезопасного кода, если публиковать всё сгенерированное без проверки. Поэтому аудит и независимое ревью у меня — это обязательная часть процесса, а не разовый этап.
Почему календарь сложнее, чем кажется
Сервис записи выглядит идеальной задачей для первого AI-проекта. На практике настоящий продакшен начинается очень быстро.
Пользователи сидят в разных часовых поясах. В разных странах переводят часы в разные дни, а где-то не переводят вообще. У одного человека может быть несколько подключённых календарей. Два клиента могут почти одновременно занять один слот. Внешний API отвечает с задержкой или лежит. Пользователь переносит встречу прямо у себя в календаре, минуя сервис.
ИИ хорошо реализует стандартный сценарий. Реальные люди создают тысячи нестандартных сочетаний, о которых никто не подумал в первом промпте. Поэтому ценность продукта не в количестве функций, а в том, насколько быстро команда — даже если это один человек с AI-инструментами — замечает исключения и чинит их.
Чем в итоге стал 42min
Сегодня 42min — самостоятельная платформа для планирования встреч, но принцип с самого начала один: расширенные функции не должны быть недоступны небольшой компании только потому, что у неё нет бюджета на корпоративный тариф. Поэтому то, за что другие сервисы просят перейти на старший план или платить за каждого сотрудника, в 42min доступно бесплатно.
Я не утверждаю, что молодой продукт уже лучше зрелого конкурента во всём. У Calendly бренд, экосистема и годы опыта. У 42min другое преимущество: он быстро меняется, слышит первых пользователей и строится вокруг сценариев, за которые небольшие команды у других сильно переплачивают.
Что я вынес из этого эксперимента
Начинать стоит с реальной и достаточно дорогой проблемы. Счёт на $600 в месяц мотивирует лучше, чем идея «сделать какой-нибудь SaaS»: есть понятная задача и способ проверить, приносит ли новое решение пользу.
Вайбкодинг радикально удешевляет проверку гипотез, но не заменяет понимание продукта. Описывать нужно не экран и кнопку, а весь сценарий, ограничения и поведение при ошибках.
И главное: продакшен требует дисциплины независимо от того, кто написал код. Мониторинг, тесты, бэкапы, независимое ревью и регулярные аудиты безопасности нужны AI-продукту так же, как приложению, которое команда писала годами.
Для меня проект доказал, что вайбкодинг годится не только для прототипов — на нём можно построить настоящий SaaS и выйти с ним на давно сложившийся рынок. Но самое ценное оказалось не в скорости написания кода, а в том, что происходит после запуска: слушать клиентов, читать логи, проверять безопасность и превращать каждую найденную проблему в следующую, чуть более надёжную версию.