Most project conversations start with a framework question — React or Vue, Next.js or Remix. It's an easy conversation to have because the answers are well documented and the trade-offs are mostly about developer experience, not the business.
But the decision that actually determines whether a system survives contact with real usage is the data model. What are the entities, how do they relate, and where does the system need to enforce a rule versus just store a fact? Get that wrong and no framework choice saves you — you end up bolting workarounds onto a shape that doesn't fit the problem.
On the House Hunting System project, this meant sitting down with listings, landlords, and tenant accounts as distinct, related entities before a single React component existed. It's a slower start. It also means the schema hasn't needed a rewrite since.
The practical version of this: before opening a terminal, sketch what the core objects in the system are and how they relate. If you can't draw that on paper, the framework choice is premature — you're optimizing the part of the stack that's easiest to change later, while leaving the part that's hardest to change for last.