I've worked in settings where frontend development happens concurrently w/ backend, as well as settings where frontend development starts before backend develop

I've worked in settings where frontend development happens concurrently w/ backend, as well as settings where frontend development starts before backend development. You don't need to have API finality to start work on frontend. There's plenty of things to do in terms of UI that can be done without a APIs being ready. You just implement the skeleton first and fill in the data on a second pass, as it becomes available. Another alternative that other have brought up is agreeing on an API. This, in my experience, is a "best practice", but in actual practice, schemas change, backend devs don't always honor what they promise, and some bad apples just don't care about/aren't capable of coding to a specification. Pragmatically, it's easier to just consider the entire schema as a blackbox and implement the bulk of the UI with the assumption that the data will attempt to destroy your layout (e.g. by being too big, or having large unbreakable strings like URLs, or stretching things vertically in some way that makes nested scrolling suboptimal). When you look from that angle, there's plenty of work to do in anticipation for when the data flood gates open, and there's arguably more dependency on effective communication with designers/UX to ensure that the UI can adapt to data with dynamic/unpredictable nature.