There's something to be said for treating it as an iterative process in layers. At first you have no specification, then you have a bad specification, and then increasingly good ones. The final implementation itself comes from having a good spec, and when you have that it should not matter which you start with.

The trouble comes in keeping a clear idea of what an iteration is supposed to test or accomplish beyond "makes it better" - and an end-to-end iteration is expensive. That is where the idea of putting the data model or UI "first" develops, since it lets you build from the technical details towards the concept, as a way of constraining and filtering your thinking.

Something I want to try but have not gotten around to willfully doing, is to treat the initial design stages as an exercise circuit of focusing on each layer for a limited period of time each day, rotating from one to the next.

I'm pretty sure that you could get some great results if a work week were spent doing a four hour cycle, with one hour each thinking and researching data, interfaces, UI, and premise/market.

The risks of building the frontend first take several forms. There is the eternal problem of the strategy people not understanding that the code can look like it works but not actually work.

And the risk of using mock data to populate a UI (to build it without any backend) is that we don't have good tools for tracking all of the places that we are still using mock data. This can lead to blind spots that make estimating delivery schedules very difficult. Because you may discover late in the process that some corner cases are still using fake data. And, it's a miserable way to work, trying to push through to a milestone when you have no idea how much further you have to go.