There are plenty of reasonable ways to build web applications. If the process you described works for you, that's great, but others do find different strategies effective too.
For example, your process puts great emphasis on the visual design. To me, that aspect is almost entirely orthogonal to the software design. That's not to say it isn't important to getting a good end result, but once you know what interactions and information architecture you need, how you draw things on a screen doesn't affect anything else much.
I suspect a lot of teams would start with the external models like interactions and information architecture, then move to internal models like database schemas or REST APIs, and then implement the former in terms of the latter.
You firstly establish a purpose of your solution. Thinking the job to be done, the users, the features..
Then you do a design. Likely you have a design team, that does research and creates wireframes or high fidelity mock ups.
Then you establish requirements for the various layers in your stack.
So what I described is a fairly typical process. It is front to back.
I can't imagine someone building a product, starting with a myopic focus on the database, followed by rest contracts, etc...