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