DX ломается не в API, а в первом запросе и ответе, который дев не понял

DX ломается не в API, а в первом запросе и ответе, который дев не понял

Time-to-first-call — это не метрика для презентации, а проверка на вменяемость продукта. Если разработчик не может за 5–10 минут получить рабочий ответ, он уходит в соседний сервис или пишет свой костыль.

Что обычно убивает onboarding:
— нет короткого quickstart без лишней теории;
— auth размазан по трем страницам;
— примеры есть только для одного языка;
— ошибки возвращаются текстом без кода, поля и причины.

Что работает лучше:
— один путь: install → auth → request → result;
— минимальный пример, который можно скопировать без правок;
— схема ответа с типами и примерами плохих кейсов;
— отдельная страница с частыми ошибками и готовыми фиксами.

Если у вас есть SDK, проверьте его как новичок: откройте docs с пустым кэшем, запустите пример и засеките, где вы споткнулись. Именно там и живёт боль DX.

Сделайте первый успех коротким, а не «полным». Тогда dev останется в продукте, а не в логах.