Мне очень слабо верится, всё равно. Дизайн, вёрстка, инфраструктура, финансы, бухгалтерия, реклама, маркетинг - всё сам?!

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

вот, не так долго и ждать пришлось

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

это могут быть ts файлы, описание схем контрактов и тд.
это позволит сохранить версионирование и консистентность типов.

если у вас язык хоть с какими-то типами.

если нет, то все эти сваггеры и генераторы все-равно не спасут, тк на ci не возможно проконтролировать что типы в коде соответствуют типам в пакете

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

у меня прошки были. с осени 2019

Придумали protobuf

И grpc

grpc немного уже, но неважно

Rework

Кто-нибудь исследовал рынок голосовых интерфейсов? Ищу решение чтобы тебя слушало нечто на десктопе, в колонке, мобиле и отправляло бы распознанное на твои собственные сервера. Есть конечно Google Assistant и даже кастомные обработчики позволяет писать, но требует постоянно активационные фразы типа «окей гугл» и «заюзать такой то навык».

Алиса технически подходит, но она не про кастомное - там все навыки публичные

чтоб не перечислять все что я знаю кроме протобаф я написал «описание схем контрактов»

но если типов в приложении нет, то толку все-равно никакого

Всем var

почему разработчики симфони считают что phpDoc важнее тайпхинтинга?

есть 3 подхода, но первые два требуют небольших изменений в коде:
1. Использовать externalDocs
2. Использовать $ref
3. смержить сгенерированный yml со своим

во-первых то что ты перечислил  - не рокет сайнс
во-вторых “отдавать иногда на субподряд” это не команда
в третьих доказательство лежит на том кто тезис выдвинул, так что то что ко всему что ты написал выше как минимум надо добавлять ИМХО

"Отдавать на субподряд" = координироваться с другими людьми, с чего и начался разговор.

цитата "Любой мало-мальски зарабатывающий деньги проект делается командами и только командами, время одиночек осталось в конце XX века."

выше уже порекоммендовали rework, но можно еще добавить the year without pants: wordpress.com and the future of work