👩🎤 Инди vs Корпорат 👨💼
Сегодня поговорим про пет- и инди-проекты.
Я, как тот самый живой человек, много лет совмещающий работу в компании и свои более-менее окупающиеся инди-движухи моя зарплата лида в Германии и доходы от пет-проектов на 2024-й примерно равны друг другу , частенько замечаю, как новички не могут вкатиться в свои инди-проекты, потому что у них сильно насрано в головах корпоративностью: кубернетесами, тестированиями, фреймворками, и прочими базвордами из их основной работы.
Программистам, начинавшим свой путь в корпоратах, сложно взять и начать писать инди, потому что у них сразу включается массированный overthinking я так и не нашел этому слову нормального перевода, подскажите плез — они начинают накручивать себе проблемы, которых на самом деле нет.
Им просто годами долбили, что они есть. Что всегда нужно думать о прозводительности а еще не дай бог помнить о Big-O notation :DDD , что всегда нужно писать тесты, что без докера-кубернетеса жизни нет, а CI/CD с красивым zero-downtime blue-green деплойментом обязателен.
В это же время какой-нибудь инди-номадлист делает БРРР, так как представляет из себя файл index.php, фронтенд на jQuery, базу данных на SQLite, в которой даже JOIN не используется, а деплоится это всё через великолепное перетягивание файликов через FTP. И его автор, Питер Левелс, делает на своих инди-проектах $2.5 миллионов в год. Один. Без налогов.
Ну либо возьмите любой другой инди-проект с Indiehackers.com или StarterStory.com с MRR от $5K в месяц. Я гарантирую, полыхающий бугурт да как так можно и как они на такой фигне столько зарабатывают!!11 на весь район гарантирован.
Программистам же самоучкам, которые изначально «инди», которые привыкли к методологии «Херак Херак в Продакшен» и «Fail Fast, Learn Faster», наоборот, всегда сложно вписаться в корпорации.
У них сразу волосы на подмышках начинают шевелиться, когда их команда закладывает шесть недель спринта на перекраску одной кнопки.
И вот почему так?
Как человек, познавший на своей шкуре обе стороны, могу сказать: здесь нет «правильного» или «неправильного» подхода. Просто существует два разных мира, которые нужно не путать, и тогда все будет заебись.
Сегодняшний пост как раз о них.
Любая компания — это давно запущенный механизм, главная цель которого — долгосрочное выживание всей системы, а не красота её отдельных блестящих шестерёночек.
Каждая новая строчка кода, которую вы пишете на работе, должна не просто решать свою задачу (с таким любой джуно-миддл справится) — она должна гарантировать, что тот чувак, который будет трогать её после тебя, ничего не сломает. А в идеале сможет еще и понять.
Для больших корпораций нормально, когда на проекте нет ни одного человека, который бы понимал систему целиком. Почти всегда оригинальный автор либо уже уволился, либо сменил проект, либо пошел на повышение.
Потому и нужны все эти дополнительные слои защиты — код-ревью, тестирование, автоматизация деплоя, отката, мониторинга производительности и прочего.
Да даже вы сами поставьте себя на место новичка. Вам будет комфортнее вкатываться в проект, где всё покрыто тестами, автоматически собирается и заранее сообщает о возможных проблемах, либо же в типичный «хуяк-хуяк-продакшен» стартап, где чуть тронь — всё посыпется как карточный домик?
То-то же. Вот потому и шесть недель на кнопку.
В корпорате вы пишете код не «для себя», а для того бедного поцана или поцанессы, которые придут после вас. Иначе жопа. Сраных «художников» никто не любит :)
И даже я сам, как тимлид в корпорате, за этим слежу. Потому что пока я на работе — я ношу эту шапку, да.
С другой стороны у нас инди. Ты один. Ты сидишь дома в трусах и пытаешься закодить очередной SaaS, чтобы нанести им пользу людям, а в идеале еще и заработать себе на сырную тарелку.
В инди ты сам себе и фаундер, и продакт, и фронтендер, и бекендер. Здесь и далее под «инди» подразумевается любой проект, сделанный одним человеком, без привлечения денег инвесторов, без попытки сделать «стартап» и собрать команду, а чисто бутстрап-штуки на самоокупаемости.
Здесь не будет людей «до» или «после» тебя. Главный и единственный человек, который когда-либо увидит твой код — это ты сам в будущем. Даже если ты станешь дофига успешным и продашь проект, то покупать будут компанию, а на код даже не посмотрят.
В инди твоя главная задача — писать код так, чтобы ТЫ САМ мог его пофиксить спустя год в два часа ночи пьяным с телефона
Стек для хорошего инди-проекта — максимальной тупой стек. Вот настолько тупой, чтобы тебе даже самому было стыдно, что ты используешь этот кусок говна мамонта.
Тот же Вастрик.Клуб написан на Django + Postgres + Redis + asyncio. Я всё это использовал еще в позапрошлом десятилетии окей, тогда вместо asyncio был tornado и знаю как свои пять пальцев. Меня ночью разбуди, я вам все модели в базе мигрирую, даже не приходя в сознание.
С деплоем такая же история. На работе у меня всё есесно в кубернетесах-шмубернетесах, но даже спустя пять лет общения с ними, я до сих пор не доверяю им настолько, чтобы использовать дома. Ваш случай может отличаться от моего. Я рассказываю о себе, а вы экстраполируйте на свой опыт и проводите аналогии по технологиям сами.
Весь первый год я деплоил Клуб своим привычным методом — ходил ручками через SSH и дергал старый советский docker-compose down/pull/up. Так было во всех моих пет-проектах. Клуб тогда еще не был чем-то особенным.
На второй год, когда я понял, что проект выстрелил, я просто делать это каждый раз, потому написал Github Action, который делал то же самое за меня, но по каждому коммиту в мастер сам.
Ииии, всё.
Да, это до сих пор так работает. На проекте, приносящем под $10K в месяц MRR. Да и в этом самом бложеке такое же говно.
Расскажи я об этом на любой айти-конференции — меня просто выгонят швабрами со сцены и отпинают потом в кулуарах.
Но сколько раз я ни пробовал «взять что-то помоднее» — я дольше ебался с фреймворком или компилятором, чем действительно решал проблему, из-за чего я забрасывал проект еще до релиза. Нет, если вы делаете пет-проект чисто с целью изучить новый для вас TypeScript или Rust — это вполне легально. Но если у вас есть хоть какие-то планы потом показать это людям — нет. Не стоит.
Как антипример можно взять тот же Pepic — сервис для загрузки/проксирования картинок и видео, который я использую аж в четырех своих проектах. Аналог imgproxy, только умеющий еще и загружать.
Пепик написан на Go, который я вроде как знаю. Но до сих пор каждый раз, когда мне нужна поддержка новомодного формата AVIF или HEIC, там выясняется, что используемая мной либа уже устарела, нужна новая, но она не умеет в то, что умела прошлая, так что надо переписывать всё минимум неделю, потому что в Go всё «устаревает» каждый год, прям как в JS.
Тотальная боль.
Мог бы написать всё на «медленном» питоне (+Pillow) и поставить снаружи Nginx + Cloudflare как статик-прокси, чтобы питон не напрягать. Но нет.
Даже docker-compose три года назад был «новинкой» в мире моих пет-проектов. До него я реально всё деплоил через SSH + git pull. У меня ушло лет десять, чтобы начать действительно доверять докеру и перестать просыпаться ночью от очередного переполнения диска или Out-of-Memory, потому что я где-то забыл прописать очередную ебаную ротацию логов или вызвать system prune.
Не уверены, что ваш инструмент не разбудит вас ночью — не берите его. Всегда есть инструмент проще.
Не доверяете докеру — дергайте ./myapp.sh restart руками.
Не уверены в новомодной базе данных — возьмите Postgres и не выебывайтесь.
Не знаете бекенда — пишите всё на своем Node.js и не слушайте «тру-бекендеров».
Не знаете git — заливайте файлы по FTP.
Даже вон у jQuery неделю назад мажорная версия вышла.
Ни один проект в истории мира еще не умирал от того, что взял слишком медленный язык программирования, слишком старый фреймворк или деплоил код через SSH.
Большинство инди-проектов умирают потому что их авторы просто выгорают и забивают на них. Поэтому самый лучший способ отсрочить это — взять самые простые кубики и строить всё из них, сэкономив себе моральных сил на куда более важные вещи. Например, той пользе, которую ваш проект наносит его пользователям :)
Закон Конвея вкратце звучит как архитектура всегда повторяет корп-структуру.
Если над проектом работают отдельно команды фронтенда, бекенда и devops, то с вероятностью 100% у них будет три репозитория — «frontend», «API», «infra».
Девопсы не хотят общаться с разработчиками, фронтендеры не хотят трогать бекенд, в итоге даже самый простейший проект в любой компании всегда выглядит как то старое мемное видео про микросервисы.
Компании уверены, что это эффективно. Ведь если у тебя раньше увольнялся жирный разраб-фуллстек, то тебе приходилось искать по рынку такого же жирного разраба и заносить ему двойную кучу денег, чтобы он продолжил за тем.
Теперь же, если у тебя уволился фронтендер — ты просто открываешь окно и там во дворе на лавочке еще парочка фронтендеров точно ошивается. Удобно. Дешево.
Корпоратам такое нравится. Ведь главное для них — взаимозаменяемость.
Однако, такой подход не только раздувает штат компаний, но и приводит к раздутию самих приложений.
Взять те же SPA.
У SPA нет вообще никаких плюсов для конечного пользователя — это чистая диверсия против современного веба. Единственная причина, почему все вокруг пилят SPA — это тот самый закон Конвея с его дешевизной замены винтиков.
Я удивлён как корпоратам удалось продать миру идею SPA. Вот у нас был браузер, который охуенно умел брать HTML и рендерить его тебе на экран. За десятилетия эволюции браузеры научились делать это настолько быстро, что пукнуть не успеваешь.
Но нет же, кто-то пришел и сказал а давайте вместо того, чтобы давать браузеру его любимый HTML, мы будем сначала грузить 12 мегабайт джаваскрипта, потом заставлять кряхтеть его исполнять прямо на месте, чтобы в итоге изрядно заебавшийся браузер осознал, что ему теперь надо сходить еще на 25 разных REST-эндпоинтов, получить 50 мегабайт жсонов (ШТО?), а потооом уже на глазах у пользователя пытаться присрать всё это на страницу в нужных местах.
Всё вокруг прыгает, моргает, десяток спиннеров на странице крутится, ну прям как в цирк Дю Солей попал.
Ведущий спит бухой в горе NPM-зависимостей, рядом акробаты переизобретают URL/роутинг на фронтенде, вокруг клоуны ебаные скачат, которые CSS-in-JS придумали. Литералли вайбы раннего РНР.
Потом на сцену врывается главный клоун и такой — ищь чо я придумал, а давайте страницы на сервере рендерить. Нет, не как раньше. Хуже. Мы кнопку на экране уже покажем, но кликать на неё пока не дадим, ведь её обработчик в тех 12 мегабайтах клиентского джаваскрипта пока не подгрузился!
КРУТО Я ПРЕДУМОЛ??)))
Зрители сидят в ахуе зачем они вообще сюда пришли. Пятьдесят секунд ждут загрузку только одного куки-баннера. Как вам, а?
В общем, вы поняли. Если взглянуть со стороны — всё очень плохо. Не нужно копировать этих клоунов. И нет, у меня нет вопросов, когда SPA — это действительно «application». Графический редактор, там, или Excel в вебе. Но, блять, сейчас даже Reddit, сраный фид с картинками, тоже SPA =/
Так вот в инди всего этого нет. Нет Конвея, нет «команд», нет зон ответственности, нет текучки кадров. Ты один. И это просто отменяет 90% твоих проблем.
Инди-чуваки могут нафигачить за неделю то, что корпорат будет рожать шесть месяцев. Просто потому что у них нет оверхеда на коммуникацию. Инди — всегда монолит, а монолит — самая эффективная структура.
При этом монолиты противопоказаны «командам» — потому что монолит подразумевает то, что каждый член команды понимает всё, что происходит внутри. А в корпоратах такого не бывает, потому они так ненавидят монолиты, и в интернете примерно 9 из 10 статей будет о том, почему монолиты — это плохо.
Но в инди ты один, а значит ты по-умолчанию всё знаешь. В этом и сила инди. Она и позволяет вам обгонять неповоротливые корпораты.
Однако, у вас есть проблема — 99% туториалов в интернете написано чуваками из корпоратов. Если вы попробуете спросить совета в профессиональных сообществах, на вас посмотрят как на душевнобольного.
Расскажу свою историю.
Когда я только начинал писать движок Вастрик.Клуба, я сразу решил, что я не хочу SPA. Это ведь обычный коллективный бложек, где большая часть вещей стандартны для любого браузера, я просто хотел «немного больше интерактивности» типа кликабельных тегов и прочей фигни, который деды в свое время называли «AJAX» ух нафталином запахло .
Тогда я был совсем тупой и без задней мысли спросил у интернета совета «какой джаваскрипт фреймворк посоветуете для простого бложека». За что, конечно, все тру-фронтендеры накидали мне говна за шиворот, после чего я понял, что зашел не в тот район :)
Я сделал второй подход. Я взял сайт гитхаба как пример того, что я хочу. Набор обычных HTML-страниц, которые быстро грузятся, индексируются поисковиками, но на которых МЕСТАМИ есть интерактивные элементы типа лайков, контекстных всплывашек и автокомплита в формах.
Дальше я пошел искать можно ли на популярных тогда React или Vue делать эдакие «частично-интерактивные» сайты.
Ведь в теории можно взять условный React и вместо того, чтобы инициализировать через него всю страницу, просто создавать новый React-инстанс на каждую кнопку лайка на странице, не? Кто мне запретит-то?
Оказалось, что в современном фронтенде за такое дают от 10 до 15 лет строгого режима.
Так нельзя.
Просто нельзя.
Нет.
Абсолютно все фронтендеры мне сказали, что я ничего не понимаю в программировании и чтобы я держался подальше от их поляны с такими идеями.
Уже не помню как, но я нашел буквально одну статью в интернете которую уже потерял , где чувак умудрился подружить Django (который чисто-олдскульный-бекендерский фреймворк) + Webpack + Vue.js именно по такой схеме. Джанга рендерила честный HTML, а уже потом на страницу подгружался Vue, который инициализировал отдельные интерактивные элементы.
Я не знал тогда Vue, но все эти хипстерские фреймворки учатся примерно за час, так что это была прям победа! Ведь оно делает то, что я хотел. С тех пор Клуб на Vue :)
Меня всё устраивает, кроме небольшой проблемки: так как наш движок в опенсорсе, иногда на него натыкаются фронтендеры, которые «хотят пофиксить баг». И вот из сотни желающих, был примерно один, который не убежал в ужасе от того, что у меня там не SPA, а вот такой вот гибрид.
Но меня это особо не парит. Инди же :)
С тех пор я вот уже несколько лет наблюдаю за новыми либами для фронтенда, в попытках найти ту самую, которая бы популяризировала вот этот мой странный стиль.
И, кажется, пару лет назад я ее нашел — HTMX.
Она по сути продолжает дело, которое начал Basecamp с его HotWire — когда вместо JSON'ов ты передаешь в браузер уже готовый HTML и просто нагло его вставляешь на нужное место.
Фронтендеры меня за такие фокусы люто возненавидят, как и автора самой либы. Но да, оказывается, так можно :)
Потому когда я обновлял вот этот вот бложек, где вы сейчас читаете этот текст, я в нем впервые попробовал использовать только HTMX для всех интерактивных элементов типа лайков и отправки комментов.
И знаете. А заебись. Начинай я Вастрик.Клуб сегодня, я бы сразу взял HTMX и забил на всё остальное. Ванильный JS для виджетов и всё.
Да, потому что я бекендер, но вспомните предыдущий пункт. Чем тупее ваш стек — тем больше вероятность, что вы запилите проект и не выгорите.
☝️ про htmx надо прям писать отдельный пост с объяснением его феномена, всех мемов, и огромного хейта со стороны фронтенд-коммьюнити, сопровождающим всех 489 CEO of HTMX и непосредственно автора :D
В современном айти буквально единицы компаний, которые бы достигли успеха полностью на самоокупаемости с первого дня и не привлекали шальных денег инвесторов для «ускорения роста».
А инвесторы всегда хотят одного. Даже если компания может спокойно окупаться и пилить новые продукты в свое удовольствие, инвесторы будут требовать выжимать 10х, 100х, 1000х из имеющихся, лишь бы приумножить свои вложения.
Что бум доткомов, что текущий кризис в айти, стал по сути следствием вливания огромного количества шальных VC-денег и последовавшей за ними паники.
Именно поэтому любой корпоративный софт всегда подвержен процессу enshittification или «оговнякивания» по-нашему. Когда вместо фокуса на продукт и проблемы пользователей, компания в какой-то момент переходит в режим исключительно выдаивания денег из своих пользователей.
Казалось бы, что мешало Dropbox'у просто оставаться удобным файлохранилищем, не ломая старые фичи в угоду новым платным, а Реддиту открытой глобальной платформой для коммьюнити, не объявляя войну сторонним клиентам и своим же модераторам?
Инвесторы.
У бедных компаний начинается биполярное расстройство, ведь им, с одной стороны, нельзя ничего менять, чтобы не сломать бизнес-модель, а с другой, надо срочно что-то менять, чтобы начать зарабатывать ещё больше.
Отсюда и начинаются все эти «изменения без изменений», когда все без конца переезжают на новые фреймворки, выдумывают третью за год «дизайн-систему», внедряют OKR и прочие вещи, о которых никто не просил.
Вот тут-то их и могут подрезать на повороте маленькие и юркие инди, которым всё это не нужно.
В инди-проекте у тебя изначально ровно ноль денег. На еду хватает и ладушки. Тебе нечего терять. Тебе не перед кем отвечать.
Потому цель любого инди — найти реальную проблему и решить её так, как её пока не решил ни гугл, ни блогеры в тиктоке, ни корпораты с их ERP'хами, ни никто вообще другой в мире.
И тогда люди захотят нести тебе денежку.
Люди несут денежку тогда, когда ваш сервис сэкономил им больше сил, чем они бы потратили на зарабатывание этой денежки
Не обязательно для этого искать новую доселе нерешенную проблему мира. Весь современный написанный корпоратами софт настолько плох, что если просто сделать одну единственную фичу, но в один клик и без подписки на «облако» — люди уже будут благодарны и понесут вам денежку.
Причём даже небольшой по меркам корпоратов «денежки» инди-разрабу хватит, чтобы содержать себя, семью и платить ипотеку. Ему не надо показывать 10x рост инвесторам в конце квартала — для выживания ему нужна лишь сырная тарелка и оплаченные счета за электричество. И дальше можно фигачить еще.
Именно поэтому инди-проекты могут со стороны показаться такими тупыми. «Приложение-будильник для телефона, которое соотносит ваш календарь с какательным расписанием вашей собаки, после чего рекомендует вам идеальное время для прогулок», — может принести его инди-автору десятки тысяч баксов в месяц. Да, люди могли бы приспособить для этого Google Calendar, но они же не ебобо.
В этом снова ваша инди-сила. Вот, например, последнее инди-приложение, которое я лично купил, делало лишь одну вещь — позволяло настроить направление скролла тачпада макбука отдельно от направления скролла на мышке. Да, блять, оказывается в настройках самого мака теперь этого сделать нельзя! Держи долор, добрый человек с реддита, который решил мою боль одним кликом.
И это снова диктует нам подход и стек. Если у вас 0 пользователей, нужен ли вашему приложению разухабистый фреймворк для тестирования? А тёмная тема? А форма восстановления пароля, если совсем уж?
Открою секрет: большая часть ваших инди-проектов умрёт, так и не дожив до этой необходимости.
Нужен ли бесшовный деплоймент сервису, на который заходят три человека в день? Да скорее всего нет, полежать 30 секунд пока делается docker-compose restart — не большая беда.
0 пользователей — вот ваша проблема. На ней и надо фокусироваться. А весь остальной овердизайн выбросить из головы нахер.
В инди вы можете делать вещи, которые недоступны корпоратам
Взять простейшую идею прямого телеграм-чата с основателем проекта, где любой может попросить новую фичу или пожаловаться на баг. Никакой FAANG не может себе такого позволить потому что у них слишком серьезные ебала и слишком много пользователей.
А для инди-проекта это, наоборот, может стать переломным моментом, когда люди подумают «блин, так круто, мне и на вопросы ответили, и мой баг починили, пойду занесу ребятам свои сто баксов на развитие».
То же касается шутеечек в интерфейсе или вот, например, у вас есть баг-трекер на гитхабе, куда вы настраиваете бота, который позволяет людям ставить реальную денежку за то, чтобы их фича была реализована. И когда фича стоит того и вы её сделали — бот автоматически начисляет вам все собранные за реализацию донаты. Ну кайф же? Никакой Facebook такого не может.
Когда-то давным давно (в 2018-м) я даже писал уже об этом феномене в рассылке про «Крафтовость — секрет успеха», где рассказывал, что в современном мире китайских копий, людей привлекают проекты, которые сделаны настоящими руками с любовью и душой, даже если они неидеальны. До сих пор работает.
В 2024-м так вообще киперпанк уже в самом разгаре и крупные айти-корпораты уже даже не пытаются притворяться «добренькими», творя откровенную хрень. На этом фоне маленькое и человекоориентированное инди, наоборот, кажется глотком свежего воздуха и даёт надежду.
Так что если у вас всё еще 0 пользователей и $0 MRR, то каждый раз спрашивайте себя — а если я сейчас потрачу неделю на X, это принесет мне хотя бы $1, или я делаю это, потому что «так положено» и «ну в книжках говорили что без X всё сломается»?
И дальше ответ сам станет очевидным.
Целью поста было не унизить корпорации, а показать, что даже в современном айти для инди по прежнему есть куча возможностей, если они не пытаются слепо всё делать «как большие». В кризис индустрия еще сильнее перекашивается и для инди-чуваков открывается больше новых путей, потому что люди начинают всё меньше и меньше уважать корпорации.
Конечно, всю эту дихотомию можно считать условной. Крайности полезны, чтобы подсветить нюансы, но в реальной жизни у вас всегда будет микс.
Даже у меня в жизни было минимум два примера, когда на работе мне давали карт-бланш на запуск проекта в режиме «инди». Чисто чтобы проверить концепцию и решить нужно ли оно.
Инди тоже бывает разное. Иногда вы действительно не можете себе позволить пролежать полдня с ошибкой 500, если решаете чувствительную ко времени проблему.
Говоря языком системного мышления — всегда смотрите на систему выше, которая находится непосредственно над вашим кодом. Пусть именно она диктует ваши ограничения, а не потому что «так в индустрии принято» и «ну по-другому нельзя».
Почему нельзя? Кем нельзя?
Если вам говорят нельзя, скажите Вастрик разрешил. Теперь можно.
В этой игре побеждает тот, чей проект больше $$$ принёс, а не у кого пайплайны были красивее и покрытие тестами плотнее.