You don't know what should be in the API until you've had a couple clients built on top of it. Users will surprise you; oftentimes that little UI detail (the one that's really hard to fit into your API) is what will make them buy.
A similar argument also applies in the opposite direction. That is, it’s all very well beginning with a beautiful, idealised API, but if there is no efficient way to implement that interface then you’ve backed yourself into a corner before you even start.
Also UIs which don't have to support an actual data manipulation tend to underestimate dealing with the edge cases of that manipulation - which I tend to think is why you never get too far from the shell in Unix-likes.
And why so many database-backed webapps look like a frontend over a database, and virtually all mobile messaging apps are frontends over TCP/IP, and web directories before Google were just webpages with a whole lot of links.
It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross. The danger with building the data model or API first is that you'll build the easy, obvious API, which is the same easy, obvious data model & API that all your competitors build. Start with the user instead and you can end up with some really powerful differentiators, at the cost of it being a bitch to transform into working, sane computer code.
It turns out it can be pretty profitable to break with the machine model of the underlying data and instead present things the way your users want to see them, even if it makes the code necessary look complicated and gross.
It certainly can, though I think you’re still figuring out a data model first on those projects. It’s just that you’re starting with how the information is organised and manipulated from the user’s point of view, then figuring out an internal representation to support it afterwards, rather than the other way around.
Experience (with this style of development) helps out here. For stuff you're completely clueless on though, it still happens. And that's when you revise your design.
Its far better to go in this direction than the other, in terms of code clarity, and it's pretty rare to have it impact performance... at all, as long as you're willing to go back and rewrite the ideal code to be a bit more practical when you notice an issue.
