Depends, if it's an API driven app, I'll typically build out 95% of the API first. Then I'll jump into the front end and start building the components (usually with Vue) that consume that API. It's in this phsae, that I can iron out the last 5% of the API.

If it's not an API driven app, then yes, it's usually concurrent.

I build them in parallel, feature by feature. Sometimes I might spend a little bit more time on the front end but since I am not really a designer, I just set up the template for a start and build a prototype application. Later on, I just change stuff and refactor code if needed.

I do this because I know that things will change and better ideas will come up later on. You can't possibly know what's coming up next, or how it will look based on the first ideas and the initial spec.

Sometimes I just add features to a list by myself just to improve the User Experience and talk about the ideas with the client if they will be implemented or not.

Thing is , when one starts with design first , the temptation to spend a lot of time on "trivial things" is high. On the flip side, great functionality with poor or not so great design often is a path to poor user acceptance.

If I had clients, I would do the business logic first and front-end second, because it seems like the front end would be dependent in some ways on the back end, yet the back end could be developed and tested completely independent of the front end.

This is rather a personal opinion. But when I'm alone, I tend to make a prototype first. This would be html, css and navigation, with fake data displayed.

I do this because it helps me focus when coding the logic behind it (give life to it). It's also useful to detect "holes" in your business logic before you do any complex coding, especially when dealing with clients. Because you can make all the specs you want, but clients will only see what's wrong once you show them the interface.

I tend to build the functionality with no design at all, once it's a point I'm happy with I then put a design in place and adapt as needed.

I can't always do that depends on the projects but more often than not it's build the feature then the design.

Well it's a little hard to make a decision, in the current solo project I am i make the login screen and the skeleton of the backoffice, and after i decide wich screen or section wan to do, and make more or less the skeleton, make some class diagram, put the code, make the tables, and make a bit of login and continues with the styles, i think if you are alone you can't do first one and later other because are complementary.