Doc44

В 15 лет я уже вовсю программировал.
Пацан не хочет.

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

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

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

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

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

Странно даже.

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

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

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

Посоветуйте -как узнать что этот программист за эту оплату действительно сделает работу до конца?

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

Как определить и контролировать этапы разработки, если в коде сам не разбираюсь?

Договориться сразу, чтобы проект реализовывался как "готовый к демонстрации в любой момент".
Чтобы не было такого - я пилю фичу, но показать тебе не могу, потому что это внутри глубоко, а внешний вид буду пилить только когда все внутренние фичи допилю через полгода.
То есть договориться сразу сделать черновой-пречерновой внешний вид. И уже от него допиливать.
Таким образом вы сможете наблюдать чуть ли не ежедневно как какая-то мелочь меняется.

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

Как программист и человек, выступающий иногда и как заказчик - настоятельно вам рекомендую отслеживать результаты работы программистов постоянно. Мы ребята такие - заказчики же ничего не понимают в нашей работе. Всегда можем и соврать, что делаем нечто умное, а сами будем заниматься другими делами. Особенно после получения предоплаты.
;)

Офис или удаленка?

Проект представляется недостаточно крупным для офисного стиля работы.

Платить 100-150 в мес ? А что если сольется через 2-3 месяца ?
Далеко не все смогут продолжить начатое или это не критично..?

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

Квалифицированные специалисты как правило трезво подходят и к объемам проекта и качеству кода и планируют свое время на будущую работу эффективнее. Поэтому смысла сливаться им нет. Ну это если вы в цене сойдетесь. Если не сойдетесь, то квалифицированный просто не возьмется с самого начала. Мое имхо.

Предложить % долю? -думаю что они сыты такими предложениями , столько мертворожденных проектов..

И это тоже.
Есть и другое соображение. Разработчик сделает вам сегодня. Завтра он что вам в проекте будет делать? А долю - плати вечно.
В особо крупных проектах - смысл имеет.

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

На своем опыте знаю, что если толковому программисту не интересен сам проект, то и за рыночные деньги особо работать не будет. А за небольшие 50-70к/мес запросто будет кривой код и не оптимизированная под нагрузку БД.

Это здорово, когда от работы тебя прет. Но не обязательно вовсе.
Вы идеализируйте профессию программистов.

Общался со студиями по разработке: то договор кривой и несерьезный, то полу готовые решения и доработки 1,5-2к в час, что показалось дорого. Не исключаю, что нормальные студии запросят 1,5-3 ед. за разработку, не готов на это.

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

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

Также у студии проще отсудить назад деньги, если что пойдет не так. Но на общее качество/скорость разработки выбор студии/отдельного разработчика не влияет.

и он выстрелил. Объемы данных растут со страшной силой

Очевидно, что надо брать бабло с пользователей.

Это что, аттракцион невиданной щедрости? Эти деньги не нужно возвращать?

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

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

Ага. Очень халявные. Только разовые.
https://vc.ru/p/check-them-out
И это только, если вас еще не догонят и не прибьют.

Любому серьезному проекту нужна огромная куча бабла. Гигантская по меркам обычного человека.
Получить его не просто, поэтому к этому специальным образом стремятся.
Если этого не делать, не стремиться получить бабло, то проект просто завалится.

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

То есть аренду офиса ты оплатить можешь с этих денег.
А купить себе Ламборджини - нет.

Лучше второй
Не так потеет спина.

Но в целом - оба так себе говно.

У любого банкомата получаются зверские комиссии (я даже не говорю о лимитах на снятие).

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

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

2. С "версионностью" мне кажется не так много сложностей на самом деле.
Если воспринимать результат работы каждой команды как какой-то сервис с api наружу (а так наверное и есть), то по сути от команд требуется обеспечивать обратную совместимость новых версий api со старыми - задача которая в любом случае полезна.
Делать версионность без обратной совместимости - очень плохая идея как мне кажется. Тут и затраты на поддержку, и затраты на переподключение у всех остальных команд.

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

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

Почитайте для начала википедию - вам необходимо определиться с терминологией.

Изучите один язык программирования (например С++) на базовом уровне - напишите несколько программ - уровня калькулятор, уровня клиент-сервер (простенький чат), и что-то с базой данных. Можно тот же чат, с хранением данных в любой sql базе.

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

Зачем регулярка, если у вас просто маска?
Зачем эта сложная конструкция, если есть просто -mtime?

find /home/user -mtime -30 ! -path"*com/trash/*"

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

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

Зачем вам экспект?
Авторизация в ssh по паролям - прошлый век.

Настройте SSH ключи и просто выполняйт scp без паролей.