Vitaly Sivkov

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

1) На сколько верным было решением использовать node.js и mongo?

Вопрос во многом холиварный. CRM это по определению много-много реляционных данных. Хранить это в любом nosql - я лично считаю очень плохой идеей. Особенно когда через полгодика пойдут change request`ы и выяснится что вещи которые в реляционке делаются за пару минут в nosql могут потребовать изменения архитектуры хранения и занять человеко-недели.

3) Сайтов у компании - масса, большая часть которых - лэндинги на чистых html с php-скриптом на почту. Все заказы ссылаются на единый gmail-ящик. Можно ли грабить эти данные из ящика, чтобы отправлять их в облако?

Можно. Но с учетом того что доставка email вообще говоря не гарантирована - завязывать один из ключевых бизнес процессов на это выглядит мягко говоря странно. По хорошему - сделать в вашей CRM, API наружу для формирования заказов и переписать все сайты для работы с ним.
* Странно что Ваш программист не может ответить на этот вопрос с закрытыми глазами

4) Какие существуют удобные облачные сервисы, которые предоставляют API для node.js?

Я рискну предположить что ЛПР где то услышал про облака и ему понравилось. На полном серьезе отдавать весь бизнес контент во внешний сервис - это надо или полным идеалистом быть, или просто не понимать о чем речь идет. Только свои железные сервера, только физическое резервирование.

5) Какова примерная стоимость подобного проекта в $ ?

Смотря где вы находитесь, насколько легально все это оформляете
В Мск приличного разработчика сейчас можно найти за 100-120 т.р. net, в регионах на 40-60 net (от региона зависит).
Сколько их нужно - без ТЗ сказать нереально, но думаю что оценка снизу это 3-4 разработчика
+тимлид 100% +project manager 100% +аналитик на старте +дизайнер по желанию +devops на аутсорсе итд

PS Без обид, но ищите грамотного CTO который это все организует. Это в любом случае длинный проект, так что можно и в штат найти человека.

Чтобы отзыв исчез вместе со всей историей, можно вернуть все деньги за проект. Если проект небольшой, и деньги не стоят нервов, можно просто плюнуть и расстаться с заработанной копейкой. Конечно, если проект большой, то просто так всё не вернёшь, однако при долгом сотрудничестве отрицательные отзывы — этот скорее исключение из правил: зачем было столько сотрудничать, если фрилансер не удовлетворяет?

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

В те времена, когда средний балл ещё не был заменён на JSS, моя встреча с неадекватным клиентом завершилась отзывом с оценкой 1.0, плюс он ещё в поддержку на меня нажаловался, правда безрезультатно. Так как средний балл заметно портился, то я вернул почти все деньги (вес оценки равен оплате). Так как отзыв был абсолютно бессодержательный, то я написал и свой отзыв, и ответ на его отзыв. А чтобы вечно мозолить клиенту глаза, не вернул последний бакс. Мой-то отзыв он скрыл, но вот пунктик с "10 часов, $1, скрытый комментарий" со ссылкой на мой профиль, где проблемы разобраны по косточкам, — будет висеть в проектах этого клиента вечно. При этом его отзыв на моей странице меня совершенно не пугает.

Макбук Про конечно, он рассчитан на профессионалов, у него много портов, он очень мощный. Можно поработать в пути и подключить кучу мониторов если нужно.

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

А чего это он у вас в мир смотрит? Ставьте nginx наружу, а в нем уже ssl, кеширование, балансировка и пр. штучки.
Понимаю, что не ответ, но имхо так правильнее.

Дембель неизбежен! Оформите ему альбом на память!

если вы про ту, которая на 1000+ страниц, то она не скоро устареет, но изучение js лучше начать с электронных ресурсов наподобиe https://learn.javascript.ru/
Флэнаган скорее как справочник хорош.

Потому что сейчас модно делать "толстые" интерфейсы на javascript и REST api бэкенд, к которому обращается UI (через ajax) с минимумом перезагрузок страницы.

Скрипты весят много, генерируют дополнительные запросы, из-за чего сначала прогружается просто статическая страничка (с кнопкой), потом подъезжают скрипты (они подключаются в самом низу, перед </body>), снова делают ajax-запрос к серверу: "А авторизован ли этот юзер?", на что сервер отвечает: "да", и скрипт рисует ссылку на "мой аккаунт".

Так что это, скорее, баг, как особенность сайтов с rich-UI.

Приготовьте огнетушитель или купите уже блок питания необходимой мощности.

Простой способ это линуксовый крон, в нем с помощью достаточно простой грамматики можно задать интервалы в достаточно широких правилах. Там задается все так:
минута час день_недели день_месяца месяц команда
Каждое из чисел это или (*), или число (5) или несколько чисел (2,3,5, 7-10), либо пропуск (что_то/интервал).
Поэтому можно легко задавать события типо каждый второй вторник
* * 2/2 * * команда
или первое число мая
0 0 * 1 4 команда 2
На основании этого можно строить регулярные события. На них накладывать расписание праздников (и то не всегда, к примеру оплата домашних счетов не зависит от праздников). Как вариант - можно сдвигать событие, если оно попало на праздник.

1. Недоработка аккаунт менеджера, он должен не бояться переключать клиентов на проектного менеджера. Есть куча способов мягкого первода.

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

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

Ну и конечно почитайте про ITIL :)

Да, еще есть книжка интересная, к слову, она по большей части мотивирующая, но для себя нашел пару интересных моментов, называется "Rework: Бизнес без предрассудков" авторы Джейсон Фрайд, Дэвид Хейнмейер Ханссон

1. Оценивать из опыта в нормо-часах
2. Закладывать риски от 10% до 30%. Соответственно, риски тем меньше, чем лучше вы знаете заказчика и его проект.

В чем проблема выведения ошибки в консоль? Если ошибки выводить в STDERR, а обмен данными производить через STDOUT, никаких проблем не будет.
Общение удобнее организовать через юникс-сокеты или через tcp на localhost. Пускай z-app висит демоном и принимает задачи на обработку.

С учетом мобайла, списка для одного человека гарантированно не существует.
Если оставить веб, то тоже крайне желательно разделять фронтенд и бекенд.
Для экономии ресурсов можете попробовать django, т.е. в навыках python, postgre, javascript, фронтенд-фреймворки. Но логично не страдать ерундой с одним разработчиком, т.к. это путь тупиковый.

Это называется "Дела давно минувших дней, преданье старины глубокой"
Люди которые это исповедуют называются староверы. Их можно узнать по длинным неухоженным бородам и прыжкам через костер. Они юзают DENVER, кричат о вреде bootstrap-a и думают что startup - это меню в макдоналдс. Остерегайтесь таких.

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