In Frontend first, Andrzej Krzywda argues for developing Frontends without any backend interaction first to make sure that all the user flow works and where and what you actually need to persist. I'd like to present a similar approach, but on another level.

Being someone that usually works on backends, some of my projects don't even include a frontend. I do have a similar approach, though: models first. Before starting with accepting HTTP, a framework and other stuff, I pick a database access layer and start implementing stub models with relationships. It usually takes the form of one script and some tests and grows from there. I try to solve any problems that I am currently already aware of and try to prototype all important database interactions. Just like Andrzejs approach, it allows me to judge the impact of already known requirements ahead of working within a framework. As a last step, this set of models is slowly migrated into the main project, probably using framework. I use that approach both for new apps as well as for new big features.

Well decoupled applications allow you to prototype in parts: build a REST API without models, build a frontend without a backend or build a model layer without depending on an upper layer. Use this property to prototype the way those components work quickly without being hampered down by the interaction between the parts.