Артем Воронов

Истина на мой взгляд посередине.

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

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

Вот это не очень понял - Вы говорите о документировании уже реализованного функционала? Мне кажется на стадии MVP это излишне, ваша задача наиболее быстро и эффективно реализовать что-то представляющее ценность и с его помощью проверить гипотезы востребованности итд.
То что будет написано в рамках MVP если проект заработает будет переписано 10 раз, смысла что-то документировать нет.

Редкий сайт приносит пассивный доход.

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

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

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

Ну и да, конечно могут встретиться разводы.

Если у мамы опыт в пром разработке 10+ лет - слушаться
Если меньше - переубеждать не надо, просто делай как сам решил

Решение называется "адекватный начальник". Оставайтесь на окладе, продолжайте работать по 8 часов день с перерывом. Важно не количество отсиженного за работой времени, а качество сделанного.

Если вы будете работать по 16 часов, а на выходе будет фигня из-под коня - какой от этого прок? А оплату будете требовать в двойном размере. Не годится такое, не правильно это.

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

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

общего продукта?

1. Для каких целей?
   
2. Кому он будет нужен?
   
3. Кто его будет поддерживать и развивать?
   
4. С помощью чего будут мотивированы создатели, чтобы продолжать над ним работу?
   

Но я постараюсь найти условия (оплатив часть работы напарников деньгами сразу или как-то иначе), чтобы иметь не менее 51%. Но мы отклоняемся от темы)

Без вариантов. Проще - на фрилансе заказать.

Рыбак рыбака. Разработчики если любят сотрудничать на таком основании то только с другими разработчиками/сисадминами либо смежными профессиями которые их дополняют, например дизайнерами-верстальщиками. Я, например не понял зачем вы мне ))

Пожалуй да. Место есть.
Но превратить хобби в продукт, раскрутиться - это не то же самое что программировать.

он не умер, он просто так пахнет

вообще то вопрос буквально гуглится..

Самая дорогая часть - дорога.
Проживание - не так уж и дорого.

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

Есть объединения русскоязычных фрилансеров, совместно арендуют - так дешевле.
Спросите у Пумы Тайланд, да.

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

Работать вы будете не на пляже.
90% времени проводить за компом.
В тамошних условиях обязательно нужна квартира с кондиционером. А это не дешевле, чем в РФ (в Москве не считаем).
А еще вам нужен нормальный интернет, который в Азии вообще говоря такой ... "азиатский", как правило. Это нужно поискать такую квартиру - это еще дороже.

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

Спросите, у питерцев, к примеру. А часто ли они бывают в Петергофе или же Третьяковке?
Или у жителей Горно-Алтайска - часто ли они ходят по горам с рюкзаком?
;)

Плюс естественно есть.
Но есть и минусы.
Я бы не рассчитывал, что вы будете прямо таки часто достопримечательности посещать.
Большая часть времени - работа, работа, работа.

Познав "дзэн программирования" перед тобой открываются большие возможности, и если есть идеи проектов, то их можно реализовывать, и зарабатывать на них, соответственно

В чем же дело? Вперед к реализации своих проектов и заработку на них!

Visual Studio есть на Win и на Mac.
Visual Studio Code тоже там же.

Везде кучи плагинов, дело привычки.
Уходить смысла большого нет, т.к. профита тоже не будет особо, только если на Rider.

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

2. Метод "разделяй и властвуй" известен уже не одно тысячелетие.
Делить проект на компоненты, отдавать разным людям в работу.
Что целесообразнее и из соображений, что узкая квалификация означает более качественную работу.

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

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

5. Того, кто будет объединять крупный проект в единое целое - лучше иметь под рукой, а не в удаленке. Или чтобы он был хорошо знаком вам.