This is an unfashionable thing to believe. We spend our days arguing about the styling. Meanwhile the decision that actually determines how the next two years will feel gets made in ten minutes on day one and is never revisited: what a User really is, whether an Order can exist without a Customer, where that status column truly lives and what it's allowed to say.

Most 'we need to refactor' moments are really 'we modeled this wrong and have been paying interest on it ever since.' The polymorphic association that felt clever. The boolean that should have been a state machine. The nullable column that quietly means three different things depending on who wrote the row. None of these are code problems, and you cannot clean-code your way out of a model that doesn't match reality.

The encouraging part is that the reverse holds too. Get the nouns right — the real ones, the ones your users would actually recognize — and the code very nearly writes itself. Rails leans into this on purpose. A migration, a model, a couple of validations, and suddenly the framework does the boring, correct thing on every screen, because the shape of the data already told it how.

So I spend the first day of a project drawing boxes and arrows, not writing code. What are the things? How do they relate? What has to be true for a row to exist at all? I would much rather argue about whether a subscription belongs to an account or to a user now, on a whiteboard, than discover the answer eighteen months later through a support ticket and a very long night.

Frameworks come and go. The button will get restyled twice before launch. But the data model is the one decision that compounds — every feature you add afterward either fits the grain of it or fights it. Get it right and most of what's left is typing.