The better solution is to start by designing the API, and to leave the design of the data model (to support the API) and myriad of user interfaces (as clients of the API) for later.
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 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.
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.