Как деплоить свои веб-проекты

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

🔥 Цель простая: быстро писать код и быстро отправлять его в прод. Желательно имея возможность легко откатиться на предыдущую версию (за вычетом миграций схемы данных).

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

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

🚫 Железный выделенный сервер в чьём-то датацентре: не рассматриваю, т.к. слишком дорого и не нужно под игрушечную нагрузку сайд-проектов

✅ Виртуальный сервер в облаке (VPS) от Digital Ocean, AWS, GCP, etc: нормальный вариант, требующий настройки, но достаточно недорогой, нагрузка может быть любой - толькло плати и настраивай горизонтальное масштабирование

⚠️ Платформа (Platfform as a Service): более удобный, но одновременно и более дорогой вариант, который легче настроить. Зависимость стоимости от нагрузки вроде тоже линейная, если не учитывать замороченные pricing схемы облачных провайдеров

🚫 Serverless: не рассматриваю, т.к. не фанат и не вижу практической ценности для своих проектов

Для своих проектов, как личных, так и клиентских, я использовал GCP как PaaS, AWS с ручной конфигурацией (поднять EC2, RDS, SQS, настроить Cloudfront), VPS, а также AppPlatform от DigitalOcean. Ещё баловался с Firebase (тоже PaaS от гугла), но на них забил.

Лично мне больше всего нравится DigitalOcean из-за простоты и доступности. Бот и сайт Стильного клуба работают на App Platform (PaaS), а мой сайт на выделенном droplet (VPS).

Также нужно настроить Cloudflare (в частности, для TLS termination), nginx как reverse proxy, хранилище файлов (S3-подобная штука, либо просто раздавать с диска через тот же nginx), postgres и redis. Последние я беру в managed-исполнении, то есть не заморачиваюсь с настройкой и просто плачу $15 за инстанс.

Единственное неудобство - собственно деплои. Пробовал я следующее:

⚠️ ansible на VPS: геморно в настройке, очень многословно, секреты хранятся в зашифрованном виде прямо в репозитории. От yaml тоже подташнивает

⚠️ github actions + рукописные скрипты для примитивных деплоев в стиле "big bang", секреты для сборки в гитхабе, секреты в продакшене из AWS Systems Manager

✅ деплои на App Platform через git push: работает практически из коробки, включая откаты релизов, но много ограничений, неэффективные пересборки и перезапуски. Секреты берутся из настроек на самой платформе

😍 докер-контейнеры под каждый сервис: собираем всё локально/в гитхабе - фронтенд, бэкенд, воркеры и т.п., кладём в DockerHub/любой container registry, на сервере делаем docker pull и docker compose up.

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

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

А вы как, куда и почём деплоитесь?

Ждём с нетерпением! 🤡

Не деплойся с краю 🐺

Хочу попробовать deno на следующем маленьком сайд-проектике (будет бот для телеги). Хоть я уже больше трёх лет и писал свои коды в основном на питоне, хочется чего-то свеженького в продакшене.

По просьбе CTO компании-клиента, который не любит питон, свой текущий проект делаю на node/ts + react/ts. Прикольно, конечно, типы шарятся туда-сюда, express мне тоже очень нравится - простой, быстрый, очевидный. Типизация в TS просто огонь в сравнении с этими class User(TypedDict) в питоне. Асинхронность более привычная, чем с asyncio. Короче, кайф, жить можно. Хотя питон тоже огонь с dataclasses, fast-api и прочими sqlalchemy.

В общем, полез я смотреть что там у deno сейчас происходит, а они уже конкурента vercel строят вовсю 🤯

Всю эту молодёжную серверлесс красоту я воспринимаю скептически (а NextJS вообще уродец жуткий и тормозной, как по мне). Но тут взгляд зацепился. Потому что идеи, стоящие за deno, мне нравятся.

- простая cистема зависимостей (в теории)
- лучшая совместимость с привычными API браузеров
- адекватная система ограничений
- typescript из коробки

Ну и всяко-разное ещё, выглядит многообещающе 😍 bun тоже прикольный, но в нём мне больше сам код на сишке zig нравится, а в deno функциональность.

Так вот, сначала взгляд зацепился за Deno KV (key-value что ли?). Это какая-то чудо-юдо serverless edge database as a function 🥴 Там всё на свете сразу: и распределённость c масштабированием, и (де-)сериализация прям в/из JS. Хоть товарищи и говорят, что подобных БД на рынке уже хватает, мне всё равно любопытно (как человеку, у которого железный сервер под столом стоит).

Потом оказалось, что у них и Deno Deploy есть. Выглядит похоже на почти идеальное решение для того, что обсуждали в посте про деплои.

🔥 А идеальное решение для деплоев сайд-проектов такое: сохранить функцию (отправить код в продакшен) и не потратить на это силы, время и деньги. То есть код в проде есть, а настраивать ничего для этого не надо. И платить тоже (на игрушечных нагрузках сайд-проектов, конечно же).

Я хоть и сопротивляюсь serverless изо всех сил, и в работающий и приносящий деньги проект всё это наверное бы не потащил, такие штуки выглядит суперски для быстрой проверки идей и проектов, которые не жалко выкинуть.

Bloom filter

Ковырял мануалы по редису, наткнулся там на Bloom/Cuckoo filter и понял, что не помню, что это такое. Полез искать и наткнулся на две потрясающие визуализации:

- тык
- тыдык

Очень круто и наглядно сделано! 🔥

Вкратце: bloom filter - это set, который поддерживает 2 операции:
- достоверно определить, что элемента в множестве нет
- с некоторой вероятностью определить, что элемент в множестве есть

Реализуется на основе хэш-функции с хорошим распределением.

При добавлении любой элемент сначала превращается в N битов, и эти биты устанавливаются в 1.

Для проверки делаем то же самое, и если все биты взведены, то элемент вероятно в множестве. Если нет, его точно нет.

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

Enjoy!

☠️ Deno - живой труп?

Как вы помните, мне приспичило побаловаться с deno. Причиной послужило то, что тайпскрипт с нодой по-прежнему дружит достаточно плохо: нужно поставить ts-node для разработки, ускорить это через swc, в прод собирать через tsc или ts-patch, сверху пяток плагинов для тривиальных штук, подружить это всё через tsconfig... Короче, очередной вебпак и бабель.

Тогда я решил попробовать собрать нового телеграм-бота на deno и запушить всё это бесплатно в deno-облако.

Мои ожидания по поводу поддержки тайпскрипта, конечно же, оправдались. Всё летает, --watch работает быстро и как часы, не нужно никакой обвязки! Очень круто, что не надо ставить 100500 утилит вокруг: есть deno test, deno lint и fmt (и не такое придурашное, как prettier или airbnb-конфиг для eslint), deno repl и deno bench. Кайф 🔥

И можно даже забить на отсутствие официального образа в Dockerhub под apple silicon. Есть неофициальный, в котором даже watch работает как надо.

Почему же deno - труп?

Изначально deno задумывался как правильный node js. Они выкинули всё, включая стандартные и проверенные годами штуки вроде http, fs и подобных модулей, многие привычные API отправились туда же и были заменены браузерными (вот уж где я не совсем согласен, но идея понятна).

Поначалу запустить какой-нибудь express на deno было просто нельзя, by design. По всем любимой причине: "ты не должен этого хотеть" 🤣 Но что-то случилось, и спустя несколько лет появляется...

1️⃣ Обратная совместимость с нодой, а с недавних пор - и полная совместимость с npm-пакетами. На первый взгляд круто, да? И удобно! Но это первый симптом долгой и мучительной кончины. Следим за руками:

- В deno мы сделаем всё как надо...

- Никто не повёлся, без npm жизнь не мила. Выкатим обратную совместимость с npm...

- Стало лучше (наверное), но авторы oak, redis и прочих написанных под deno библиотек отправляются в пешее эротическое путешествие. Зачем нужны кривые и недописанные костыли, если есть проверенные годами koa, express, официальный node-redis, с хорошей поддержкой и покрытием тестами?

- Нода продолжает развиваться, а вместе с ней и популярный опенсорс. Появляются новые API, про deno никто из авторов не думает, а значит deno вынужден (будет) продолжать поддерживать node.

- И тогда deno... превращается в node с быстрой компиляцией typescript?

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

Но есть и вторая причина...

2️⃣ Венчурное финансирование и целевая аудитория! Команда подняла $21m год назад, чтобы сделать "javascript for serverless era" - и позволить хипстерам деплоить свои функции прямо на край, без занудной настройки серваков и инфраструктуры.

Но мы-то знаем, что, хотя для миниатюрных проектов serverless и может быть почти бесплатным, зарабатывают облака не на них. А на огромных клиентах вроде Netflix или Twitch, в которых есть свои инфраструктурные команды, оптимизирующие и издержки, и developer experience.

Весь serverless может оказаться просто оплачиваемой из бездонного кармана крупных облачных провайдеров попыткой раскрутиться за счёт почти бесплатных пользоватлей, чтобы, через неизбежную оптимизацию стоимости, затащить их на свои привычные VPS и Anything-as-a-Service решения. Человек в костюме медведя.

А вот у deno карманы не бездонные. А ещё есть конкуренция со стороны Netlify или Vercel, которые как раз для той же ЦА и понаделали Next.js и подобных штук. И, с их точки зрения, deno как среда разработки наверняка сильно проигрывает комбайнам, где всё уже как-то сделано за тебя.

🤔 Получается, что платформа deno наверняка умрёт без органического роста adoption и из-за совместимости с node, в то время как деньги подняли под serverless-штуки: deno deploy и deno kv. Мало того, что каждый из компонентов сложно сделать правильно и выдержать конкуренцию, они ещё и бьют в хотелки разных целевых аудиторий.

Я могу ошибаться, ведь serverless рынок растёт. Как думаете, чем закончит deno как технология и компания?

Красота-то какая! 😍

Отличная статья LLMs Practical Guide из замечательного рассказа Andrej Karpathy про то, как устроены и как использовать LLM.

А вы как относитесь к LLM? К ChatGPT и подобным.

Используете в работе?
Делаете приложения на их основе?
Думаете, они бесполезны, и всё это хайп?
Не знаете, что это такое вообще и зачем?

Поделитесь в комментах!

Вот как на самом деле работают продукты с суффиксом AI 😁

Не хочу превращаться в новостной канал, но 2 недели назад OpenAI подал заявку на патент на GPT-5 🫣

Мемчики на вашу мою любимую тему завезли 🤪

1. Идея важнее всего — делаем стартапы с умом ❤️

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

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


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

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

Идей у меня был миллион. Самый смешной случай был наверное лет 15-20 назад. Я придумал минималистичную CMS под названием Colibri (очень оригинально), и до того мне эта идея понравилась, что я написал на неё СПЕЦИФИКАЦИЮ. Неделю наверное писал.

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

Я тогда зачитывался книгами Брукса, ДеМарко и Листера, Спольски про лютый энтерпрайз и зачем-то тащил решения энтерпрайзных проблем в свои миниатюрные задумки. До сих пор ржу 🤣


✅ Плюсы этапа одержимости идеями

1. Это весёлый творческий этап, на котором можно поймать много кайфа и вдохновения

2. Идеи (изредка) могут быть хорошими

Хорошие идеи "из головы" появляются, на мой взгляд, только лишь как следствие большого опыта и прокаченной интуиции в той области, где вы создаёте. Ну, как у Баффета в финансах и бизнесе.

Но даже если идея потрясающая, её всё равно надо быстро проверять, чтобы увеличить шансы попасть в окно возможности. Зависать на этом этапе вредно!


👎 Минусы

1. Обычно "классные идеи", приходящие в голову без погружения в проблему, мало чем отличаются от галлюцинаций LLM. У меня так точно

2. Идеи имеют отрицательную стоимость, потому что реализация и продвижение стоят денег - а главное, времени

Хоть я и уверен, что каждый человек хоть раз придумывал что-то увлекательное, ценности сами по себе идеи не несут. А появляются они так легко и часто, на мой взгляд, потому, что наш ум - точно как большая языковая модель (LLM) - увлекает нас в рассуждения и фантазии, генерируя бесконечный внутренний диалог.

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

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

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

Ставьте ❤️, если ждёте следующие части. И рассказывайте про свои идеи!

2. Реализация важнее — делаем стартапы с умом ❤️

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

Это расхожее и, в большей степени, правдивое утверждение тоже хочется обсудить.

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

Так или иначе, я ничегошеньки не делал для их воплощения в действительность, а самое главное - сомневался в наличии способностей и навыков, чтобы реализовать свои идеи 🤔

Только попав в фейсбук и заскучав там во время коронавируса, я махнул рукой на все сомнения и принялся за реализацию. В это время я сделал словарик английского с произношением Quiken, Калькулятор стоимости жизни, начал и доделал до вменяемого состояния сайт со статьями. Чуть раньше, пока учился и отдыхал в Штатах, я сделал небольшое приложение для учёта своих трат.


✅ Полезное на этапе "надо суметь сделать"

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

2. Мы учимся лучше всего на практике, через делание - фундаментально важная мысль! И, хотя я "знал" это много-много лет, научиться так действовать удалось только недавно 🤯

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

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

На мой взгляд, единственный работающий триггер для изучения чего-то нового - это взять и попробовать. Сначала не будет получаться, потом что-то получится, но по непонятной причине. Затем причины, структура реальности и неочевидные поначалу взаимосвязи станут более понятны. Круг обучения (по David A. Kolb) замкнётся.

Месяц назад я не знал, как использовать LLM, а сейчас делаю несколько проектов с их использованием и читаю самые свежие научные статьи на тему эффективного использования языковых моделей. Там столько всего интересного и нового!

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


👎 Минусы этапа

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

2. На этапе делания очень легко зависнуть на неопределённый срок. Особенно нам с вами, программистам, создателям.

Даже с любовью сделанный продукт != коммерчески успешный бизнес. Нужно подумать про клиентов и их реальные проблемы (или "работы" в JTBD), а также как о них узнавать; стратегию и эксперименты с продвижением продукта; его экономическую целесообразность и жизнеспособность.

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

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


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

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

О себе в 50 словах

🧌 (иконка бомжа) фултайм стартапер-бутстрапер, он же индихакер уже больше года

💃🏽 вместе с женой делаем и продаем Стильный клуб для девушек

🚀 запускаю небольшие проекты с расчетом, что что-то рано или поздно "взлетит"

🤑 променял зарплаты, опционы и должности в Sourcegraph, Facebook, Toptal, Яндексе на свободу

🇬🇧 живу в Лондоне, воспитываю сына


Всем привет и добро пожаловать! Рассказывайте в комментариях о себе 🔥

Полезные посты прошедшего 🥲 лета

- Как в продакшене память потекла, скачки в 10-15% за раз, и как всё разрешилось
- Ужасы отладки
- Публично о неудачах
- Совпадения и хорошие новости
- Код-ревью: убрать нельзя оставить
- Как деплоить свои веб-проекты
- Не деплойся с краю
- Про bloom filter
- Deno - живой труп?
- LLMs practical guide
- Идея важнее всего - делаем стартапы с умом
- Реализация важнее - делаем стартапы с умом

Ставьте сердечки и пересылайте друзьям ❤️

Почти 404 Day not found 🤣

С праздником, коллеги! 🎉

🎸 Металлика напишет status update, а ✌️Эминем пожелает коллегам хороших выходных

Как вы наверное знаете, я много вожусь с LLM — как по работе, так и для себя. И вот решил поделиться с вами очередным экспериментом — @fraza_ai_bot.

Это бот, который может 🌿 подправить грамматику в английском тексте, переписать его на манер ✌️эминема или 🎸металлики. Смотрите примеры в чате/комментариях к посту.

Вот, например, Эминем желает вам хороших выходных:

Yo, appreciate you peepin' this rhyme
Wishing you a dope Friday, have a real good time
Hope your weekend's sunny, no clouds in sight
Stay blessed, my fam, keep shining so bright

😁

У каждого пользователя есть 30 бесплатных попыток. Попробуйте, расскажите о впечатлениях!👇

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

Пишу я вчера в рабочий чатик update о том, что выкатил новую версию на стейджинг. Рядом API playground от OpenAI открыт. Засомневался в себе, попросил GPT перефразировать сообщение, чтобы звучало более естественно. Получилось. Думаю: "во, прикольно, можно в бота по-быстрому завернуть это всё".

Ведь у меня как раз есть инфра для быстрого запуска таких вот AI-ботов 💪

Удобнее будет, чем промты перебирать. Одновременно фантазирую, что можно не только грамматику исправлять и подгонять под американский/британский/международный стиль, а ещё и поржать. Что, если сообщение написал бы кто-то знаменитый? Шекспир, Толкиен, персонаж Гая Ричи, Металлика, Эминем? Весело же!

Тут уже в глазах искорки славы заплясали! 🤡

"Вот выкачу всё это, дам знакомым сначала, потом в блоге опубликую, потом статью на VC напишу..." — так думаю. Быстренько туда квоты на использование прикрутил, сделал удобное редактирование сообщений, такое, чтобы пересылать можно было оригинал вместе с исправленной версией.

"Да, телеграм-бот — точно не лучший формат", думаю я, "но если людям надо (а как может быть не надо? Круто же!), то воспользуются". Фантазировал про Slack ещё, вацап, разное такое.

И что вы думаете, опубликовал я пост, прочитало его уже ~500 человек... и воспользовались только трое. Да, трое, Карл! 🤣

Думаю, что причин этому масса:

- плохо написан текст, не понятна ценность, нет внятного триггера, чтобы пойти и попробовать

- тут вряд ли достаточно представителей ЦА, либо до них не донесена ценность...

- высокие транзакционные издержки: бота надо открыть, нажать кнопку, скопировать текст, выбрать ещё одну кнопку (а их там 8 штук!), подождать, прочитать ответ, скопировать его назад

- мало ценности в сравнении с ChatGPT и другими исправлялками — особенно для ребят вроде вас, которых этим не удивить!

Может ещё подскажете? 🤔 Точно ведь ещё какие-то косяки есть.

Хорошо только, что я на разработку потратил буквально около 6 часов. А не месяцев или лет 😆

💪 6 часов от идеи до прода

Несколько лет назад я запустил свой первый публичный сайд-проект — словарик с произношением Quiken. Хоть им попользовалось от силы человек 10, готовился я всерьёз. Тогда путь от идеи до прода занял месяца три. И мне казалось, что это быстро.

Сейчас же, с @fraza_ai_bot, на разработку, от идеи до продакшена, я потратил всего шесть часов.

Очень горжусь этим обстоятельством!

🔥 Запуститься так быстро мне помогают несколько простых принципов

👻 Я трезво оцениваю свои силы, а значит не берусь за слишком сложные и длинные проекты.

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

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

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

🤯 Лучше один раз попробовать, чем месяцами фантазировать и надумывать.

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

🤭 Отказ от "best practices" в разработке. В подобных экспериментальных проектах я стараюсь писать минимум кода, без ненужных абстракций. Чем понятнее, тем лучше — и тем меньше шансов ошибиться. А значит не нужны и тесты.

Реляционной БД со схемами, миграциями и прочими заморочками нет — вместо нее юркий redis. Инфраструктуры, как таковой, тоже нет — только копеечный VPS с докером. Деплои я делаю вручную в 4 команды (docker build, push, pull, docker compose up). Логи пишутся только в stdout/err и никуда не сохраняются. Мониторингов нет. Одна кожа да кости, ничего лишнего.

🤔 Чем гордиться, и зачем нужны такие мелкие проекты? — этим вопросом я и сам постоянно задаюсь.

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

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

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

🗺️ Я вижу две принципиально разные стратегии для стартаперов

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

2️⃣ Выбрать одно направление и без устали долбить туда несколько лет, по сути, перебирая все возможные комбинации факторов успеха.

У обеих есть плюсы и минусы, но я пока что чаще склоняюсь к первому варианту.

Так веселее и задорнее, и мне нравится делать быстрые и небольшие проекты.

Единственное, что я обязательно добавлю — это такие же быстрые и "грязные" эксперименты с маркетингом. Ведь очевидно, что моя аудитория в канале может очень плохо совпадать с ЦА моих экспериментов, а умение найти работающие каналы продвижения не менее важно, чем полезный продукт.

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

Потраченное на разработку время = деньги и упущенные возможности 💰

Лайк-репост, как полагается, с вас ❤️