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.