I don't think front-to-back or back-to-front are correct. From my experience, it's always from what I've seen outside-in This means understanding the problem d

I don't think front-to-back or back-to-front are correct. From my experience, it's always from what I've seen outside-in This means understanding the problem domain. What does the app solve? Better yet, how does the app either (1) save money/resources for the problem, or (2) generate revenue streams? When you start from this approach, things become much more clear. Generally speaking, start with the UX low fidelity wireframes first. What are the user-stories for the user? Can they log in? Can they do some CRUD functionality relative to the problem domain? Okay, what data does this user need for these pages? What sort of user-activity are they going under? Create a set of datatables describing the problem domain. It needs a user table? check. It needs a license table? Just map out all the data needed, and group them into appropiate tables. Fromo there, map out the relationships in a relational format to get a better prospective on the bigger feature Are these features even needed according to the frontend? Okay, go from there. What is the cost to implement each feature, and how does this impact the development velocity / budget of the project? Go and find the sweet point of what's defined as a MVP, and then proceed to figure out what a stage 2 looks like. Does the original data model have a migrationary upgrade path? Imagine if your developing the backend. Do you forsee problems running the migrations? Now you need to think about scalability and whether that actually matters here. Changes are it doesn't for the vast majority of apps. Do you need subscribers to aggregate bulkInsertions to the database? Do you need a redis cache to prevent unnecessary calls to database? Or do you need something more complex, because the end user is a developer and your providing a high scalable Web API service? Just keep cycling outside-> in until you've satisfied all the results into a proper MVP database and a MVP UX pen paper design. At this point, you'll want to define the API and how the frontend will consume it. How will the backend handle it? For instance, if you spec it graphql, prepare for a world of pain on the backend and an easy life on the frontend. You should think about your API design, and use design patterns to think about how you can keep the frontend as simple as possible. The state of truth should of an application should live closest to its data source(s), so tread with this path in mind. Sometimes the frontend does the same work (e.g. financial calculations) to reduce the total number of calls to the backend. You might want to consider everything else here at this point, e.g. whether websockets are needed etc. And other factors in the application such as third party providers. There's many right solutions to a problem domain, but there are just as many wrong solutions as well. Go from the business side first, and go outside-in. The best answer is the simplest one that satisfies all criteria, both in UX and how scalable it needs to be