DX ломается не в SDK, а в первом шаге: что мешает дойти до рабочего вызова

DX ломается не в SDK, а в первом шаге: что мешает дойти до рабочего вызова

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

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

Хороший DX — это когда путь до первого запроса виден без регистрации в трех местах. Один минимальный сценарий, один язык примера, один ожидаемый ответ, одна страница с типовыми ошибками. Если API требует догадок, это уже не API-first, а hope-first.

Проверьте свой onboarding так: новичок открывает docs, копирует пример, меняет один параметр и получает понятный ответ. Если на любом шаге нужен созвон, значит документация не закрывает базовую задачу.

Сначала уберите трение, потом добавляйте возможности. Разработчик прощает бедный дизайн, но не прощает непонятный первый запрос.