Как запустить своё приложение, не умея программировать: от идеи до первых пользователей

На примере Kvartum: что пришлось настроить кроме самого кода — от ИИ-агента и GitHub до VPS, релизов, аналитики и первых пользователей.

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

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

Но есть нюанс: код — только одна часть продукта.

Вам всё ещё нужно сформулировать концепцию, определить рамки MVP, выбрать технологии и где-то хранить исходники. А ещё — поднять сервер, подключить базу данных, настроить релизы, аналитику и, наконец, привести первых пользователей.

Я прошёл этот путь на собственном продукте — Kvartum, сервисе для планирования и управления ремонтом. Разработку я начал примерно в начале июля. Уже через две недели работы по вечерам у меня была полноценная рабочая версия, в которой, по моей оценке, было реализовано около 75% нынешнего функционала.

А дальше скорость заметно упала. Чем больше становился продукт, тем больше времени уходило не на крупные новые функции, а на роли и права, мелкие сценарии, интерфейс, тесты, инфраструктуру и полировку. Отдельно много времени забрал планировщик. Это тоже важная часть истории: сделать первые 70–80% продукта с ИИ можно очень быстро, а последние проценты оказываются совсем не такими быстрыми.

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

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

Сначала нужна проблема, которую вы хотите решить.

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

Можно начать с простого вопроса:

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

У меня ответ появился во время собственного ремонта.

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

Так появилась идея Kvartum — собрать управление ремонтом в одном месте.

Следующий шаг — аналоги.

Кто уже решает эту проблему? Что у них сделано хорошо? Что раздражает? Чего вам не хватает? И главное: почему после появления вашего продукта кому-то вообще понадобится ещё один?

В моём случае полных аналогов оказалось немного, но отдельных инструментов для ремонта достаточно. Например, есть специализированные планировщики квартир вроде RemPlanner.

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

Оба результата полезны.

Следующая опасность — попытаться сразу построить идеальный продукт.

Не надо.

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

Для первой версии Kvartum мне было достаточно, чтобы пользователь мог:

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

В моём случае примерно за первые две недели уже работала большая часть основы продукта. Дальше каждая новая возможность стала требовать больше внимания к тому, как она влияет на всё, что было сделано раньше.

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

Дальше начинается собственно разработка.

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

Я использую Cursor. Но это не единственный вариант: похожим образом можно работать с Claude или ChatGPT.

Гораздо важнее не конкретный инструмент, а то, как вы ставите ему задачи.

Есть огромная разница между:

«Сделай калькулятор».

и:

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

Чем точнее определён объём итерации, тем предсказуемее результат.

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

Но постановка задач ИИ — отдельная большая тема. Здесь важно другое: создаём проект и дальше ведём всю разработку внутри него.

На первом этапе никакой отдельный сервер не нужен.

Код находится у вас на компьютере, а приложение запускается локально — например, через localhost.

Так начинался и Kvartum.

Фактически приложение уже работает почти как обычный сайт, только открыть его можете вы сами.

Именно здесь удобно разрабатывать первую версию, экспериментировать и ломать всё без риска для пользователей.

Даже если код пишет ИИ, совсем не понимать, из чего состоит ваш продукт, не получится.

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

Перед началом разработки я бы обязательно спросил ИИ:

В Kvartum основа — TypeScript и Next.js. Для хранения данных используется PostgreSQL.

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

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

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

Если интерфейс начинает разрастаться, полезно иметь отдельное место для работы с дизайном.

Там можно хранить используемые цвета, кнопки, состояния элементов, размеры, компоненты и общие правила интерфейса.

Иначе довольно быстро возникает классическая ситуация: пять одинаковых кнопок выглядят пятью немного разными способами.

После крупных итераций я прошу ИИ фиксировать, что было реализовано и почему.

Без огромных технических документов. Простым человеческим языком.

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

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

Поэтому я заранее задаю правила работы. Например:

У меня для этого есть отдельный универсальный промпт. Я выложил его в Telegram-канале — его можно взять за основу и адаптировать под свой проект.

ИИ умеет не только писать код, но и довольно успешно ломать то, что написал раньше.

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

Добавили новую функцию — прогнали тесты — убедились, что старые сценарии продолжают работать.

Я бы сейчас заводил GitHub практически в самом начале проекта, а не после готовности MVP.

Если сильно упростить, путь приложения от разработки до пользователя выглядит так:

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

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

В моём случае каждое проверенное локально изменение отправляется в GitHub, и уже оттуда попадает на рабочий сервер

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

То есть домен.

Выбираете регистратора, проверяете, свободно ли нужное имя, и регистрируете его.

У меня это kvartum.com.

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

Я для этого использую VPS — виртуальный сервер.

Почему именно VPS? Мне хотелось самостоятельно контролировать приложение, базу данных и остальные сервисы проекта. Это не единственный вариант размещения, но для Kvartum такой подход оказался удобным.

В Kvartum я использую Timeweb Cloud. После покупки сервера на нём нужно развернуть всё необходимое для приложения: само приложение, базу данных и другие компоненты вашего стека.

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

После этого ваш localhost окончательно превращается в настоящий публичный сервис.

Если будете повторять этот путь на Timeweb Cloud: вот моя реферальная ссылка. На момент написания статьи по условиям, которые показывает мне сервис, новый пользователь получает 300 ₽ после первой оплаты. Для моей текущей конфигурации этого хватает примерно на девять дней работы сервера. Ссылка именно реферальная — регистрация по ней учитывается как приглашение от меня.

Поначалу очень хочется делать так:

написал новую функцию → отправил на сервер → скрестил пальцы → надеюсь, ничего не сломалось.

По мере роста Kvartum стало понятно, что так продолжать нельзя: чем больше зависимостей и сценариев появляется в продукте, тем дороже обходится случайная поломка.

Поэтому я один раз определил понятную последовательность релиза.

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

После релиза автоматически формируется сообщение с содержанием новой версии.

В итоге я всегда понимаю:

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

Вот приложение опубликовано.

Теперь возникает неприятный вопрос: им вообще кто-нибудь пользуется?

Можно смотреть на регистрации вручную, но довольно быстро этого становится недостаточно.

Для Kvartum я подключил Яндекс Метрику и настроил отдельные продуктовые события: регистрацию, создание проекта, начало работы с отдельными инструментами.

Так я вижу не только количество посетителей, но и то, что они делают внутри продукта.

Потому что «на сайт зашло 100 человек» и «20 человек попробовали ключевую функцию» — это совершенно разные знания о продукте.

Отдельный источник пользователей — органический поиск.

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

В Kvartum я подключил Яндекс Вебмастер и Google Search Console, а также начал делать отдельные страницы под задачи, которые люди уже ищут.

Важно не путать это с идеей «напишем побольше SEO-текста и получим пользователей».

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

Мой минимальный набор на момент написания статьи выглядит примерно так:

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

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

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

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

Но на самом деле именно здесь и начинается продуктовая работа.

Нужно смотреть:

И вот здесь ИИ уже не даст простого правильного ответа. Придётся разговаривать с людьми, смотреть на данные и постепенно менять собственные предположения.

Я сделал к этой статье короткий чек-лист из 12 этапов — от идеи до первых пользователей. Полную версию выложу в Telegram-канале «Коваленко разбирается». Там же уже лежит универсальный промпт с правилами для ИИ-агента, который я использую как основу для своих проектов.

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

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