I not totally agree with this. Architecture is really important because it can make new feature less expensive in term of development. If you judge a work only in terms of final product UX, you miss this point.
Architecture is important but not as important as getting the data-model right. We can refactor out bad architecture but a bad datamodel will have missing or inaccessible data since it was created and you cannot get that back.
Too many people do build like this initially but are not willing to pay to fix the mess when it starts to get hard to add new features.
Data models are a dime a dozen and are throwaway.
Your architecture can change.
Saving the whole file or not is an architectural decision involving cost tradeoffs, technology capabilities, and business strategy.
Which data points you put in your OLTP is the data model and, as you just painted an example of, throwaway when the use cases change. Later you'll want different data points or different relations. And then you'll evolve your data model yo serve that. If you did your architecture right, it will change much less than the data in your databases.
Sometimes, it's as simple as "frontend, backend, and a way to deploy it".
Not to mention so many developer tooling products out there already decide on the architecture for you. Use anything firebase for example, and you'll be pretty railed in around the way your system is architected.
One “product first” engineer I worked with years ago made a database indexing system, syncing our data into elasticsearch so we could add text search to our product. For about 6 months after the feature launched we kept running into indexing bugs - where data was missing from the index and things like that. I (naturally code first) ended up helping rearchitect it. After we relaunched the feature we never had another indexing data bug as long as I was at the company.
Sometimes it’s faster to take more time to do it right rather than do it wrong and spend your life playing whackamole with bugs. It all depends on your context. (Is this a MVP to throw away? Or are you working on code that will probably still be around in a few years?). The best engineers know how to adapt their own personal process to the needs of the project. Sometimes that means quick and dirty. Sometimes it means thinking it through and building it to last.
Maybe the broader frame is to say there’s two perspectives to hold: the perspective of the user and the perspective of the code. Each orientation has its own set of supporting skills. Good developers are strong in one of those perspectives, but need other people on the team to balance them out. Excellent developers are strong in both, and can switch between them based on the immediate needs of the company and project.