What changes for you
Your data model becomes something your team can read and change, reached a part at a time, while the product your customers use keeps working.
The situation usually builds slowly. Each quick addition made sense at the time: a field for one customer’s request, a second table because the first one was hard to change before a launch, a column whose name no longer says what it holds. Years later the same fact lives in two places, and nobody is sure which one is right. Some tables nobody dares to touch, because nobody remembers what depends on them. Every new feature now starts with an argument about where its data should go, and takes longer because of it.
After the work, the parts that were tidied have fewer tables, clear names and one home for each fact. A developer who opens them can tell what they hold. A new feature has an obvious place to put its data. The tables nobody dared to touch are understood, and those that served no one are gone.
This page is about the data model alone. If the wider codebase also carries years of shortcuts, paying down technical debt while features keep shipping covers that, and the two fit together.
What you decide
You decide which part comes first. Most teams know where it hurts: the corner every feature has to work around, or the duplicated fields that make two screens disagree. That knowledge is the best starting map.
You decide what each piece of data means. When the same fact lives in two places with two different values, which one is right is a business question, not a technical one, and it stays with you.
You decide the names. The tables after the work should use the words your team and your customers already use, so that a new developer and a product manager read the same thing.
You decide how far to go. Tidying one painful part may be enough for now, and the rest can wait until it starts to cost you.
You decide what ships. Nothing reaches your users without your approval.
What you see along the way
Changes to your data model land in your own repository, in pieces small enough for your team to read and approve. Each part you chose becomes simpler while the rest of your product carries on as before. A choice that is yours, such as which of two conflicting values to keep, reaches you with the question and a link.
What it costs you in time
A first conversation about where the data model hurts most and which features it is holding back. After that, short answers when a question about meaning comes up. The person who knows why a field was added is worth more here than the person who wrote it.
What if you want to stop
Each part that is finished stands on its own, so stopping after one leaves you with a tidier part and the rest as it was. Whatever you have approved remains in your repository, and your code and your product stay yours to take anywhere.
If nobody is sure what everything holds
That is the normal starting point, not a reason to wait. Admitting that a table is a mystery is often the most useful sentence in the first conversation. Lifting your eyes from the next feature long enough to name the parts that slow every feature is how the tangle starts to loosen.
Starting small
We have not untangled a data model for anyone yet, and we will not suggest otherwise. A sensible first piece takes one duplicated fact and gives it a single, clearly named home, with the screens that use it still working as your users expect. That lets your team see the difference in one familiar place before you choose the next part. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
