SanchezBoy

Вариант только один. Искать нормальных разработчиков, делать НОРМАЛЬНУЮ документаци, налаживать процессы, автоматизировать все что должно быть автоматизировано, рефакторить все, что должно быть отрефакторено, выкидывать костыли и заменять их нормальными решениями. Можно постепенно, если можно, а не все сразу.
Отдавать на аутсорс можно. Это довольно частая проблема, когда текущая команда не хочет изменений, или не в состоянии менять ничего. У нас приличное количество таких проектов. Отдать на аутсорс (можно и другой команде внутри) более мотивированной команде это один из выходов.

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

Определите наиболее весомые для проекта риски. Из того что перечислено, на мой вкус, это все яйца в одной корзине (один разработчик) и отсутствие тестирования. Важно понимать, что наличие костылей само по себе не так уж и критично, как поют некоторые спецы. Куда критичнее отсутствие регрессионного тестирования.

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

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

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

Для создания автотестов, вам не нужен разработчик, вам нужен тестировщик с навыками создания автотестов. Только когда будут автотесты имеет смысл разгонять скорость разработки за счет привлечения новых программистов, делать CI и по ходу фиксировать технические решения, важные для дальнейшей разработки.

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

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

А теперь по сути вопроса - сейчас занимаюсь реализацией авторизации для своего сервиса, сделал Yandex, Google+, Facebook. Все эти сети отдают email, как уже писал выше, с разрешения пользователя. Начал смотреть Vkontakte - там вроде тоже такое право есть.

Сомневаюсь, что есть соцсети, которые не дают право получить пользовательский email =)