Сохраняй посты, комментируй и ставь оценки
Пожалуйста, зарегистрируйтесь или авторизуйтесь для просмотра содержимого данного поста.
ХЕО POD имеет 20 встроенных динамиков, и сидящий в нем человек оказывается окружен музыкой.
Знакомец открыл, скажем так - бизнес.
Дело в том, что он работает кузнецом - ограды там и прочее.
Так вот, поселился он в новую квартиру - новостройку и по традиции, видимо известной ему одному вбил в косяк двери входной небольшой кованный гвоздь, на который по наущению своей бабки нашептал, какие-то слова.
За этим делом его застал сосед - врач (!) и расспросив, захотел себе такой-же. Этот мужик сделал ему такой-же и понеслось! Сарафанное радио в действии.
Начал ковать их на работе в свободное время, из обычных обрезков арматуры. Берут по 150 - 500 рублей. Зависит от формы и размера, наличию узоров и прочее.
В месяц десяточку с этого дела в карман себе кладет.
Больше всего, конечно берут, как декоративный элемент, но тем не менее...
Такие дела.
Пы.Сы. Честно шепчет над каждым гвоздем заветные слова.
Текст изначально был опубликован в моем авторском блоге: https://zen.yandex.ru/media/evhrustalev/kak-mujik-znakomyi-z...
У любого проекта должен быть сайт. Даже если единственный пользователь — моя мама.
Мама — это идеальный QA: откроет с телефона, в дороге, через мобильный интернет, спросит «а почему замочек не зелёный?» и закроет, если что-то долго грузится. Значит, сайт должен открываться по твоему красивому домену, по HTTPS, без рыжих предупреждений, и желательно находиться в поиске.
В этой статье мы за вечер соберём и задеплоим простой сайт «с нуля» почти бесплатно: купим домен, поднимем машину с публичным IP, обернём всё в Docker, прикрутим автопродление SSL, добавим sitemap.xml и robots.txt, и вручную прокинем сайт в индексацию Google и Яндекса, чтобы он не лежал «в вакууме».
По шагам:
В конце — у тебя домен с «замочком», сайт открывается на телефоне у мамы, а поисковики знают, что ты существуешь.
Проблематика (что обычно ломается)
Первое, что нужно любому сайту, — свой адрес в интернете.
Я обычно беру домены на reg.ru, потому что у них простой интерфейс и быстрая регистрация. Но по факту — можно использовать любой регистратор, хоть GoDaddy, хоть Namecheap, хоть вашего локального провайдера.
Процесс простой:
💡 Лайфхак:
Отказываемся от всех «дополнительных услуг» — конструкторы сайтов, «хостинг за 1 рубль», SEO-пакеты и прочий мусор. Это почти всегда платные подписки, которые через месяц начнут жечь бюджет.
В итоге у нас в руках домен, например:
Дальше будем учить его показывать наш сайт и радовать маму зелёным замочком.
Чтобы сайт был доступен маме в любое время суток, нам нужен компьютер, который:
Если у тебя дома стоит ПК, который никогда не выключается (например, твой старый системник или мини-сервер), можно попросить у интернет-провайдера выделенный статический IP.
У меня такая услуга стоит ~200 ₽/месяц, у тебя может быть чуть дороже или дешевле.
Но надо заморочиться с локальной сетью, пробросом портов и динамическим DNS. Но для нашей задачи это лишняя головная боль — главное, чтобы в итоге у нас был:
Я чаще всего беру VPS на serverspace — самая дешёвая конфигурация там обходится примерно в 400 ₽/месяц. Это дороже, чем дома, но зато:
📌 На этом этапе у нас уже есть:
Дальше — ставим Docker и готовим окружение.
🐳 Шаг 3. Ставим Docker и Docker Compose
Почему я люблю Docker?
Потому что всё окружение можно описать декларативно: база, сервер, сервисы — всё в одном docker-compose.yml. Один файл — и твой проект можно поднять на любой машине за пару минут.
Для нашей цели нам нужен только Docker Engine и Docker Compose plugin.
Ниже — команды для Ubuntu 24. Если у тебя другая версия или дистрибутив, просто загугли:
how to install docker-compose <название_твоей_системы>
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
После этого выйди из сессии SSH (exit) и зайди снова. Теперь можно писать docker ps, а не sudo docker ps.
Пора навести порядок и подготовить инфраструктуру, которая сможет работать на любом сервере с Docker.
В корне создаём папку sites и внутри неё такую структуру:
sites/
├─ docker-compose.yml
├─ nginx/
│ ├─ debugtest.conf # конфиг nginx для сайта
├─ site/ # твои статические файлы
│ ├─ index.html
│ ├─ sitemap.xml
│ └─ robots.txt
└─ certbot/
├─ conf/ # здесь появятся сертификаты (том для /etc/letsencrypt)
└─ www/ # временные файлы для валидации домена
Команды для Linux:
mkdir -p sites/nginx sites/site sites/certbot/conf sites/certbot/www
touch sites/site/index.html
Для редактирования текстовых файлов можно использовать nano:
nano sites/site/index.html
(Если ты используешь vim, то, скорее всего, и так не читаешь этот гайд 😉)
Файл docker-compose.yml (в папке sites) будет выглядеть так:
services:
nginx:
image: nginx:1.27-alpine
container_name: speech_nginx
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx:/etc/nginx/conf.d/:ro
- ./certbot/www:/var/www/certbot/:ro
- ./certbot/conf/:/etc/nginx/ssl/:ro
- ./site:/var/www/html/site
restart: unless-stopped
certbot:
image: certbot/certbot:latest
container_name: speech_certbot
volumes:
- ./certbot/conf:/etc/letsencrypt
- ./certbot/www:/var/www/certbot
entrypoint: /bin/sh
# будем запускать вручную:
# docker compose run --rm certbot ...
server {
listen 80;
server_name debugtest.ru www.debugtest.ru;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
root /var/www/html/site;
try_files $uri $uri/ /index.html =404;
}
}
site/sitemap.xml:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://debugtest.ru/</loc>
<lastmod>2025-08-12</lastmod>
<changefreq>monthly</changefreq>
<priority>1.0</priority>
</url>
</urlset>
site/robots.txt:
User-agent: *
Allow: /
Sitemap: https://debugtest.ru/sitemap.xml
📌 Теперь у нас есть:
Дальше — будем ставить SSL и запускать всё это добро.
Наша цель — чтобы мама открыла https://debugtest.ru и увидела зелёный замочек, а не красное «Небезопасно».
Для этого используем бесплатные сертификаты от Let’s Encrypt и встроим их в наш Docker-стек.
Переходим в папку с docker-compose.yml и стартуем контейнеры:
docker compose up
Пока без -d, чтобы видеть логи и убедиться, что Nginx поднялся без ошибок.
Открываем вторую SSH-сессию к серверу и там выполняем тестовый запуск certbot:
docker compose run --rm certbot certonly \
--webroot --webroot-path /var/www/certbot/ \
--dry-run \
-d debugtest.ru
--dry-run — это проверка. Certbot не выпустит реальный сертификат, но убедится, что домен доступен и валидация проходит.
Если dry-run прошёл без ошибок — запускаем команду без --dry-run:
docker compose run --rm certbot certonly \
--webroot --webroot-path /var/www/certbot/ \
-d debugtest.ru
После этого в папке certbot/conf/live/debugtest.ru/ появятся файлы сертификатов.
Файл nginx/debugtest.conf теперь будет выглядеть так:
server {
listen 443 ssl;
server_name debugtest.ru;
ssl_certificate /etc/nginx/ssl/live/debugtest.ru/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/live/debugtest.ru/privkey.pem;
location / {
root /var/www/html/site;
try_files $uri $uri/ /index.html =404;
proxy_set_header Host $host;
client_max_body_size 3G;
proxy_set_header X-Forwarded-Proto https;
}
location = /sitemap.xml {
root /var/www/html/site;
try_files /sitemap.xml =404;
}
location = /robots.txt {
root /var/www/html/site;
try_files /robots.txt =404;
}
}
docker compose down
docker compose up -d
Открываем https://debugtest.ru — должен быть зелёный замочек.
Если всё ок, значит мама сможет зайти на сайт без предупреждений.
💡 Про автопродление
Сертификаты Let’s Encrypt живут 90 дней. Чтобы не бегать руками, добавь в crontab:
0 4 * * * docker compose run --rm certbot renew && docker compose kill -s SIGHUP nginx
Это проверит сертификат каждый день в 4 утра и перезапустит Nginx, если сертификат обновился.
Поисковики не телепаты. Даже если твой сайт уже крутится с идеальным SSL и sitemap.xml, Google и Яндекс могут заметить его через недели.
Мы ускорим этот процесс вручную.
💡 Лайфхак: сразу после добавления sitemap.xml можно зайти в Проверка URL и вручную «Запросить индексацию» главной страницы. Это ускорит попадание сайта в выдачу.
📌 Теперь твой сайт:
💬 Если тебе зашёл этот формат и ты хочешь видеть больше таких разборов, у меня есть Telegram-канал, где я делюсь своими пет-проектами, экспериментами, идеями для стартапов и многим другим.
Ссылка на канал — в моём профиле.
Builder.ai - лондонский стартап, основанный в 2012 под названием SD Squared.
На старте - обычная студия, делали сайты и мобилки под заказ.
Позже ребрендились в Engineer.ai, а потом в Builder.ai, чтобы звучать больше как платформа.
Идея:
"Выбираешь фичи - а мы собираем тебе приложение, как конструктор.
Быстро, дёшево, с ИИ."
По сути — Shopify + Tilda, но под мобилки.
Скорость, автоматизация, "интеллектуальный сборщик фич", ИИ-ассистент Наташа и всё такое.
Все эти заявления выглядели красиво.
Проблема - почти всё оказалось враньём или преувеличением.
Инвесторы: Insight Partners, Jungle Ventures, WndrCo и др.
2016–2018: была обычная студия, клепали сайты и приложения.
Поняли, что на этом инвесторы не разогреваются.
→ Переименовались в Engineer.ai
→ Придумали фейкового "ИИ-ассистента" Наташу
→ Заявили про 32 000 инженеров в сети
→ Подняли $29M в раунде А
2018–2023: по их словам, 82% кода делал ИИ - и за первый час.
WSJ немного удивился, разобрался и выяснил:
всё писали руками.
Компания переименовалась, сделала вид что всё ок - и пошла за новыми деньгами.
2021–2024:
Financial Times выкатил материал:
доходы завышены в 4 раза
(отчёт — на $220M, по факту — $55M)
Май 2025:
Компания жгла по $10M в месяц.
Платили за отчёты, которые рисовали на коленке.
Кредиторы закрутили гайки → банкротство.
Наняли нового CEO, чтобы он красиво всё признал.
История не про технологию.
А про то, как работает рынок: говоришь «ИИ», зовёшь Наташу, и вот ты уже единорог.
Вспоминается:
📌 Я такие истории собираю и разбираю у себя в канале - всё, что касается ИИ, стартапов, микро-проектов и цифровой паранойи.
Если интересно - залетай посмотреть. 🔗Ссылка - в профиле.
Стартап Jetson решил устроить гонки на своих дронолётах Jetson One:
Заявленные характеристики:
Вес пустого - 55 кг.
Вес с Аккумуляторами - 115 кг.
Грузоподъёмность (вес пилота) - 95 кг.
Размеры - 270х160х112 см.
Ширина в сложенном виде - 98 см.
Примерное время полёта - 20 мин.
Максимальная скорость программно ограничена в 102 км/ч
Потолок - 450 м.
Имеет 8 безщёточных эл. двигателей (отказ одного не приводит к аварии).
Резервирование литий-ионной батареи.
Система автоматического приземления.
Управление - 4х осевой джойстик.
Полностью алюминиевый каркас (фюзеляж).
Есть спасательный парашют (для всего дрона)
Не требует лицензии пилота в США.
До конца 2025 года планируют выпустить около 200 летательных аппаратов.
Сейчас принимают заказы по цене 128 000$ с поставкой через 2 года.
З.Ы. Забавная игрушка для богатых, однако.
Калифорнийская компания Vast Space, которая планирует развернуть на околоземной орбите собственный аванпост под названием Haven-1 в августе 2025 году, показала прототип структуры своей одномодульной космической станции.
Модуль Haven-1 представляет собой структуру 10 метров в длину и три метра в диаметре. На орбиту его доставит ракета Falcon 9 компании SpaceX.
Вскоре после запуска орбитальная станция сможет принять четырех космических туристов в рамках 30-ти дневной экспедиции Vast-1. Первый экипаж прибудет на станцию на космическом корабле SpaceX Dragon.
Студенты МФТИ из стартапа «Мэтрикс Вейв» 22-23 ноября 2023 года представят на площадке Всероссийского форума технологического предпринимательства инновационные абонентские терминалы для новых спутниковых группировок связи, основанные на метаповерхностях. Эта технология обещает стать более дешевым аналогом терминалов связи популярной системы Starlink Илона Маска.
Стартап получил поддержку в рамках Федерального проекта «Платформа университетского технологического предпринимательства» и участвует в деловом мероприятии форума «Питч по-взрослому».
«Основным преимуществом абонентских терминалов на основе метаповерхностей является их существенно более низкая стоимость, а также возможность полной локализации производства. Это позволит активно применять новую разработку для нужд народного хозяйства, научных экспедиций, работ в отдаленных районах, включая районы Крайнего Севера, на морских и воздушных судах, а также для борьбы с чрезвычайными ситуациями», – рассказал Алексей Космынин, руководитель стартапа «Мэтрикс Вейв».
Представители стартапа сообщили о планах провести первичный сеанс связи через собственный терминал в 2024 году. Планируется также масштабирование технологии для ключевых существующих и развертываемых спутниковых сетей в Российской Федерации с перспективой выхода на рынки дружественных стран. Кроме того, уже имеются письма заинтересованности от большинства вендоров и ключевых игроков в области новых спутниковых систем связи, включая ведущие национальные космические программы.
Как отмечают разработчики, использование новых абонентских терминалов в составе перспективной Российской орбитальной группировки, например, спутниковой сети «Сфера», анонсированной Роскосмосом, позволит значительно расширить доступ к широкополосному интернету и коммуникациям в удалённых и труднодоступных районах.
«Это открывает новые возможности для развития технологий, экономики и общества в целом. Беспилотный транспорт, качественный интернет во время полета в самолете, интернет вещей, доступ к государственным сервисам и связь из любой точки мира и многое другое»
На сегодняшний день в Российской Федерации присутствуют вся необходимая линейка ракетоносителей и головных обтекателей полезной нагрузки для группового запуска спутников космического интернета. Услугами Роскосмоса уже пользовался британский проект OneWeb. Его спутники были выведены на орбиту ракетоносителями семейства Союз c разгонным блоком Фрегат-М. Ленточная система отделения космических аппаратов позволяет выводить на заданные орбиты спутники с чувствительным научным оборудованием.
No-code выглядит соблазнительно.
Не надо учиться кодить. Разработчики не нужны. Накликал интерфейс - и запускай единорога.
Звучит красиво.
А на деле - быстро превращается в болото.
Недавно видел пример: ребята сделали приложение для изучения испанского языка на no-code.
Через месяц им пришлось переписать всё на код.
Причина простая - костыли.
И это не открытие. Я ещё лет десять назад видел такие штуки.
Delphi, Microsoft Access, Lotus Notes, позже Oracle APEX — там тоже можно было натыкать кнопочек, набросать интерфейс, и оно даже работало.
Но стоило захотеть что-то серьёзнее - и упираешься в потолок платформы.
В итоге такие проекты либо переписывают, либо бросают.
No-code повторяет ту же историю.
Хочешь добавить функцию - нельзя. Делаешь костыль.
Хочешь ещё - снова костыль.
Через месяц костылей так много, что проект перестаёт развиваться.
Да, есть исключения. Специализированные инструменты работают классно.
Тильда для лендингов. Airtable для таблиц. Retool для дашбордов.
Но это не «замена программистов», а «ускоритель для специалистов».
А универсальные конструкторы «сделай любое приложение без кода» - это мираж.
Ты вроде строишь продукт, а на деле собираешь небоскрёб на болоте.
Я сам часто запускаю проекты и пишу про эти попытки, удачные и не очень.
Так что тема no-code для меня не теория, а наблюдения из практики.
Инди‑разработчик одновременно пишет код, рисует иконки, настраивает аналитику и считает, хватит ли выручки, чтобы дожить до следующего релиза. В голове при этом орут шесть голосов — от художника‑перфекциониста до паникёра, который шипит: «не лезь в серяк, всё сломаешь». Недавно я это сполна почувствовал, когда на финальной прямой запуска моего расширения для Chrome под Европу Google заблокировал рекламный кабинет — весь запуск был заточен под поисковый трафик, и в один момент канал просто исчез.
Расширение жило за счёт идеи: забираем тёплый поисковый трафик из Google Ads, ведём на продукт, дальше монетизируем. Аудитория — Европа, так что нормальной альтернативы Google по объёму и качеству трафика, по сути, нет. На финальной части запуска, когда оставалось включить бюджеты и смотреть на конверсии, рекламный кабинет схлопнулся по политике: без внятных объяснений, с размытыми формулировками и стандартной отпиской.
В голове мгновенно нарисовались четыре сценария:
И вот тут во мне в полный голос заговорили все внутренние персонажи — от паникёра до художника. Чтобы не принимать решение «на ощущениях», я вытащил метод шести шляп.
Метод шести шляп — это техника Эдварда де Боно, где мышление делится на шесть режимов: факты, эмоции, риски, выгоды, креатив и модерацию. Вместо того чтобы держать всё в голове одновременно и метаться, ты по очереди «надеваешь» шляпы и смотришь на одну и ту же ситуацию под разными углами.
Для инди‑разработчика это особенно полезно: обычно решения принимает либо внутренний паникёр (чёрная шляпа), либо вдохновлённый художник (зелёная/красная), а белая и жёлтая — факты и выгоды — просто молчат.
Классика такая:
Ниже — как я разобрал свою блокировку Google Ads по этим шляпам.
Сначала — сухие факты без истерики.
На этом этапе задача — увидеть реальность без «всё пропало» и «да нормально, сейчас разбанят».
Здесь вообще не нужен рационал — только то, что ощущается.
Смысл — признать, какие решения ты принимаешь просто из страха или обиды, чтобы потом не маскировать это под «рациональный выбор».
Дальше — максимально пессимистичный взгляд на каждый сценарий.
Чёрная шляпа нужна, чтобы честно увидеть, где ты можешь потерять больше, чем готов.
Теперь тот же список, но с вопросом «что здесь может пойти хорошо?».
Жёлтая шляпа возвращает понимание, что в каждом сценарии есть не только «помереть», но и «выиграть» — вопрос цены и горизонта.
Здесь цель — не выбирать между A/B/C, а придумать C1, C2, D.
Например:
Зелёная шляпа — это место, где из «всё или ничего» появляется несколько ступеней и промежуточных экспериментов.
На этом этапе я собрал всё выше в конкретный план.
Что решил:
Какие метрики для себя отметил:
Синяя шляпа — это момент, когда ты перестаёшь бесконечно «думать» и признаёшь: да, это не идеальное решение, но это проверяемый эксперимент с понятными правилами и горизонтом.
Если у тебя сейчас:
Когда начал прогонять через шляпы не только монетизацию, но и такие аварийные ситуации, стало заметно, что во мне чаще всего орёт чёрная шляпа (паникёр) и иногда красная (обида/страх), а факты и выгоды просто не доходят до стола.
Если тебе заходит формат разборов решений инди‑разработчика (с цифрами, факапами и рабочими фреймворками), залетай в мой Telegram‑канал. Там чаще, короче и местами больнее
Друг недавно пошёл купить планку памяти на 16 ГБ и вернулся с ощущением, что железо скоро будут продавать в ипотеку.
Он зацепился за простую мысль: оперативка есть везде — в компьютерах, телефонах, приставках, серверах. Если память дорожает, значит очень быстро подорожает всё остальное железо.
Для разработчиков это неприятный звоночек. На мобилках и десктопах подход «и так сойдёт, железо вывезет» будет работать хуже: более дешёвые устройства, больше экономии на начинке — значит, снова придётся думать про оптимизации, вес приложений, количество абстракций и то, что реально нужно тащить в рантайм.
На бэке привычное временное решение «завалим проблему железом» (которое по традиции становится постоянным) тоже перестаёт быть очевидным. Если память, GPU и виртуалки дорожают, то горизонт «давайте просто докинем ещё один инстанс» превращается в всё более дорогой вид спорта.
С другой стороны, на всё это сверху уже наезжает волна сервисов и приложений на LLM, сделанных без особых мыслей про ресурсы. Если виртуалки и GPU подорожают, LLM‑API, скорее всего, тоже станут дороже, а значит, экономика части проектов, построенных по принципу «шлём всё в большую модель и не паримся», может просто перестать сходиться.
Разработка в итоге снова превращается в честный анализ критериев: что считать локально, что кешировать, какую модель брать, что выкинуть, чтобы продукт вообще жил в плюс, а не работал в минус ради красивых демо.
Вопрос к читателям: если железо и облака ещё подорожают, вы скорее пойдёте в жёсткую оптимизацию всего или просто заложите рост себестоимости в цену продукта?
Если такие разборы интересны, в Telegram делюсь ещё и практикой: как считаю экономику своих фич и LLM‑штук на реальных проектах.
Термин A-Player сначала звучит как что-то из спорта, но в IT под этим обычно понимают людей, которые тащат команду на новый уровень. И это не всегда «сеньор с 10 годами опыта». Иногда это может быть джун, который смотрит на работу шире, чем просто строчки кода.
A-Player отличается не количеством выданного кода, а подходом. Он думает о продукте, а не о том, чтобы накрутить ещё один сервис ради красоты архитектуры. Он делает жизнь коллег проще, поднимает планку в команде и берёт на себя задачи так, что другим не нужно держать их в голове. С ним процессы двигаются быстрее, а продукт становится лучше. 🚀
Я понял это на собственном опыте, когда начал активно запускать пет-проекты. Там ты одновременно разработчик, продукт, дизайнер, саппорт и менеджер. Ты не можешь спрятаться за «моя часть готова, дальше не моя проблема». Ты видишь весь цикл: от идеи до первых пользователей. И именно это формирует продуктовое мышление, которое отличает A-Player от «просто хорошего кодера».
В стартапах и небольших командах такие люди решают исход проекта. Один A-Player может дать ценности больше, чем пять «средних». Не потому что он пишет в пять раз больше строк, а потому что думает в пять раз шире. Он видит проблемы раньше, берёт на себя ответственность и фокусируется на том, что действительно двигает продукт вперёд.
По сути, каждый пет-проект — это маленький тренажёр 🏋️ для прокачки этих навыков. Ты учишься брать ответственность целиком, думать о ценности для пользователя и экономить время — своё и потенциальной команды. В карьере это очень заметно: такие навыки ценят куда выше, чем знание конкретного фреймворка.
Хочешь стать ближе к A-Player? Начни с простого вопроса: то, что ты делаешь сегодня, делает ли продукт лучше и жизнь коллег проще? Если да — значит, ты на правильном пути.
Я пишу о своём пути в indie-hacking и пет-проектах в телеграме. Если интересно наблюдать за процессом изнутри - ссылка в профиле ✨
Интересная история из мира инди-разработки — парень, не бросая основную работу, построил SaaS-сервис, который спустя два года принес ему крупный exit.
🧪 Началось всё с личной боли. Его жена, научный сотрудник, жаловалась, как сложно читать и пересказывать научные статьи. Он решил помочь и за пару вечеров собрал MVP — SciSummary, сервис, который автоматически сокращает и упрощает академические тексты.
💡 Проект запущен в январе 2023. Уже через 3 месяца с помощью Google Ads, SEO и пары постов у инфлюенсеров сервис начал приносить $1k в месяц. В это же время он узнал, что скоро станет отцом, поэтому не стал рисковать и продолжал работать по найму (его зарплата — $250k в год), а проект развивал в свободное время (~20 часов в неделю).
📈 Спустя год:
– Проект стабильно генерирует $25k MRR
– В команде 6 удалённых фрилансеров
– Более 700 тысяч пользователей
– ARR — около $400k
🔥 В 2024 он продал 85,5% проекта, но остался в нём ведущим инженером. Причина продажи — выгорание от постоянной нагрузки и желание больше времени проводить с ребёнком.
«После сделки чувства были смешанные — радость, тревога, оцепенение. По сути, моя жизнь не изменилась. Я всё так же просто работаю».
⚙️ Что важно вынести из этого кейса:
🎮 Автор проекта в своём профиле скромно пишет: «Люблю кодить, играть в игры и пить пиво». А по факту — запустил сервис с ARR $400k, пока качал коляску на выходных.
🔗 Я веду Telegram-канал, где разбираю такие истории и делюсь собственными экспериментами в инди-хакинге и запуске микро-продуктов. Ссылка — в профиле.
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи.Их просто нет
Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты
Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ru edge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth
Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД
Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки
Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибкиRLS (Row Level Security) ошибается молча.
Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций
Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи.Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок
Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?
Дебаж 🐞с ноги 🦶
35 лет подряд Янн Лекун угадывает повороты в ИИ.
В 80-х он говорил про распознавание изображений, в нулевых - про нейросети, в 2016 - про самообучение.
И вот сейчас он заявляет самое радикальное: LLM в том виде, в каком мы их знаем, мертвы.
Проблема не в данных и не в мощности, а в архитектуре.
Каждый токен чуть сдвигает модель в сторону, и чем длиннее вывод - тем выше шанс галлюцинаций. Никакие терабайты и GPU это не спасут.
А теперь подумай, сколько сейчас продуктов держится только на API OpenAI.
Чат-боты, резюмирование документов, генерация текстов.
Все эти проекты живут лишь потому, что можно позвать API.
Но новая волна придёт не от «больше параметров», а от моделей, которые учатся «как дети»: через видео, восприятие и понимание мира.
И тогда поддерживать бизнес на API старых LLM станет бессмысленно. Новые модели будут быстрее, точнее и дешевле.
Лекун прямо говорит: закрытые модели исчезнут, открытые и распределённые — победят. Meta уже вкладывает $20 млрд в перестройку стратегии. Сроки короткие: 3-5 лет до первых моделей мира, и около десятилетия до ИИ уровня человека.
Для корпораций это вызов. А для indie-hacker’ов - шанс.
У больших игроков всё завязано на старых API и инерции.
А у нас есть свобода пробовать новое. Пет-проекты — это маленькие лаборатории, где можно тестировать идеи будущего и учиться жить «после LLM».
Когда рынок перетрясёт, выиграют те, кто уже умеет мыслить продуктом, а не строками API.
Я как раз пишу о своих экспериментах в инди-хакинге и пет-проектах у себя в телеге 👉 ссылка в профиле
Бомж Фёдор, мастер инвестиций,
Открыл стартап, войдя в кураж.
В очередях народ толпится
Попробовать
Если бы год назад меня спросили, с чего начинать IT-проект, я бы не задумываясь сказал: с MVP.
Так учили, так делают большие продуктовые команды, так звучит «по науке».
Но чем больше я работаю, тем сильнее понимаю, что моё представление о minimal и value давно извратили корпоративные процессы.
MVP — это уже не про скорость, а про маленький продукт с большой бюрократией.
Проблема даже не в том, что минимальный продукт часто получается просто говном — с багами, уродливым дизайном и UX из 2010-го.
Проблема в том, что на него уходит время. А это уже не MVP, а мини-стартап со всеми рисками.
Сейчас я всё больше убеждаюсь, что главное — не идея и не продукт, а трафик.
Сколько его, сколько стоит, где его взять, как купить, какая там конкуренция и какие риски.
Трафик — это и есть спрос. Всё остальное — следствие.
Иногда вместо MVP хватает лендинга.
Он быстро отвечает на главный вопрос: стоит ли вообще делать MVP и какие фичи туда добавить.
Ориентиры простые:
Если CTR высокий, а CR низкий — идея заходит, но оффер не цепляет.
❌ Плохо описана фича.
❌ Много нецелевой аудитории.
Если CTR низкий, а CR высокий — наоборот: оффер норм, но ты не туда бьёшь.
🎯 Промах по таргету.
🎯 Слабая коммуникация.
Если оба низкие — идея мёртвая.
И вот теперь я думаю: может, всё MVP-мышление надо перевернуть?
Не строить продукт, чтобы проверить спрос, а сначала проверить спрос, чтобы понять — нужен ли продукт.
Короче, если твоя идея собирает внимание — проект почти точно полетит.
Я пишу про такие наблюдения, тесты и свои эксперименты с инди-продуктами у себя в телеге 👉 t.me/debug_leg
Я всё больше прихожу к мысли, что моя стратегия - это не «ставка на одного единорога», а портфель продуктов.
Я постоянно запускаю новые проекты. Да, не все они находят рынок. Но зато всегда есть шанс, что один или два "выстрелят".
Почему не один?
Потому что меня не драйвит идея "сидеть на одном продукте до посинения". Мне нравится запускать, проверять гипотезы на реальном спросе, а не тратить месяцы на интервью и бесконечные обсуждения проблем пользователей. Минимальный прототип -> рынок -> обратная связь. И вперёд.
У этого подхода есть очевидные плюсы. Это диверсификация: один провал не убивает всё. Это быстрые тесты: можно пробовать разные рынки и модели монетизации. Это сглаживание дохода: разные продукты дают суммарный MRR и снижают волатильность. И, конечно, это опыт: каждый запуск учит чему-то новому, и следующий делать проще.
Но есть и обратная сторона. Переключение между проектами рвёт фокус. Поддержка множества продуктов превращается в постоянный саппорт. Иногда ловлю себя на том, что не дожимаю тот проект, который стоит дожать, потому что «есть ещё три».
Бренд тоже страдает: аудитории сложнее понять, о чём ты. Ну и усталость - постоянные запуски дают дофамин, но оставляют хвост незакрытых задач.
Короче, портфель продуктов - это не магия и не серебряная пуля. Это осознанный выбор между рисками и свободой. Я понимаю, что так жертвую глубиной и стабильностью, но выигрываю в скорости, энергии и опыте.
И знаете что? Пока мне нравится сам процесс. Запускать, смотреть реакцию, делать выводы и идти дальше. Это даёт мне больше мотивации, чем идея "строить идеальный продукт годами" (это уже проходили).
Кстати, я регулярно пишу о своих продуктах, экспериментах и запусках в телеграме 👉(ссылка в профиле)
Всем привет. Меня зовут Максим. Являюсь веб-разработчиком и сейчас поставил цель разработать два своих небольших проекта и довести дело до продаж.
Вообще имею большое кладбище стартапов. Их конечно нельзя назвать полностью неудачными, т.к получал с них опыт, что очень важно и полезно.
Но сейчас решил изменить подход к разработке, развитию проектов. Одно из изменений - вести заметки и делиться удачным, неудачным опытом. Возможно это поможет довести проекты до конечной цели и вполне возможно опыт, которым поделюсь будет кому-то полезен.
Для разработки выбрал два проекта: система лояльности для небольшого бизнеса и seo-мониторинг сайтов. Пока без подробностей.
Точка отсчёта - 22 мая 2025 года. Релиз seo-мониторинга - 1 июля 2025 года, система лояльности - 1 августа 2025 года.
Первый раз при разработке своих проектов сделал оценку трудозатрат и будет интересно сравнить ожидание и реальность.
Также посоветовали больше писать о проектах, делиться мыслями. Будет конечно трудно, но попробуем)
Для коротких заметок создал канал в telegram https://t.me/itmvpnotes
Спасибо за внимание
На пикабе прорекламировали новый стартап. https://skazalitochka.ru. Суть - пользователи различных сервисов бы оставили отзывы бы но им лень пейсать. У них лапки. Они привыкли голосовые кидать. Ушлые чуваки предлагают за скромную плату поставить на сайт владельцев online-магазинов и сервисов некий плагин преобразующий речь в текст:) Шикарно!
И ведь будут покупать!
Выдержка из руководства "О Яндекс Клавиатуре для Android" к примеру:
Зажмите правую зону пробела со значком микрофона и отпустите — включится режим диктовки.
Надиктуйте текст. Клавиатура сама расставит знаки препинания.
Чтобы завершить диктовку, нажмите или значок отправки сообщения
