Build Software from Front-to-Back

I would disagree, having been on both sides of this half a dozen times each.

When you write front-to-back, you don't get an immediate sense of what the deeper relationships and nuances of your data models are going to look like. You're designing for what you immediately think you want to see.

This approach can work well, until you run into things that end up being a lot more difficult to implement behind-the-scenes than the data you just expect to appear on the page in front of you.

Personal experience/preference, but the thing that has (almost) never led me wrong was doing a walkthrough of the domain of the application, and then thinking about what the client-side pages and functionality are going to look like (page-by-page, user stories), and then implementing the backend. Finally, wire up the backend to the frontend mockups/design.

For more complex systems, there are things that need to be ironed out in their entirety and have their modeling/relationships, and functionality proven on the API side of things before you decide to start writing UI elements for them.

On the flipside, having worked on projects where there have been major, multi-month setbacks, it was nearly always because the models/domain weren't well thought out and it needed major components to be re-worked (either UI or backend) before we could proceed.

isn't everyone building front to back?

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...

I think one should start with whatever extension in the API between front and back is needed. That is the point to make the compromise between the two. On the one hand one wants to make exactly the data that the front end needs available but on the other hand one wants something that makes sense to request to the data. Once one has that compromise front and back end can be developed separately.

> doing a walkthrough of the domain

Any advice on how to do this without a domain expert to hand?

Always interesting to read how others work.

I'm a backend dev who does quite a bit of frontend though I deeply dislike the current state of frontend (bring back Webforms)

For me it all starts with the database, always. Code, ux, network is all ephemeral. The schema, the invariants and the data are forever. (this is also why I think microservices are often the wrong approach, you're solving a code problem at the expense of the data)

I've been thinking about the concept of code as pipes for data and the (incorrect) emphasis we place on code. This is why something like MongoDB never clicked for me, code is worthless without the data it operates on and ensuring the quality of that data takes priority over anything.

Of course you need to know roughly what the data will be used for and approaching it database first can result in some nasty surprises if the requirements change, but the rest of the code will rot and be replaced far sooner than the database. Given the churn on frontend the schema in the database will probably see 5 front end frameworks come and go.

Edit: having written this I realised this is also why I don't like or understand letting your ORM handle database migrations. The code is built on top of a dependable database, letting it inform the design of the database is completely the wrong way round, in my opinion.