Андрей Николаев

Возможно в меня сейчас что-нибудь прилетит, но мы используем Битрикс24 (собственно его же и внедряем).
Сделка прекрасно разбиваемся по направлениям:
- Проект
- Сопровождение
- Домены
- Лицензии

Для разработчиков используем Redmine, а для тех.поддержки Okdesk.

Получается следующий кейс: все новые обращение поступают в лиды, их обрабатывают сейлы (сотрудники отдела продаж), они определяют куда это все отправляется.
Далее заключаются соответствующие договоры.
- Лицензии (они же регулярные/разовые продажи продлений).
За Н дней до окончания лицезнии напоминание ответственному менеджеру, печать документов по лицензии, согласование цены и особых условий (для крупняков, госов и т.п.)

- Домены
То же, что и с лицензией, за исключением того что там нет согласования, а из документов только счет/акт

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

- Проект
Длительная штука, там есть интеграция с Redmine по количеству задач и потраченных часов.

Все внутренние коммуникации, евенты и т.п. берет на себя битрикс24. Учет рабочего времение (формальный, т.е. не сколько отработал, а работал ли вообще).
Рядовые сотрудники получают задачи в Redmine / Okdesk, а портал у них для общей информации по компании.

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

P.S. Jira кусается по цене сильно

На РИТ++ в этом году был прекрасный (на мой взгляд) доклад от Андрея Евсюкова из Lamoda. Рекомендую присмотреться. Записи увы нет, но по слайдам думаю будет понятна исходная суть.
Кстати, там рассмотрены именно Ваши проблемы (Time-to-market) и часть Ваших страхов

Да тут по сути пара вариантов и есть:
1) Либо запросы проксируются (пропускаются) через СА к внутренним ресурсам. Тогда СА является единой точкой доступа к сети.
2) Либо запросы идут к конкретным ресурсам, а они уже опрашивают СА на предмет - правильный ли этот токен.

Я мало где видел второй вариант, посколько использовать одну точку доступа и на ней же располагать СА куда проще и выгоднее (нет лишних запросов по сети и время ожидания меньше).

Для технической реализации стартапа у Вас есть 2 пути:
1) Найти партнера/сотрудника (далее компаньон) для разработки технической части проекта
2) Самому разобраться в технической части проекта

Оба подхода хоть и оттакливаются от одного и того же минимального набора знаний, но являются противоположными.
Если Вы ищите компаньона, то Вы должны в первую очередь быть в нем уверены, потому что ПОЧТИ ВСЮ техническую часть Вы отдадите ему. Ваша задача - идеи, маркетинг, бизнес и т.п. Вы обсуждаете с ним чего хотите, а у него уже болит голова как это сделать чтобы всем было хорошо
Если Вы хотите все контролировать, то увы, но Вам придется разобраться во многих тонкостях работы IT-специалиста (языки программирования, технологии, базы данных и т.п.)

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