Philipp

Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.

Если денег нет совсем, то Redmine.

Дайте ему заранее инфу о своем продукте. На собеседовании пусть сделает холодный звонок из вашей базы.
Если продаст с первого раза - берите.

Есть довольно интересный проект, называется Pivotal Tracker.

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

Покопайтесь на newyork.craigslist.org
Порассылайте резюме, там иногда попадаются стартапы, которые готовы платить цену ниже рыночной, но дают некоторую свободу в плане посещения офиса и т.д.
Один важный момент - ваша виза должна разрешать работу в США, если у вас туристическая, то никто вас никуда не возьмет.

JIRA, Slack, GitHub, Google Hangouts.
У нас команда разбита на основную в офисе и удаленщики.
Все проекты ведутся в Jira, она интегрирована с GitHub & Slack. Как только задача меняет статус, это видно в слаке. Коммиты и пулреквесты содержат метки задач, поэтому видно, какая задача была закрыта каким кодом.
GitHub также интегрирован со Slack. Сразу видны code review, pull requests.
При управлении кодом используем слегка адаптированную модель отсюда
nvie.com/posts/a-successful-git-branching-model
Код из master всегда в деплое, разработка путем пулл реквестов в development. Под каждую задачу (группу совместных задач) отдельная ветка.
Пулл реквесты облегчают рассмотрение кода. Внутри имеем правило - пул реквест обязательно должен быть прочитан кем-то еще, кроме автора. Автор мерджит после одобрения.

Тоже используем Slack. Очень удобный, имеет потрясающие возможности по интеграции с другими сервисами через web hooks и свой API. У нас интегрирован с GitHub, CodeShip, Sentry и SalesForce Chatter (через Zapier).
Плюс написали парочку самопальных скриптов для внутренних нужд. Это очень легко и просто.
Работает с телефона тоже. Сила Slack в его интеграции со сторонними сервисами и плюс очень дружелюбный. У нас ребята поназагружали кастомных смайлов и развлекаются, когда очень тоскливо.
Еще очень удобно загружать кусочки кода в тред, они с подсветкой и т.д. В HipChat это тоже есть, но не так круто.
Для звонков у нас Google Hangouts (в слаке даже есть команда /hangout для начала звонка и автоматического приглашения участников канала). Hangouts стабильнее.
Рекомендую почитать это.