Alex Goncharov

Все перечисленные пункты действительно важны, но это только идейная и техническая сторона вопроса.
Начать надо с того, чтобы посмотреть на то, как экономически и управленчески развиваются стартапы. Желательно послушать питч-сессии - очень полезно. Был на таких недавно на прошедшей Startup Village 2016. Действительно много интересного. И кстати некоторые уже работающие стартапы говорят о том, что не правильно оценили потребность в своем продукте и после исследования рынка изменили свои проекты и теперь просят новых денег у инвесторов.
Иными словами важно правильно понять своего потребителя и свой бизнес в целом. Вопросы монетизации тоже не на последнем месте. А по указанным четырем пунктам, уверен вы справитесь.

Всё imho:

1) Техническое задание стартапа должно описывать функционал + подробно детализировать неявные моменты.
Писать по госту на 40+ листов - верный путь в никуда.
Нанимать на написание ТЗ категорически никого не советую - это должны сделать Вы, как носитель идеи.
Если за дизайн в проекте отвечаете Вы, в принципе готовый дизайн + frontend сценарии + неявные backend сценарии это вполне нормальное ТЗ.

* frontend сценарии - набор экранов приложения со стрелочками "что происходит если нажать сюда"

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

*** Вообще странно брать инвестиции не имея ТЗ и соответственно оценки разработки.
По опыту 30k$ это скорее MVP чем полноценный продукт.

2) hantim.ru , hh.ru , проверенные аутсорсеры итд

3) Правильный порядок: ТЗ > Дизайн > Проектирование Backend > Разработка Backend > Разработка Mobile.
* Если горят сроки можно перед разработкой backend за день собрать моки и вести разработку на них.
** Если в backend есть вещи не завязанные на дизайн - backend можно начать делать параллельно с дизайном

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

С чего начать разработку стартапа?

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

Зависит от нагрузки.

Собственную - только для серьзных задач. Иначе не выгодно.

Google Hangout - нормальный и даже бесплатный, вроде.

Судя по тому, что Вы описали - Вы жадничаете. Я бы просчитал так - взял бы период самоокупаемости (ну или период, за который Вы выйдете на желаемый уровень. У Вас ведь есть что-то типа бизнес-плана?). Просчитал прибыль за этот период, если Вы будете делать все без инвестора и с ним. Отношение этих цифр и даст долю вклада. Если доля вклада инвестора слишком высока, то есть подозрение, что продукт нафиг никому не нужен и надо цепляться за инвестора. Если мала - есть цифры на которых обосновать инвестору такую долю. Все это, конечно, ИМХО.

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

https://www.youtube.com/watch?v=fB0XwZpfEBo&index=... - в этой лекции (и в других данного курса) как раз рассказывают как это спланировать и проверить.

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

Пример для веб-сервиса:
Структура
-Главная
-Каналы
--Страница канала 1
--Страница канала 2
-О сервисе
...

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

Архитектурная составляющая
-Типы данных
--Новость
---Тип данных предназначен для учета новостей. Тип данных должен включать в себя следующие атрибуты:
----Заголовок* (тип: строка);
.....

-Списки
--Последние новости
---Список последних 5 новостей (ссылка на тип данных "Новость"). Список должен включать в себя:
----заголовок;
....
---Список должен быть отсортирован по дате, по убыванию.

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

====

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

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

Для описания сущностей смотрите в сторону UML или ERM.

Надо фиксировать текущее состояние пользователя бота, с кем идет диалог.
Описать правила, какие команды при каких состояниях могут выполняться.

При команде "Оставить отзыв" менять состояние на ожидание ввода отзыва. После команды "Стоп" состояние меняете на ожидание ввода команд.

Да, https://blockchain.info
В поиск надо вбить кошелёк получателя либо номер транзакции.
Обратите внимание, что есть еще всякие www.localbitcoinschain.com и тому подобное.

Symfony Console Component
Question Helper

https://sameroom.io/blog/connect-slack-and-telegram/

как вариант

но лучше и там и там поработать с API