<b>DX ломается не в API, а до первого рабочего запроса</b>

<b>DX ломается не в API, а до первого рабочего запроса</b>

Если дев не может за 10–15 минут понять, как дернуть ваш сервис, он не будет «разбираться позже». Он уйдёт в другой тул или в саппорт, а это уже плохой знак для продукта.

Проверьте onboarding не глазами команды, а глазами человека с нуля:
— где найти auth;
— какой минимальный запрос нужен;
— что делать, если вернулся 401/403;
— как выглядит рабочий пример на одном языке, а не на трёх абстрактных схемах.

Самая частая проблема — документация отдельно, SDK отдельно, а ошибки вообще спрятаны в тикетах. В итоге dev видит красивый эндпоинт, но не понимает, как дойти до результата без догадок.

Хороший DX — это когда:
— есть один короткий quickstart;
— примеры можно скопировать и запустить;
— названия полей совпадают в docs, SDK и ответах API;
— из ошибки понятно, что чинить.

Если хотите улучшить onboarding, измеряйте не «прочитали ли docs», а time-to-first-call. Чем меньше шагов до первого ответа от сервера, тем выше шанс, что продукт останется в рабочем стеке.